On Wed, 20 Jun 2001 08:20:03 -0700 Aluo Nowu <etoffi@users.sourceforge.net> wrote:
wouldn't it be just great if Mailman lists could tell you what messages you have bounced (and provide a way to get them of course =P), just like ezmlm?
Sure.
<foobar-return-500-lazyman=mailserver.org@lists.baz.quux>
Message numbers are the relatively uninteresting case as they are an arbitrary value that Mailman may not (usually doesn't) actually know at the time of broadcast, and which further, doesn't actually apply or necessarily exist for those using external archivers.
Message-IDs would be a better and more guaranteed portable route and in the general case don't need to be embedded as you can already find them in the bounce.
-- J C Lawrence claw@kanga.nu ---------(*) http://www.kanga.nu/~claw/ The pressure to survive and rhetoric may make strange bedfellows
please keep me on cc: etoffi@bigfoot.com
J C Lawrence writes:
On Wed, 20 Jun 2001 08:20:03 -0700 Aluo Nowu <etoffi@users.sourceforge.net> wrote:
[snip]
Message numbers are the relatively uninteresting case as they are an arbitrary value that Mailman may not (usually doesn't) actually know at the time of broadcast, and which further, doesn't actually apply or necessarily exist for those using external archivers.
so mailman does _no_ storage of messages after they are sent? if so, i applaud task separation.
Message-IDs would be a better and more guaranteed portable route and in the general case don't need to be embedded as you can already find them in the bounce.
given that mailman does _not_ hold onto messages, a separate program/component/thingydoodle would be the best way to go, or modifing the code directly?
maybe a separate, "virtual" list?
ps: i'm quite sure i should start looking at the code now.
-- J C Lawrence claw@kanga.nu ---------(*) http://www.kanga.nu/~claw/ The pressure to survive and rhetoric may make strange bedfellows
-- etoffi <http://oluworld.sourceforge.net/>
On Thu, 21 Jun 2001 05:33:36 GMT etoffi <etoffi@softhome.net> wrote:
J C Lawrence writes:
On Wed, 20 Jun 2001 08:20:03 -0700 Aluo Nowu <etoffi@users.sourceforge.net> wrote:
Message numbers are the relatively uninteresting case as they are an arbitrary value that Mailman may not (usually doesn't) actually know at the time of broadcast, and which further, doesn't actually apply or necessarily exist for those using external archivers.
so mailman does _no_ storage of messages after they are sent? if so, i applaud task separation.
Mailman has an internal archiver which may or may not be enabled for a given list. By default it is enabled. In my case it is disabled as I use an external archiver (MHonArc) which operated asynchroously with regard to the list.
Archiving using the internal pipermail archiver takes place under the qrunner context when the message is broadcast.
Message-IDs would be a better and more guaranteed portable route and in the general case don't need to be embedded as you can already find them in the bounce.
given that mailman does _not_ hold onto messages...
It *may* not. More specifically it does not (when using the internal archiver) in a format friendly to re-access/sending (web and mbox).
a separate program/component/thingydoodle would be the best way to go, or modifing the code directly?
maybe a separate, "virtual" list?
ps: i'm quite sure i should start looking at the code now.
You're trying to solve the wrong problem. MessageIDs effectively uniquely identify messages. They are what you are looking for: A way of identifying a message. Don't try and re-invent a poor shadow of something that is already there.
-- J C Lawrence claw@kanga.nu ---------(*) http://www.kanga.nu/~claw/ The pressure to survive and rhetoric may make strange bedfellows
(just in case any new people reply, please keep me on cc!)
J C Lawrence writes:
You're trying to solve the wrong problem. MessageIDs effectively uniquely identify messages. They are what you are looking for: A way of identifying a message. Don't try and re-invent a poor shadow of something that is already there.
well i for one actually think message numbers are nice to say the least. but the difference between [message numbers and message ids] id irrelevant in this context. one thing i would like to say about message numbers before leaving this part of the conversation is that i can create my own list archive, which is automatically synced with all others because i have a "master" number. maybe this could be an option (for people who like this point)
either way, my idea is to have a unique value that represents each message accepted to a list and a map of subscriber addresses and missed message [unique values]. Mailman could then try for, let's say, two weeks, then automatically unsubscribe the bounced user or put them "on hold."
-- J C Lawrence claw@kanga.nu ---------(*) http://www.kanga.nu/~claw/ The pressure to survive and rhetoric may make strange bedfellows
-- etoffi <http://oluworld.sourceforge.net/>
On Fri, 22 Jun 2001 01:35:22 GMT etoffi <etoffi@softhome.net> wrote:
J C Lawrence writes:
one thing i would like to say about message numbers before leaving this part of the conversation is that i can create my own list archive, which is automatically synced with all others because i have a "master" number. maybe this could be an option (for people who like this point)
There is little preventing you from using MessageIDs to and for the same purpose. The only difference is that literal numbers are a bit more human friendly than MessageIDs. I argue that this is a false economy as, handled properly the MessageID's would never have to be human processed but could be embedded in URLs and pre-canned commands ready to email.
either way, my idea is to have a unique value that represents each message accepted to a list and a map of subscriber addresses and missed message [unique values].
Not a bad idea. I've got a CGI that does MessageID based lookups on MHonArc archives (give it the MessageId it returns the archive page). It wouldn't be difficult to ad a mapping back to the original message.
In fact I'm about to be doing precisely this by adding a function to my archives such that you can have the original copy of any list post emailed to you.
As for the tracking of missed messages by subscribers this requires VERP support as you can't guarantee taht the MessageID is available in a bouce. VERP support is currently under discussion as a possible future optional feature -- it comes with a number of other fairly chunky disadvantages.
Mailman could then try for, let's say, two weeks, then automatically unsubscribe the bounced user or put them "on hold."
Automatic resends of bounced/missed posts my the MLM is an interesting idea. I don't like it from an abstraction/layering model, but I can see why the interest. Given a VERP supporting MLM I'd prefer a pattern ala:
-- Member bounces N messages -- Member successfully receives M messages as determined by the fact that no bounces for them is received for Q days. -- Mailman emails a list of the missed MessageIDs to the member along with instructions on how to retrieve/read the missed messages.
The contents of the "how to retrieve X message" would have to be tailored fairly heavily depending on the configuration of the list in question (eg archiver turned on or off, use of an external archiver, use of a subscribed archiver, external retrieval methods, etc).
-- J C Lawrence claw@kanga.nu ---------(*) http://www.kanga.nu/~claw/ The pressure to survive and rhetoric may make strange bedfellows
participants (3)
-
claw＠kanga.nu -
etoffi＠softhome.net -
J C Lawrence