On Sat, Apr 15, 2006 at 12:28:25AM -0400, Gene Heskett wrote: > On Friday 14 April 2006 21:57, Ken Irving wrote: > >On Fri, Apr 14, 2006 at 01:11:20PM -0400, [EMAIL PROTECTED] wrote: > >> This is not the first time I've seen an argument about whether a > >> specific message had the unsubscribe tag-line appended to it. > >> There would seem to be confused mail clients out there that cut off > >> the signature if there is also a PGP key. Does anyone know which > >> ones? > > > >IMHO the confused clients must be the ones showing the tag-line. ;-) > > > >I think the pgp thing is a red (pink?) herring; the effect is actually > > due to MIME encoding, which pgp messages use, as do other messages. > > I think you are correct. The answer I haven't looked up yet, is what is > an email agent supposed to do with 2 or 3 extra text lines that are > below the end marker of the mimetype? IMO it should fall back to plain > text mode and display it, but what does the actual rfc say about such a > situation?
This page links to several rfcs, http://www.livinginternet.com/e/ea_att_mime.htm dealing with MIME. From rfc1341: In the case of multiple part messages, in which one or more different sets of data are combined in a single body, a "multipart" Content-Type field must appear in the entity's header. The body must then contain one or more "body parts," each preceded by an encapsulation boundary, and the last one followed by a closing boundary. ... ... There appears to be room for additional information prior to the first encapsulation boundary and following the final boundary. These areas should generally be left blank, and implementations should ignore anything that appears before the first boundary or after the last one. NOTE: These "preamble" and "epilogue" areas are not used because of the lack of proper typing of these parts and the lack of clear semantics for handling these areas at gateways, particularly X.400 gateways. If the message is identified as "multipart" in the header, then it's not supposed to revert to a flat body model. It probably could be "recommended" to work that way, but it doesn't appear to be. > > And, how much screwing around would it be to make the listserver actualy > wrap it with the proper mimetype declaration? The SmartList (used for the debian lists) FAQ ends with: 8.13: Why are MIME and HTML emails a problem for SmartList? This FAQ entry originated in a discussion about problems with embedding X-Commands in the body of a MIME formatted message. ... The exact same type of trouble arises when you want to add a custom message heading or footer to the body of a message. ... ... Hans-Albert Schneider, by way of Martin Mokrejs contributed this useful explanation of why X-Commands from the message body won't work if the email is divided into MIME segments! This is because MIME segments create extra blank lines between the header and the body; something like this: ... Body heading: Text inserted by recipes immediately after the first blank line (i.e. at the start of the body if the message were a regular text email) won't show up because it's before the first MIME separator, and thus doesn't belong to any of the MIME message parts. You'd need to properly determine which MIME sections to modify and which to leave alone (e.g. leave all attachments and binaries alone). Then you'd need to figure out how to parse each segment to be modified, and insert the text appropriately, e.g. as html before the closing html tag in the html section, and just as text in the text section. Very messy. Probably possible if you're good with perl and understand the MIME format, and if all of your submitters use proper MIME formatting email clients. God save you if someone decides to post the newsletter as a word doc. Body footer: Similar to the previous case, but here the text is injected after the final MIME separator, and so again doesn't belong to any of the MIME message parts. A proper MIME-aware text insertion recipe would have to know how to modify ALL of the text message segments without touching any message segments which contain non-message text data, e.g. attachments. So it looks like it means fixing something, somewhere. -- Ken Irving -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
