Mailman 3 Reply-To: handling - Mailman-Developers

Reply-To: handling

J C Lawrence

19 Oct 2001 19 Oct '01

7:34 p.m.

I've been reading RFC 2822 on the subject of Reply-To and noticed that the content of Reply-To is a list. ie you can have more than one address listed under a Reply-To:

reply-to = "Reply-To:" address-list CRLF address-list = (address *("," address)) / obs-addr-list address = mailbox / group mailbox = name-addr / addr-spec name-addr = [display-name] angle-addr angle-addr = [CFWS] "<" addr-spec ">" [CFWS] / obs-angle-addr group = display-name ":" [mailbox-list / CFWS] ";" [CFWS] display-name = phrase mailbox-list = (mailbox *("," mailbox)) / obs-mbox-list

eg:

Reply-To: list@foo.conm, list@bar.com, claw@kanga.nu

This would seem to potentially remove one of the complaints on Reply-To: lists -- that they nix/kill crossposting, and lose the actual semantic value of the original Reply-To header.

Ergo, if a given list is configured to do reply-To munging and it receives a message with Reply-To set, then it makes sense to _ADD_ the list's address to the Reply-To: header if present, rather than replacing it.

-- J C Lawrence ---------(*) Satan, oscillate my metallic sonatas. claw@kanga.nu He lived as a devil, eh? http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live.

Show replies by date

Jay R. Ashworth

19 Oct 19 Oct

7:39 p.m.

On Fri, Oct 19, 2001 at 12:34:05PM -0700, J C Lawrence wrote:

...

I've been reading RFC 2822 on the subject of Reply-To and noticed that the content of Reply-To is a list. ie you can have more than one address listed under a Reply-To:

reply-to = "Reply-To:" address-list CRLF address-list = (address *("," address)) / obs-addr-list address = mailbox / group mailbox = name-addr / addr-spec name-addr = [display-name] angle-addr angle-addr = [CFWS] "<" addr-spec ">" [CFWS] / obs-angle-addr group = display-name ":" [mailbox-list / CFWS] ";" [CFWS] display-name = phrase mailbox-list = (mailbox *("," mailbox)) / obs-mbox-list

eg:

Reply-To: list@foo.conm, list@bar.com, claw@kanga.nu

This would seem to potentially remove one of the complaints on Reply-To: lists -- that they nix/kill crossposting, and lose the actual semantic value of the original Reply-To header.

Ergo, if a given list is configured to do reply-To munging and it receives a message with Reply-To set, then it makes sense to _ADD_ the list's address to the Reply-To: header if present, rather than replacing it.

Assuming that mailers correctly handle such a Reply-to.

And note that this message arrived here with no To: header, FWIW.

Cheers, -- jra

Jay R. Ashworth jra@baylink.com Member of the Technical Staff Baylink RFC 2100 The Suncoast Freenet The Things I Think Tampa Bay, Florida http://baylink.pitas.com +1 727 804 5015

"Usenet: it's enough to make you loose your mind." -- me

barry＠zope.com

9:15 p.m.

...

...
...
...
...
"JCL" == J C Lawrence claw@2wire.com writes:

JCL> Ergo, if a given list is configured to do reply-To munging
JCL> and it receives a message with Reply-To set, then it makes
JCL> sense to _ADD_ the list's address to the Reply-To: header if
JCL> present, rather than replacing it.

VM/XEmacs does the right thing too, with both Reply-To: that contains multiple addresses, and multiple Reply-To: headers in the original message.

I'll rework the munging code for the next alpha to augment the header instead of replacing it. It would be easier to simply add a new Reply-To: header. Can you guys check to see if multiple Reply-To: headers are honored too?

-Barry

J C Lawrence

9:37 p.m.

On Fri, 19 Oct 2001 17:15:29 -0400 Barry A Warsaw barry@zope.com wrote:

...

...
...
...
...
...
"JCL" == J C Lawrence claw@2wire.com writes:

JCL> Ergo, if a given list is configured to do reply-To munging and JCL> it receives a message with Reply-To set, then it makes sense to JCL> _ADD_ the list's address to the Reply-To: header if present, JCL> rather than replacing it.

...

