Re: [Mailman-Developers] Modifications to msg
On Mon, Mar 18, 2002 at 08:12:54PM -0800, J C Lawrence wrote: > RFC 2822 explicitly states that Reply-To can contain a list of > headers. RFC 822 is more ambiguous. To my mind this single fact (if > used with Reply-To aggregation) obviates most of the arguments in the > Reply-To Munging Considered Harmful document. Not really, it only addresses the limited problem that Reply-To munging removes the Reply-To that the posting user could have been set. In the case where I want replies to go to another address than my posting address, that's fine, and indeed extending Reply-To: is much better than replacing it. This doesn't affect however the many other problems including: - me trying to set a reply-to to redirect traffic to another list (not that it works that well anyway, but at least it can give a clue) - you replying to me privately without having to hand edit headers - mailing list loops with broken autoresponders) - etc... (see reply-to considered harmful document for "etc") Marc -- Microsoft is to operating systems & security what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ | Finger [EMAIL PROTECTED] for PGP key ___ Mailman-Developers mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-developers
Re: [Mailman-Developers] Modifications to msg
On Mon, Mar 18, 2002 at 08:12:54PM -0800, J C Lawrence wrote: > On Mon, 18 Mar 2002 19:28:59 -0800 > John W Baxter wrote: > > > (Unlimited reply to headers sounds like a great way to get a Spam > > multiplier effect, but that wasn't a consideration at RFC writing > > time.) > > RFC 2822 explicitly states that Reply-To can contain a list of > headers. RFC 822 is more ambiguous. To my mind this single fact (if > used with Reply-To aggregation) obviates most of the arguments in the > Reply-To Munging Considered Harmful document. The Linux Answer Gang list at ssc.com uses multi-player Reply-to's. It confused me at first, because I keep Mutt set to prompt, and it only prompts for the *first* address in the list -- subsequently giving you and edit-mode prompt showing all the reply-to's, which it handles correctly. Cheers, - jra -- Jay R. Ashworth[EMAIL PROTECTED] Member of the Technical Staff Baylink RFC 2100 The Suncoast Freenet The Things I Think Tampa Bay, Floridahttp://baylink.pitas.com +1 727 647 1274 "If you don't have a dream; how're you gonna have a dream come true?" -- Captain Sensible, The Damned (from South Pacific's "Happy Talk") ___ Mailman-Developers mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-developers
Re: [Mailman-Developers] Modifications to msg
On Mon, 18 Mar 2002 19:28:59 -0800 John W Baxter wrote: > (Unlimited reply to headers sounds like a great way to get a Spam > multiplier effect, but that wasn't a consideration at RFC writing > time.) RFC 2822 explicitly states that Reply-To can contain a list of headers. RFC 822 is more ambiguous. To my mind this single fact (if used with Reply-To aggregation) obviates most of the arguments in the Reply-To Munging Considered Harmful document. -- J C Lawrence -(*)Satan, oscillate my metallic sonatas. [EMAIL PROTECTED] He lived as a devil, eh? http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live. ___ Mailman-Developers mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-developers
Re: [Mailman-Developers] Modifications to msg
> There is rather tortured logic in the old (and maybe new) documents > justifying the ability to have multiple addresses in the single From: > header. Personally, I've never sent or received one of those, even as a > test message (I'm sure to get one now, having said that ;-)). Geek wedding announcements? :) :) > And remember, too, that some things in RFCs are the way they are because > that's the way they are (and are hard to explain any other way). surely true. And the point about "there sorta must be multiple Received:s" is of course well-taken. ___ Mailman-Developers mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-developers
Re: [Mailman-Developers] Modifications to msg
At 18:56 -0800 3/18/2002, Dan Mick wrote: >> RFC 2822 rules on the number of specific headers a message can have. >> E.g. it can have many Received: headers, but only one Reply-To: header >> (although the latter allows for multiple addresses... go figure). > >Ease of parsing. No one but humans typically looks at Received:, >but dumb MUAs need to use Reply-To:, so complicated tricks for >accumulating a list are limited there. (at least that's what >I'd guess at for a rationale.) There is rather tortured logic in the old (and maybe new) documents justifying the ability to have multiple addresses in the single From: header. Personally, I've never sent or received one of those, even as a test message (I'm sure to get one now, having said that ;-)). The other side of the coin is that there almost have to be multiple received headers (OK, there could be one, munged some more by each handling MTA, but that sounds dangerous for several reasons including ultimate size), since multiple MTAs along the message's travel MUST each include a Received: header (or would have to stick the information into the one Received: header given the other rule). And, of course, too many hops would be harder if the MTAs had to unwind a 30 sub-item Received: header. So let's turn the question around: of what headers is there a logical reason for multiples. 1. Received, for the reasons mentioned. 2. X-anything (I suspect, since there's little control over those) But not Date: (despite the appearance of multiple ones of those in some messages) and several others. Reply to: ?? There probably shouldn't be huge numbers of Reply to: addresses. Multiple addresses are probably allowed on the same sort of reasoning as multiple addresses in From:--the boss and the secretary thing. (Unlimited reply to headers sounds like a great way to get a Spam multiplier effect, but that wasn't a consideration at RFC writing time.) And remember, too, that some things in RFCs are the way they are because that's the way they are (and are hard to explain any other way). --John -- John Baxter [EMAIL PROTECTED] Port Ludlow, WA, USA ___ Mailman-Developers mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-developers
Re: [Mailman-Developers] Modifications to msg
> RFC 2822 rules on the number of specific headers a message can have. > E.g. it can have many Received: headers, but only one Reply-To: header > (although the latter allows for multiple addresses... go figure). Ease of parsing. No one but humans typically looks at Received:, but dumb MUAs need to use Reply-To:, so complicated tricks for accumulating a list are limited there. (at least that's what I'd guess at for a rationale.) ___ Mailman-Developers mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-developers
Re: [Mailman-Developers] Modifications to msg
At 07:55 PM 3/18/2002 -0500, Barry A. Warsaw wrote:
>Just a quick style nit; I hope you don't mind!
>
> | 1if msgdata.get('dlist'):
> | 2threadID = msgdata['thread_id']
> | 3syslog('info', "threadID = %d", threadID)
> | 4to_line = '%s-%d@%s' % (mlist.real_name.lower(),
>^^^
>
>better to use "mlist.internal_name()".
Not at all. Thanks.
Ellen
___
Mailman-Developers mailing list
[EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/mailman-developers
Re: [Mailman-Developers] Modifications to msg
>I hope that helps, It's very helpful. Thank you. Ellen ___ Mailman-Developers mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-developers
Re: [Mailman-Developers] Modifications to msg
Just a quick style nit; I hope you don't mind!
| 1if msgdata.get('dlist'):
| 2threadID = msgdata['thread_id']
| 3syslog('info', "threadID = %d", threadID)
| 4to_line = '%s-%d@%s' % (mlist.real_name.lower(),
^^^
better to use "mlist.internal_name()". While it's true real_name
shouldn't be different except for case changes, I still think
internal_name() is more consistent with what Mailman uses internally.
|threadID,
|mlist.host_name)
| 5syslog('info', "to_line = %s", to_line)
| 6del msg['To']
| 7msg['To'] = to_line
| 8syslog('info', "Set msg['To'] to '%s'", msg['To'])
-Barry
___
Mailman-Developers mailing list
[EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/mailman-developers
Re: [Mailman-Developers] Modifications to msg
> "ES" == Ellen Spertus <[EMAIL PROTECTED]> writes:
ES> I've been making some modifications to Mailman to support
ES> dynamic sublists (http://javamlm.mills.edu). I'm still rather
ES> new with Python and have a question about modifying fields
ES> (dictionary elements) of the msg data structure.
It's important to remember that the Message class is not a dictionary,
even though it supports dictionary-like syntax. Python is funny in
that there is no concrete interface specification, so we tend to say
something is "mapping-like" or "file-like" if it supports common
methods of those built-in types, but those similes don't really mean
anything. But they are amorphous because "file-like" might mean the
object supports a write() method with the same signature as a file
object's write(), but what does that say about a "file-like" thing's
read() method, etc.? Nothing, actually. :)
Mapping-like is even more information-free. Usually a mapping-like
object supports __getitem__(), and keys(), but does it support
items(), values(), setdefault(), etc.? Who knows?
When in doubt, we have to be concrete about what API a class provides
or expects, e.g. /this/ method, or /that/ signature.
ES> Specifically, I added the following code to change the
ES> message's "To" field at the end of CookHeaders.py:
| 1if msgdata.get('dlist'):
| 2threadID = msgdata['thread_id']
| 3syslog('info', "threadID = %d", threadID)
| 4to_line = '%s-%d@%s' % (mlist.real_name.lower(),
|threadID,
|mlist.host_name)
| 5syslog('info', "to_line = %s", to_line)
| 6del msg['To']
| 7msg['To'] = to_line
| 8syslog('info', "Set msg['To'] to '%s'", msg['To'])
ES> This correctly changes the "To" field of the message from
ES> etest-new@hostname to etest-@hostname, as shown by
ES> the log: Mar 18 13:29:55 2002 (4600) threadID = 19 Mar 18
ES> 13:29:55 2002 (4600) to_line = [EMAIL PROTECTED] Mar
ES> 18 13:29:55 2002 (4600) Set msg['To'] to
ES> '[EMAIL PROTECTED]'
ES> Similarly, the resulting email message that is sent has the
ES> new 'To' field.
ES> The problem is I don't see why line 6 above is necessary.
Here's where the Message class has purposefully different semantics
than a dictionary. Specifically, because email messages can have more
than one of some kinds of headers, the Message class supports this as
well. Therefore __setitem__() -- which is what "msg['to']" maps to --
does not delete existing To: headers. However, I didn't want
__getitem__() -- aka msg['to'] -- to return anything but a string, so
I decided that in the face of multiple headers, __getitem__() would
return "one of them". Which one it returns is purposefully left
undetermined.
That's why Message.get_all() exists, so that you can get all the To:
headers the message might have had. That's also why you must call del
first -- aka __delitem__() -- if you want to overwrite all the To:
headers.
This is all spelled out in the module documentation:
http://www.python.org/doc/current/lib/module-email.Message.html
Aside: one of the reasons why I want this behavior is because I'd like
the Message class (or a derived class possibly) to eventually enforce
RFC 2822 rules on the number of specific headers a message can have.
E.g. it can have many Received: headers, but only one Reply-To: header
(although the latter allows for multiple addresses... go figure).
I hope that helps,
-Barry
___
Mailman-Developers mailing list
[EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/mailman-developers
Re: [Mailman-Developers] Modifications to msg
At 02:05 PM 3/18/2002 -0800, Dan Mick wrote: >Question one: which version of mailman? The "message" class >changes drastically from 2.0.x to 2.1.x. Sorry to leave that out. I'm using Mailman 2.1a3 and Python 2.2c1. Ellen ___ Mailman-Developers mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-developers
[Mailman-Developers] Modifications to msg
I've been making some modifications to Mailman to support dynamic
sublists
(http://javamlm.mills.edu).
I'm still rather new with Python and have a question about modifying
fields (dictionary elements) of the msg data structure.
Specifically, I added the following code to change the message's
"To" field at the end of CookHeaders.py:
1 if msgdata.get('dlist'):
2 threadID =
msgdata['thread_id']
3 syslog('info', "threadID
= %d", threadID)
4 to_line = '%s-%d@%s' %
(mlist.real_name.lower(),
threadID,
mlist.host_name)
5 syslog('info', "to_line
= %s", to_line)
6 del msg['To']
7 msg['To'] = to_line
8 syslog('info', "Set
msg['To'] to '%s'", msg['To'])
This correctly changes the "To" field of the message from
etest-new@hostname to etest-@hostname, as shown by the
log:
Mar 18 13:29:55 2002 (4600) threadID = 19
Mar 18 13:29:55 2002 (4600) to_line = [EMAIL PROTECTED]
Mar 18 13:29:55 2002 (4600) Set msg['To'] to
'[EMAIL PROTECTED]'
Similarly, the resulting email message that is sent has the new 'To'
field.
The problem is I don't see why line 6 above is necessary. When I
comment it out, however, I get the incongruous logfile entry:
Mar 18 13:36:04 2002 (4640) threadID = 20
Mar 18 13:36:04 2002 (4640) to_line = [EMAIL PROTECTED]
Mar 18 13:36:04 2002 (4640) Set msg['To'] to
'[EMAIL PROTECTED]'
as though line 7 had never been executed. The final email
message contains two "To" headers, one with
"etest-new" and one with
"etest-". It's not clear to me why the
original value is preserved instead of overwritten. Could
someone let me know what I'm missing about dictionaries or the email
class?
Thank you.
Ellen Spertus
