The problem seems to be of the "except in some situations" kind. It could be failing if the line is more than 78 characters or 998 octets, but this is not what you expect when you tell it to get rid of QP by supplying the -r8 option. I have some samples that are confidential so I will try and hand craft some that can reproduce the problem.
> -r8 > Like -r but also convert quoted-printable-encoded MIME sections to > 8bit. > -r8 does the same thing, but also converts quoted-printable-encoded > content to 8bit, except in some situations. Man page reformime(1) and HTML /usr/share/doc/maildrop/html/reformime.html I still think its a bug. The SMTP line length limit of 998 octets could just be ignored as you do with 8BITMIME when SMTP only talks plain old SMTP. Try and send it anyway. Historically SMTP parsed messages line at a time with buffer of say 1001 bytes. (The 1 at the end is for the '\0'.) However, if the buffer does not end with a '\n' and you simply sent on as is long lines are still correctly handled. You will still see the short line ".\r\n" that terminates DATA. The fact that long lines can't be read is a human, not an MTA issue. With humans the limit is 80 characters for Western and possibly only 40 for CJK. If our ".\r\n" started at 1000 then we might then erroneously terminate DATA. Could guard this with a flag set from previous "line". > RFC 821 prohibits lines longer than 998 bytes, and requires that all > servers be able to accept 998-byte lines. In practice, users sometimes > send longer lines. http://cr.yp.to/smtp/message.html The problem is that those users conceal their unreadable email from the filter with QP. The old 8BITMIME is just sent anyway with plain old SMTP. http://cr.yp.to/smtp/8bitmime.html All 8BITMIME tells you to do is append the BODY=8BITMIME to the MAIL command if you have any 8bit DATA. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