VM/XEmacs does the right thing too, with both Reply-To: that contains multiple addresses, and multiple Reply-To: headers in the original message.

If I'm reading it correctly, multiple Reply-To headers violates RFC 2822. The fact that VM supports it is fine, but that doesn't mean Mailman should emit it.

Be generous in what your accept and conservative and what you emit.

...

I'll rework the munging code for the next alpha to augment the header instead of replacing it. It would be easier to simply add a new Reply-To: header. Can you guys check to see if multiple Reply-To: headers are honored too?

Note: Need to make sure you do duplicate collapsing of the Reply-To header in case the poster has already set Reply-To to the list in effort to nix CC: dupes.

-- J C Lawrence ---------(*) Satan, oscillate my metallic sonatas. claw@kanga.nu He lived as a devil, eh? http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live.

barry＠zope.com

9:44 p.m.

...

...
...
...
...
"JCL" == J C Lawrence claw@2wire.com writes:

JCL> If I'm reading it correctly, multiple Reply-To headers
JCL> violates RFC 2822.  The fact that VM supports it is fine, but
JCL> that doesn't mean Mailman should emit it.

You're right of course, see section 3.6:

Field           Min number      Max number      Notes
reply-to        0               1

(I'm battling a cold and lack of sleep so apologies for having been lazy about looking it up.)

JCL> Note: Need to make sure you do duplicate collapsing of the
JCL> Reply-To header in case the poster has already set Reply-To
JCL> to the list in effort to nix CC: dupes.

Are you suggesting that we collapse Reply-To: even if we don't add one ourselves? I would think that we should only collapse if we're adding a value.

-Barry

Chuq Von Rospach

9:54 p.m.

New subject: Mailman and cookies.

Ran into a fun one the other day. I came to work, tried to log onto one of my lists, and started getting server errors out of the web server. Mailman was broken.

So I immediately went to my assistant to see if he'd changed anything -- and it was working for him. Borrowed a co-worker's computer, and sure enough, the system was working fine, except when I tried to use it.

Restarted the browser. Nothing. Cleared the cache. Rebooted my desktop. Restarted the web server.

After 20 minutes or so, I finally tracked it down. Some other site at apple had lodged a cookie in my browser. When Mailman tried to read my cookies to validate my browser, it was causing the admin CGI to core dump.

This is bad on any number of levels. Mailman 2.0.5 isn't reading cookies right; it seems to be making assumptions about what will be there. The cookie (no, I don't have details about what was IN it) was set to "apple.com". Why that would affect a program reading cookies for www.lists.apple.com, I dunno.

But it ALSO bothers me that I can create a cookie that not only affects mailman, but causes the CGI to core-dump. IT seems to me there's a serious opportunity for havoc.

Barry, I think you need to take a look at your cookie code, and look for ways to bullet-proof it. It seems to have some assumptions that I found out the hard way aren't safe.

barry＠zope.com

10:08 p.m.

New subject: Mailman and cookies.

...

...
...
...
...
"CVR" == Chuq Von Rospach chuqui@plaidworks.com writes:

CVR> After 20 minutes or so, I finally tracked it down. Some other
CVR> site at apple had lodged a cookie in my browser. When Mailman
CVR> tried to read my cookies to validate my browser, it was
CVR> causing the admin CGI to core dump.

Core dumped, right? Not caused a traceback?

Python's like any other interpreted or byte compiled language: in theory you should never be able to write pure Python code that can crash the interpreter. Such a situation is by definition a bug in the interpreter.

Are you running Python 1.5.2? I vaguely recall that it was possible to crash Python with some sequence of cookie data.

[quick google search...]

Here's an article in the middle of a thread about this on the Python mailing list. It contains a patch (which I can't vouch for).

http://mail.python.org/pipermail/python-list/1999-July/006953.html

Note the date. :)

Suggestions:

upgrade Python to 2.1.1 and Mailman to 2.0.6.
apply the patch suggested above and see if the crashes go away.

-Barry

Chuq Von Rospach

10:16 p.m.

New subject: Mailman and cookies.

On 10/19/01 3:08 PM, "Barry A. Warsaw" barry@zope.com wrote:

...

Core dumped, right? Not caused a traceback?

Correct. Left a corefile.

...

