>>>>> "JM" == James Madill <[EMAIL PROTECTED]> writes:
JM> Sendmail accepted the encoded document for Mailman, but on
JM> sending out, Mailman encountered what it thought was an EOM
JM> marker and stopped the processing of the message at that
JM> point. Unfortunately, there was still plenty of message left
JM> to send, so it was not removed from the queue, and Mailman
JM> kept on sending the first portion.
>>>>> "BG" == Ben Gertzfield <[EMAIL PROTECTED]> writes:
BG> Mailman 2.1 has an entirely re-written infrastructure for MIME
BG> message handling, and likely has fixed this bug (the old
BG> quoted-printable module had some serious flaws and has been
BG> re-written).
BG> If you could send us a copy of the naughty message, we could
BG> test it with Mailman 2.1 from CVS and let you know if the bug
BG> has been fixed, but I'll bet that it has been fixed now.
I'd still be very surprised if this ends up being a Mailman problem.
Python strings don't care at all about end-markers, NULs, etc. so you
can't put something in a string that would cause Python to shorten
it. And Mailman just uses the file object's read() method to suck the
message in from disk, and that just reads the whole file. On writing,
Mailman will hand the whole string over to the smtplib module, which
itself just blasts the whole thing down the socket connection.
I'm much more suspicious of the MTA or some other intermediary
bolluxing something up.
-Barry
_______________________________________________
Mailman-Developers mailing list
[EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/mailman-developers
