Re: ATTN: Barbara Oncay

[Ken Irving <fnkci@uaf.edu>]

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