Are you running Python 1.5.2? I vaguely recall that it was possible to crash Python with some sequence of cookie data.

Yes. Haven't updated yet. Haven't needed to...

...

upgrade Python to 2.1.1 and Mailman to 2.0.6.

apply the patch suggested above and see if the crashes go away.

Thanks. Ahead of the game again, I see.

barry＠zope.com

11:24 p.m.

New subject: Mailman and cookies.

...

...
...
...
...
"CVR" == Chuq Von Rospach writes:

CVR> Barry, I think you need to take a look at your cookie code, CVR> and look for ways to bullet-proof it. It seems to have some CVR> assumptions that I found out the hard way aren't safe. This patch against Mailman 2.0.6 should be enough to prevent the core dumps. If you haven't completed your upgrade yet, can you give it a try? -Barry -------------------- snip snip -------------------- Index: SecurityManager.py =================================================================== RCS file: /cvsroot/mailman/mailman/Mailman/SecurityManager.py,v retrieving revision 1.31.2.1 diff -u -r1.31.2.1 SecurityManager.py --- SecurityManager.py 2001/07/25 18:07:51 1.31.2.1 +++ SecurityManager.py 2001/10/19 23:23:12 @@ -118,7 +118,7 @@ cookiedata = os.environ.get('HTTP_COOKIE') if not cookiedata: return 0 - c = Cookie.Cookie(cookiedata) + c = Cookie.Cookie(cookiedata, net_setfunc=lambda x: x) if not c.has_key(key): return 0 # Undo the encoding we performed in MakeCookie() above

Marc MERLIN

24 Oct 24 Oct

12:10 a.m.

New subject: Mailman and cookies.

On Fri, Oct 19, 2001 at 07:24:52PM -0400, Barry A. Warsaw wrote:

...

...
...
...
...
...
"CVR" == Chuq Von Rospach writes:

CVR> Barry, I think you need to take a look at your cookie code, CVR> and look for ways to bullet-proof it. It seems to have some CVR> assumptions that I found out the hard way aren't safe.

This patch against Mailman 2.0.6 should be enough to prevent the core dumps. If you haven't completed your upgrade yet, can you give it a try?

I've the same cookie problems than chuck except that mm's admin interface returns a 500 error (no core dump, I have python 1.5.2) Would that patch fix the failures in the admin script when a bad cookie shows up?

...

-------------------- snip snip -------------------- Index: SecurityManager.py =================================================================== RCS file: /cvsroot/mailman/mailman/Mailman/SecurityManager.py,v retrieving revision 1.31.2.1 diff -u -r1.31.2.1 SecurityManager.py --- SecurityManager.py 2001/07/25 18:07:51 1.31.2.1 +++ SecurityManager.py 2001/10/19 23:23:12 @@ -118,7 +118,7 @@ cookiedata = os.environ.get('HTTP_COOKIE') if not cookiedata: return 0 - c = Cookie.Cookie(cookiedata) + c = Cookie.Cookie(cookiedata, net_setfunc=lambda x: x) if not c.has_key(key): return 0 # Undo the encoding we performed in MakeCookie() above

_______________________________________________ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers

-- Microsoft is to operating systems & security .... .... what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ | Finger marc_f@merlins.org for PGP key

barry＠zope.com

25 Oct 25 Oct

6:17 a.m.

New subject: Mailman and cookies.

...

...
...
...
...
"MM" == Marc MERLIN marc_news@valinux.com writes:

MM> I've the same cookie problems than chuck except that mm's
MM> admin interface returns a 500 error (no core dump, I have
MM> python 1.5.2)

MM> Would that patch fix the failures in the admin script when a
MM> bad cookie shows up?

Interesting. I wonder why you don't get a segfault. Could be your platform is a bit more resilient about the corrupted memory? Or maybe you /are/ segfaulting, but you've got core size limits or other restrictions preventing the writing of a core file. Then your web server catches Python's crash and turns it into a 500 error? I forget what an HTTP 500 code is (and can't look it up right now).

When bad cookie data shows up, you obviously won't be able to log in.

The patch will prevent Cookie.py from trying to unpickle the seemingly random string stored in the cookie value. That string isn't a pickle so there's no need to avail ourself of Cookie.py's, er, convenience here.

-Barry

