I *think* I found two (more) bugs in Mailman, but my setup is sufficiently hacked that I can't test it for sure. One of the two I tested on python-list, and I think I saw it reproduced. The other one I'm not going to test, because it's potentially destructive.
Subscription-confirmation-response-emails to *-request, with multiple attachements, fail. The problem is that Mailman tries to interpret the MIME boundary and content-type headers and what not as commands, rather than taking the first attachement and parsing that. This wasn't a real problem when I tested it on python-list, because my mailer doesn't put enough headers in the first MIME part, but customers of ours have seen honest problems with this. People mailing with HTML mail enabled, for instance, but also people who get a signature attached to the email, without being able to prevent it. This enforced signature is becoming more and more populair in clueless paranoid companies :P
'\n.\n' screws up Mailman. This comes in two flavours :) If the '\n.\n' sequence is late enough in the email, Mailman doesn't notice, and the rest of the mail (including the '\n.\n') silently vanishes. If the sequence is a bit higher, Mailman does notice: sendmail stops the transmission while Mailman still has data to send. Mailman considers the mail not sent, and tries again later -- but the first part of the mail is sent to all recipients just fine.
This is a problem in particular with digests. One of our employees found out she could skip the mailman-enforced signature by adding '\n.\n' to the end of her own signature. She forgot about digests, however, and 5 other employees got 300+ copies of the start of each digest, up to her signature. Obviously, I don't want to test this on python.org's lists, unless Barry or someone else is ready to edit the qfiles to remove the '\n.\n' sequence. Is there a mailman-test-list on python.org or some 'vanilla' installation that this could be tested on ?
-- Thomas Wouters <thomas@xs4all.net>
Hi! I'm a .signature virus! copy me into your .signature file to help me spread!
At 11:11 AM +0100 12/12/00, Thomas Wouters wrote:
- '\n.\n' screws up Mailman. This comes in two flavours :) If the '\n.\n' sequence is late enough in the email, Mailman doesn't notice, and the rest of the mail (including the '\n.\n') silently vanishes.
that's because that's a standard end of message delimiter in the SMTP protocols. It may not even be Mailman, but the MTA.
This is a problem in particular with digests.
yes, it's related to one I found, where ^@ (NUL) does the same, because it also is read as an End of File flag, so the digest truncates. But the one you have is actually part of the SMTP standards, so at some level, the answer is "don't do that", I think, or disable it in your MTA configuration. I know it can be turned off in sendmail, but don't remember the command offhand.
-- Chuq Von Rospach - Plaidworks Consulting (mailto:chuqui@plaidworks.com) Apple Mail List Gnome (mailto:chuq@apple.com)
We're visiting the relatives. Cover us.
"TW" == Thomas Wouters <thomas@xs4all.net> writes:
TW> 1) Subscription-confirmation-response-emails to *-request,
TW> with multiple attachements, fail. The problem is that Mailman
TW> tries to interpret the MIME boundary and content-type headers
TW> and what not as commands, rather than taking the first
TW> attachement and parsing that. This wasn't a real problem when
TW> I tested it on python-list, because my mailer doesn't put
TW> enough headers in the first MIME part, but customers of ours
TW> have seen honest problems with this. People mailing with HTML
TW> mail enabled, for instance, but also people who get a
TW> signature attached to the email, without being able to prevent
TW> it. This enforced signature is becoming more and more populair
TW> in clueless paranoid companies :PThe standard MIME parsing modules in Python suck. I want to fix this for 2.1, but haven't yet had time. mimectl might be the way to go, but I also think I want a DOM-like approach so I can slice and dice MIME messages, then just say "okay, spit out the results".
TW> 2) '\n.\n' screws up Mailman. This comes in two flavours :) If
TW> the '\n.\n' sequence is late enough in the email, Mailman
TW> doesn't notice, and the rest of the mail (including the
TW> '\n.\n') silently vanishes. If the sequence is a bit higher,
TW> Mailman does notice: sendmail stops the transmission while
TW> Mailman still has data to send. Mailman considers the mail not
TW> sent, and tries again later -- but the first part of the mail
TW> is sent to all recipients just fine.Hmm, a simplistic approach on my personal test lists, using a rather stock Postfix doesn't seem to suffer from this. I have a couple of test lists floating around on various domains, although I think they all use Postfix. Thomas, I'll email you separately and you can try some things out.
-Barry
At 10:54 PM -0500 12/14/00, Barry A. Warsaw wrote:
The standard MIME parsing modules in Python suck. I want to fix this for 2.1, but haven't yet had time. mimectl might be the way to go, but I also think I want a DOM-like approach so I can slice and dice MIME messages, then just say "okay, spit out the results".
please, do, because it falls right in place with tw things I'm grappling with -- the auto-moderation/anti-spam stuff (initial design ideas coming soon, honest!) and my active filter content stuff, so I can integrate what de-mime does for me with greater granularity (and since htere are now viruses in shockwave, I hate to say "I was right", but -- I was right. it's not just .exe or virtual basis or word macros, but any active content has to be screened...
-- Chuq Von Rospach - Plaidworks Consulting (mailto:chuqui@plaidworks.com) Apple Mail List Gnome (mailto:chuq@apple.com)
We're visiting the relatives. Cover us.
participants (3)
-
barry＠digicool.com -
Chuq Von Rospach -
Thomas Wouters