Package: altermime Version: 0.3.x Severity: important
it appears on several systems we maintain that emails being sent with (at least) MS Outlook that are html formatted may arrive incomplete. the issue was brought to our attention because more and more users of a particular system got emails that seemed to have a file attached, but the attachment vanished in the mua the very moment they would click on it. when tracking the problem down you can see in the logfile that the email comes in with a certain size, but it is significantly smaller after being piped through dfilt. originally we suspected amavis, later altermime itself, but the we discovered that even emails that won't be treated by altermime because they arrived from "outside" get ripped apart. on systems that have 2 interfaces the issue is less likely to happen, but if you have a box that is static natted, with a single interface, all mail is piped through dfilt (as declared in the postfix master.cf). we uncommented the trap line to keep the in.$$ files to see if they are already broken when being read. they were intact, so we wrote the parameters into a logfile right before $SENDMAIL is called at the end of the script. we used an in.$$ file we kept before that was received as incomplete email. we compared the resulting mail to the complete file read into the disclaimer script to see where exactly the the mail had been cut. when sending an email that is Content-Type: multipart/mixed it can happen under certain circumstances that the mail is formatted in a way that a dot that seems to be at the end of a line (when looking at it in the mua) appears on the following line, being the only character. the sendmail wrapper that comes with postfix interpretes that as the end of the mail and strips everything that comes after that. there is a flag for postfix ( -oi) that ignores single dots on a line. the postfix documentation says that the behaviour while reading a message from stdin (either EOF or a single dot on a line) is standard, so we had to add the -io flag to the $SENDMAIL command at the end of the disclaimer script: $SENDMAIL "$@" <in.$$ becomes $SENDMAIL -oi "$@" <in.$$ after that we were able to get the incorrect formatted email through the disclaimer script. the script example should contain the -oi flag by default, since this type of mail is likely to appear more often these days, and people setting up altermime with the help of the examples will run into this issue, for sure. thus, we suggest the examples and the documentation to include hints on that behaviour. since it appears that the documentation of the flag is missing in etch (our testing victim), lenny and sid as well, it doesn't apply to a particular distribution. -- System Information: Debian Release: 5.0.4 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.26-2-686 (SMP w/2 CPU cores) Locale: LANG=en_US.ISO-8859-15, LC_CTYPE=en_US.ISO-8859-15 (charmap=ISO-8859-15) Shell: /bin/sh linked to /bin/bash Versions of packages altermime depends on: ii libc6 2.7-18lenny2 GNU C Library: Shared libraries ii sendmail-bin [mail-trans 8.14.3-5+lenny1 powerful, efficient, and scalable altermime recommends no packages. altermime suggests no packages. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