Marc MERLIN

6:02 p.m.

New subject: Mailman and cookies.

On Thu, Oct 25, 2001 at 02:17:35AM -0400, Barry A. Warsaw wrote:

...

Interesting. I wonder why you don't get a segfault. Could be your platform is a bit more resilient about the corrupted memory? Or maybe you /are/ segfaulting, but you've got core size limits or other restrictions preventing the writing of a core file. Then your web

You are probably right.

...

server catches Python's crash and turns it into a 500 error? I forget what an HTTP 500 code is (and can't look it up right now).

Let's see my original report of this problem was: http://mail.python.org/pipermail/mailman-developers/2001-September/009568.ht...

and once I looked in my server logs and found: [Thu Jul 12 15:47:17 2001] [error] [client 171.71.41.31] Premature end of
script headers: /var/local/mailman/cgi-bin/admin

That would be consistent with python segfaulting.

...

The patch will prevent Cookie.py from trying to unpickle the seemingly random string stored in the cookie value. That string isn't a pickle so there's no need to avail ourself of Cookie.py's, er, convenience here.

It seems that it will solve my problem too. Thanks. (I won't be able to tell right away, because I can't reproduce it myself and I only get a report of this every so often, out of thousands of list admins)

Marc

Microsoft is to operating systems & security .... .... what McDonalds is to gourmet cooking

Home page: http://marc.merlins.org/ | Finger marc_f@merlins.org for PGP key

barry＠zope.com

26 Oct 26 Oct

4:24 a.m.

New subject: Mailman and cookies.

...

...
...
...
...
"MM" == Marc MERLIN marc_news@valinux.com writes:

MM> It seems that it will solve my problem too. Thanks.  (I won't
MM> be able to tell right away, because I can't reproduce it
MM> myself and I only get a report of this every so often, out of
MM> thousands of list admins)

Cool, let me know how it goes.

I really don't want to release a MM2.0.7, and Python 1.5.2 is sooo old that I definitely recommend upgrading (if and when your resources allow you to).

What I have done though is uploaded a patch to the SF files page

http://sourceforge.net/project/showfiles.php?group_id=103&release_id=45268

that contains the fix for crashes under Python 1.5.2. Once the SF file release delay expires I'll send a message out about this patch on the mailman-* lists.

-Barry

J C Lawrence

19 Oct 19 Oct

10:21 p.m.

On Fri, 19 Oct 2001 17:44:29 -0400 Barry A Warsaw barry@zope.com wrote:

...

Field Min number Max number Notes reply-to 0 1

Thanks.

...

Are you suggesting that we collapse Reply-To: even if we don't add one ourselves?

No. I specifically think we should collapse duplicate list addresses in the Reply-To. Duplicate other addresses in the Reply-To are likely not good, but are also not our responsibility.

Note: This does expose an abuse vector:

I don't like Bubba.

I send a troll to a busy list with Reply-To set to Bubba.

Bubba is inundated with unwanted mail.

There is little/nothing Bubba can do about it.

I get away clean.

This abuse vector currently exists for non-reply-to munging lists. The only difference is that with the change I'm advocating is that it now also exists for reply-to munging lists where it didn't before.

Its easy to view this as either a Good or Bad Thing. I side on adding to any extant Reply-To being a Good Thing in balance.

...

I would think that we should only collapse if we're adding a value.

Agreed.

-- J C Lawrence ---------(*) Satan, oscillate my metallic sonatas. claw@kanga.nu He lived as a devil, eh? http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live.

Chuq Von Rospach

10:32 p.m.

On 10/19/01 3:21 PM, "J C Lawrence" claw@2wire.com wrote:

...

Note: This does expose an abuse vector:

I don't like Bubba.

I send a troll to a busy list with Reply-To set to Bubba.

Aka the "set your followup to /dev/null" on usenet hack.

I'm of the opinion, and I don't expect to be in the majority, that "reply-to" should not transport through a mail list. Either the mail list replaces it with a list-centric one, or it deletes it.

The only people overtly screwed over by this are the people who insist on mailing from one address and getting you to reply elsewhere. Something like:

From: chuq@apple.com Subject: spoofed headers! To: mailman-developers@python.org Reply-to: chuqles-da-clown@hotmail.com

