"Neil Durant" <[EMAIL PROTECTED]> wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> Jacek Piskozub <[EMAIL PROTECTED]> writes
> >Peter Lairo wrote:
> >
> >> Gervase Markham wrote:
> >
> >>> b) A signature appears at the end of a document, by analogy with paper
> >>> documents. Everyone knows that.
> >> No, in all of our reports, the signature comes after the report
> >>text, THEN come the supporting documents (tables, lab analyses,
> >>copies of coorespondence, etc.).
> >
> >Well, attachments do come after the signature. I see no problem here.
>
> According to the RFCs, attachments should be able to be inserted
> anywhere in the document, so you should be able to say something like,
> "Here's the spreadsheet I was telling you about", followed by an
> attachment, and then "And this is a relevant graph", followed by another
> attachment.
>
> Sadly a lot of non-fully-RFC compliant email/news software mistakenly
> assumes attachments come at the end, so for example with Outlook
> Express, if it finds an attachment followed by some more text, that text
> appears an a second attachment!
>
> By all means force outgoing attachments to be put at the end by the
> software, if preferred, but mail/news clients should be able to
> interleave body text and attachments for incoming messages if they are
> to comply with the RFCs.
It's called an "inline attachment". There's an optional
MIME header "Content-Disposition:" that is used to
determine whether the content should be displayed
inline with the basic message view or separately as
an attachment.
>From RFC 2183:
> 2.1 The Inline Disposition Type
>
> A bodypart should be marked `inline' if it is
> intended to be displayed automatically upon display
> of the message. Inline bodyparts should be presented
> in the order in which they occur, subject to the normal
> semantics of multipart messages.
Note that last sentence. Mailers that ignore the
Content-Disposition header display text following the inline
attachment as attachments because they really are
attachments...they're separate from the initial main body
text. The inline attachments aren't "interleaved with the
main body text", they follow the main body text and can
be themselves followed by additional inline attachments
(which may be text).
And for completeness' sake:
> 2.2 The Attachment Disposition Type
>
> Bodyparts can be designated `attachment' to indicate
> that they are separate from the main body of the mail
> message, and that their display should not be
> automatic, but contingent upon some further action of
> the user. The MUA might instead present the user of a
> bitmap terminal with an iconic representation of the
> attachments, or, on character terminals, with a list of
> attachments from which the user could select for viewing
> or storage.
Unfortunately, none of the RFCs really address sigs in the
context of MIME format: they don't say whether sigs must
appear at the end of the main body text, or if they may
appear in inline attachments, so you have to go by how the
majority of mailers/newsreaders interpret it. In my experience,
the sig tends to get put in the first section of the body (main
body text) and attachments follow. That also seems to be safe
(that is, I haven't seen a mailer strip an inline text attachment
because it follows a sigdash in the main body).
Son-of-RFC 1036 mentions that work is being done on a MIME
based signature scheme (a note in section 4.3.2):
> NOTE: The choice of delimiter is somewhat unfortunate,
> since it relies on preservation of trailing white space, but
> it is too wellestablished to change. There is work underway
> to define a more sophisticated signature scheme as part of
> MIME, and this will presumably supersede the current
> convention in due time.
Hopefully this MIME-based sig standard, if it ever appears,
will clear up the ambiguities sigs have WRT attachments.
