Re: ATTN: Barbara Oncay
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, hendrik@topoi.pooq.com 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
Reply to: