Looping digest - mailman bug?
Hi, On Wed, 20 Jun 2001 19:12:00 +0200, I wrote:
Last Monday, one of our mailing lists went mad and sent multiple copies of the same digest to the list's digest users.
[...]
The traceback in the errors log shows:
Jun 19 00:01:01 2001 (18618) Traceback (innermost last): File "/usr/local/mailman203/Mailman/Handlers/HandlerAPI.py", line 82, in do_pipeline func(mlist, msg, msgdata) File "/usr/local/mailman203/Mailman/Handlers/Sendmail.py", line 86, in process fp.write(msgtext) IOError: [Errno 32] Broken pipe
We run Mailman 2.0.3 with Postfix. I addressed this problem earlier (March 26th), but there was no reply.
Several of our lists suffered from Mailman's mail bombing and we turned the digest option off in hope it'll help. It did, for a while, until the same happened with a non-digest message being send over and over again (once per minute, by qrunner). We were able to locate where and how it happens, and to 'reproduce' the error (in laboratory conditions :-) both under mailman 2.0.3 and 2.0.6. The mail looping occurs when there is a MIME message with a single . (dot) in a line; Mailman sends it to sendmail 'as is'. But since sendmail/postfix interprets a line with single dot as the end of the message, it sends everything before the dot and exits with 'Broken pipe'. Mailman, however, still has the message in it's queue and sends it all over again... When I tried sending non-MIME message with single-dot-line in it to a Mailman list, there was no looping, but the message body after the single dot was missing. Until there is something better, I suggest adding to Sendmail.py a patch which perhaps is not pretty (it adds a space before the infamous dot), but it works: --- ./Mailman/Handlers/Sendmail.py.orig Fri Jul 27 13:40:31 2001 +++ ./Mailman/Handlers/Sendmail.py Fri Jul 27 14:11:46 2001 @@ -31,6 +31,7 @@ import string import os +import re import HandlerAPI from Mailman import mm_cfg @@ -80,6 +81,8 @@ msgtext = str(msg) # cycle through all chunks failedrecips = [] + bar = re.compile('\n\.') + msgtext = re.sub(bar, '\n .', msgtext, 0) for chunk in recipchunks: # TBD: SECURITY ALERT. This invokes the shell! fp = os.popen(cmd + chunk, 'w') Kaja
On Mon, Jul 30, 2001 at 07:09:47PM +0200, Kaja P. Christiansen wrote:
Until there is something better, I suggest adding to Sendmail.py a patch which perhaps is not pretty (it adds a space before the infamous dot), but it works:
--- ./Mailman/Handlers/Sendmail.py.orig Fri Jul 27 13:40:31 2001 +++ ./Mailman/Handlers/Sendmail.py Fri Jul 27 14:11:46 2001 @@ -31,6 +31,7 @@
import string import os +import re
import HandlerAPI from Mailman import mm_cfg @@ -80,6 +81,8 @@ msgtext = str(msg) # cycle through all chunks failedrecips = [] + bar = re.compile('\n\.') + msgtext = re.sub(bar, '\n .', msgtext, 0)
Sorry, this is the wrong fix. "\n." isn't the pattern that breaks it; you
want "\r?\n.\r?\n". And the proper escape of a single dot on a line is
doubling it (see the SMTP standard.) Barry, do you have a clue whether
msgtext is guaranteed (not) to have \r's (CR) in them ? If either is
guaranteed, we don't even need to use that ugly 're' module :)
--
Thomas Wouters
On Mon, 30 Jul 2001, Thomas Wouters wrote:
Sorry, this is the wrong fix. "\n." isn't the pattern that breaks it; you want "\r?\n.\r?\n". And the proper escape of a single dot on a line is doubling it (see the SMTP standard.) Barry, do you have a clue whether msgtext is guaranteed (not) to have \r's (CR) in them ? If either is guaranteed, we don't even need to use that ugly 're' module :)
RFC2822 requires CRLF to end a line, not just LF and not just CR. However there are many broken SMTP clients which ignore this requirement.
alex
On Mon, Jul 30, 2001 at 01:37:08PM -0700, alex wetmore wrote:
On Mon, 30 Jul 2001, Thomas Wouters wrote:
Sorry, this is the wrong fix. "\n." isn't the pattern that breaks it; you want "\r?\n.\r?\n". And the proper escape of a single dot on a line is doubling it (see the SMTP standard.) Barry, do you have a clue whether msgtext is guaranteed (not) to have \r's (CR) in them ? If either is guaranteed, we don't even need to use that ugly 're' module :)
RFC2822 requires CRLF to end a line, not just LF and not just CR. However there are many broken SMTP clients which ignore this requirement.
That's not the issue; IIRC, both the smtplib module (used by the SMTPDirect delivery in Mailman) as the Sendmail deliverer use CRLF's, adding CR's where necessary. (One of the very best reasons for a 'rich' standard library like Python's is strict compliance to the standards. Like you say, the CR/LF issue is ignored by so many mail-sending and -receiving applications, it's just not funny. By using smtplib, the burden gets lifted off your shoulders, and you do it 'correct' whether you want it or not :)
My question was whether the message text, at that moment, was guaranteed to contain CR's (or guaranteed not to contain them.) I'm not sure what kind of mangling Barry's mimelib does :)
-- Thomas Wouters thomas@xs4all.net
Hi! I'm a .signature virus! copy me into your .signature file to help me spread!
"TW" == Thomas Wouters thomas@xs4all.net writes:
TW> My question was whether the message text, at that moment, was
TW> guaranteed to contain CR's (or guaranteed not to contain
TW> them.) I'm not sure what kind of mangling Barry's mimelib does
TW> :)I don't think there are any hard guarantees, but certainly current practice seems to be for Unix MTAs to deliver the message locally to file or program with line endings canonicalized to LF only.
I actually think this is the right thing to do. Let the protocol specific module deal with massaging the data according to the spec, but let client code deal with it in a natural, albeit platform specific way.
mimelib doesn't do any explicit mangling of line endings. Parser uses fp.readline() and Generator uses the print command's implicit line ending behavior which should both adhere to the local line ending conventions.
-Barry
Thomas Wouters writes:
- bar = re.compile('\n\.')
- msgtext = re.sub(bar, '\n .', msgtext, 0)
Sorry, this is the wrong fix. "\n." isn't the pattern that breaks it; you want "\r?\n.\r?\n".
Not really; to be precise, "\n\.\n" is what breaks mail delivery. This was tested and confirmed in mailman lists using Sendmail delivery module, in standard installations of Sendmail 8.11.2 and Postfix 20010228-pl03 and on two different platforms: IRIX 6.5 vs. RedHat 6.2.
If a message contains MIME part (text/plain format) with "\n.\n" in it, it triggers the mail bombing. If there is no MIME, the message body is proccessed up to "\n.\.\n", the rest gets truncated.
That's not the issue; IIRC, both the smtplib module (used by the SMTPDirect delivery in Mailman) as the Sendmail deliverer use CRLF's, adding CR's where necessary.
CRLF's issues notwithstanding, looping digests has given much distress to many list members and the patch above prevents foul behaviour. If there is a better suggestion, I'll be greatful.
My question was whether the message text, at that moment, was guaranteed to contain CR's (or guaranteed not to contain them.)
Guaranteed not to contain CR's; I've saved a few of the 'bombing messages' and the single dot on a line is preceeded and followed by LF's.
This said, thanks to the Mailman team for the wonderful software; Mailman has been a great success for mailing lists for which I am responsible (on two different domains); which is the very reason for getting into this...
Kaja
On Wed, Aug 01, 2001 at 03:29:35PM +0200, Kaja P. Christiansen wrote:
Thomas Wouters writes:
- bar = re.compile('\n\.')
- msgtext = re.sub(bar, '\n .', msgtext, 0)
Sorry, this is the wrong fix. "\n." isn't the pattern that breaks it; you want "\r?\n.\r?\n".
Not really; to be precise, "\n\.\n" is what breaks mail delivery.
Yes. And "\r?\n\.\r?\n" matches that (I forgot to escape the . in my first reply :) Alright, the first '\r?' can be left out, but the second can't. Go ahead and try it; I'm pretty certain "\n.\r\n" will also break off the delivery.
Guaranteed not to contain CR's; I've saved a few of the 'bombing messages' and the single dot on a line is preceeded and followed by LF's.
That is no guarantee, unfortunately. That's empirical proof, which is the most treacherous sort around :) Unless you (or someone else) traced all code paths and see no way for any kind of input to case the message text at that point to contain CR's, I'd prefer to use "\n\.\r?\n", even though that means we have to use the 're' module instead of the 'string' one.
-- Thomas Wouters thomas@xs4all.net
Hi! I'm a .signature virus! copy me into your .signature file to help me spread!
Thomas Wouters writes:
Yes. And "\r?\n\.\r?\n" matches that (I forgot to escape the . in my first reply :) Alright, the first '\r?' can be left out, but the second can't. Go ahead and try it; I'm pretty certain "\n.\r\n" will also break off the delivery.
Yes, "\n.\r\n" breaks the delivery as well (with unpatched Sendmail.py).
Unless you (or someone else) traced all code paths and see no way for any kind of input to case the message text at that point to contain CR's, I'd prefer to use "\n\.\r?\n",
Given the alternative, I'd prefer it too :)
Kaja
"KPC" == Kaja P Christiansen kaja@daimi.au.dk writes:
KPC> Several of our lists suffered from Mailman's mail bombing and
KPC> we turned the digest option off in hope it'll help. It did,
KPC> for a while, until the same happened with a non-digest
KPC> message being send over and over again (once per minute, by
KPC> qrunner).
KPC> We were able to locate where and how it happens, and to
KPC> 'reproduce' the error (in laboratory conditions :-) both
KPC> under mailman 2.0.3 and 2.0.6.
KPC> The mail looping occurs when there is a MIME message with a
KPC> single . (dot) in a line; Mailman sends it to sendmail 'as
KPC> is'. But since sendmail/postfix interprets a line with single
KPC> dot as the end of the message, it sends everything before the
KPC> dot and exits with 'Broken pipe'. Mailman, however, still has
KPC> the message in it's queue and sends it all over again...
KPC> When I tried sending non-MIME message with single-dot-line in
KPC> it to a Mailman list, there was no looping, but the message
KPC> body after the single dot was missing.
KPC> Until there is something better, I suggest adding to
KPC> Sendmail.py a patch which perhaps is not pretty (it adds a
KPC> space before the infamous dot), but it works:Okay, several issues going on here. First, let me ask: why are you using Sendmail.py instead of SMTPDirect.py? The former has well known adverse security holes, including being able to trick the shell used during the os.popen() to do evil things. I include your mailbomb example as another security hole in Sendmail.py. I'm strongly considering removing Sendmail.py from MM2.1, but I want to know why some people seem to prefer to use it instead of SMTPDirect.py first.
I suspect the reason is because Sendmail tends to want to do recipient domain verification when invoked through smtp, even if the connection is through localhost, while connecting through "sendmail -bs" it does not. If that's the primary reason, then we have two choices: 1) document what Sendmail users should do in order to fix this problem in their MTA, or 2) dig up the patches to enhance smtplib.py to do sendmail -bs connections (I know there have been at least one such contribution, but I'd have to search around for it).
I really want everybody to use SMTPDirect.py from now on, so let's fix things so even the Sendmail.py'ers can.
"TW" == Thomas Wouters thomas@xs4all.net writes:
TW> Sorry, this is the wrong fix. "\n." isn't the pattern that
TW> breaks it; you want "\r?\n.\r?\n". And the proper escape of a
TW> single dot on a line is doubling it (see the SMTP standard.)
TW> Barry, do you have a clue whether msgtext is guaranteed (not)
TW> to have \r's (CR) in them ? If either is guaranteed, we don't
TW> even need to use that ugly 're' module :)Now, as to line endings and single-dot termination lines. Python's smtplib does the right thing here, and it fortunately hides everything from the module client. That's a big reason why SMTPDirect.py users never get into trouble; it uses smtplib. smtplib properly line terminates according to RFC 2821 regardless of the line termination of the source text. It also properly implements dot-line transparency according to $4.5.2.
On the receiving end, it appears that all the major Unix MTAs properly undo the dot-line escaping, and convert all line endings to Unix line endings (LF-only) before handing the text off to a program or file. I didn't find Postfix documentation on this, but testing and this message
http://archives.neohapsis.com/archives/postfix/2000-02/0686.htmlconfirm this to be the case. Exim has a configuration option "use_crlf" which controls this behavior, but since the default value is false, I'm guessing that most Exim installations canonicalize the line endings to Unix-style too. I suspect Sendmail does the same thing, although I haven't found a definitive description yet.
So I think it's fair to assume that by the time Mailman's wrapper gets a message, the line endings have all been converted to Unix-style LF termination.
So I think Thomas is right that we don't need re and can just check
for the first character being a .' and if so, quote it by adding a leading .'.
But I'm still more inclined to 1) zap Sendmail.py /and/ 2) merge support for sendmail -bs into smtplib.py
-Barry
Barry A. Warsaw writes:
Okay, several issues going on here. First, let me ask: why are you using Sendmail.py instead of SMTPDirect.py?
I have no weighty reason, I'm afraid. I experimented with both, in early Mailman installations, and recall that there was some problem with getting SMTPDirect to work; setup with Sendmail was fine so I settled for that.
The former has well known adverse security holes, including being able to trick the shell used during the os.popen() to do evil things. I include your mailbomb example as another security hole in Sendmail.py. I'm strongly considering removing Sendmail.py from MM2.1, but I want to know why some people seem to prefer to use it instead of SMTPDirect.py first.
I no longer have the older versions of Mailman, but current Defaults.py and Sendmail.py do have warning about perils. Maybe one could add it to README.SENDMAIL as well? It would make people stop and reconsider the setup.
Thank you for your letter. I made a test configuration of Mailman with SMTPDirect module and there was no trouble at all.
Kaja
participants (4)
-
alex wetmore -
barry＠zope.com -
Kaja P. Christiansen -
Thomas Wouters