Which is a lame attempt (IMHO) to use a single subscribed address from multiple places, which I don't think should be encouraged anyway (instead use the NOMAIL hack, dammit! grin. The real answer are aliases attached to a subscripiton)

My argument is that when I send mail to the list, the list processes it and then sends out a new message that my message is the basis of it. At that point, the original reply-to is no longer valid, it's what the list software says should happen that matters. As the bubba-hack shows, to NOT do this opens up lists to abuse in not-necessarily-obvious ways, and worse, you leave things in ambiguous states, depending on factors most users don't understand. Lists act differently based on whether it reply-to coerces and whether the original poster coerces reply-to, and you have the issue of which coerced reply-to 'wins'.

How is the typical user to understand how this all works together, and why when they reply to a list, this happens, except when it's fred's message?

It seems from a consistency's sake, the MLM ought to handle this stuff unambiguously, which means ONLY mailman's reply-to (or lack of it) ought be be propogated.

Jay R. Ashworth

20 Oct 20 Oct

4:56 a.m.

On Fri, Oct 19, 2001 at 02:37:40PM -0700, J C Lawrence wrote:

...

...
VM/XEmacs does the right thing too, with both Reply-To: that contains multiple addresses, and multiple Reply-To: headers in the original message.

If I'm reading it correctly, multiple Reply-To headers violates RFC 2822. The fact that VM supports it is fine, but that doesn't mean Mailman should emit it.

If multiple headers are not supported, then I submit that we should assume that a multi address Reply-to may well be a bug in the spec; other address headers may appear multiple times, may they not?

I'd go read 2822, but I'm too damned tired<tm>.

Cheers, -- jra

Jay R. Ashworth jra@baylink.com Member of the Technical Staff Baylink RFC 2100 The Suncoast Freenet The Things I Think Tampa Bay, Florida http://baylink.pitas.com +1 727 804 5015

"Usenet: it's enough to make you loose your mind." -- me

John W Baxter

8:47 p.m.

At 0:56 -0400 10/20/2001, Jay R. Ashworth wrote:

...

If multiple headers are not supported, then I submit that we should assume that a multi address Reply-to may well be a bug in the spec; other address headers may appear multiple times, may they not?

No more a bug than the legal multi-address From: header. This was for something like a secretary sending a message "from" her boss and herself, IIRC.

...

I'd go read 2822, but I'm too damned tired<tm>.

At least I think it's still legal (tossed in just in case 2822 changed things).

--John

John Baxter jwblist@olympus.net Port Ludlow, WA, USA

Jay R. Ashworth

11:20 p.m.

On Sat, Oct 20, 2001 at 01:47:54PM -0700, John W Baxter wrote:

...

At 0:56 -0400 10/20/2001, Jay R. Ashworth wrote:

...
If multiple headers are not supported, then I submit that we should assume that a multi address Reply-to may well be a bug in the spec; other address headers may appear multiple times, may they not?

No more a bug than the legal multi-address From: header. This was for something like a secretary sending a message "from" her boss and herself, IIRC.

I had been talking about mulitple headers; it appears *no* (address) header may appear more than once.

As it happens, Mutt appears not to deal well at all with it: .88e (which is what I can get mail to) just doesn't reply to anyone.

I have 1.2.5 on my laptop, but I can't conveniently get mail to it to test.

Cheers, -- jra

Jay R. Ashworth jra@baylink.com Member of the Technical Staff Baylink RFC 2100 The Suncoast Freenet The Things I Think Tampa Bay, Florida http://baylink.pitas.com +1 727 804 5015

"Usenet: it's enough to make you loose your mind." -- me

8217

Age (days ago)

8224

Last active (days ago)

List overview

Download

17 comments

6 participants

participants (6)

barry＠zope.com
Chuq Von Rospach
J C Lawrence
Jay R. Ashworth
John W Baxter
Marc MERLIN

Reply-To: handling

J C Lawrence

Cheers, -- jra

J C Lawrence

Chuq Von Rospach

Chuq Von Rospach

Marc MERLIN

Marc MERLIN

Marc

J C Lawrence

Chuq Von Rospach

Cheers, -- jra

John W Baxter

--John

Cheers, -- jra

tags

participants (6)