🚀 go-pugleaf

In article <1993Jan7.191810.1857@infodev.cam.ac.uk>, ag129@cus.cam.ac.uk (Alasdair Grant) writes:
> 
> Is there any convention for transmitting MIME messages if extra
> mail headers (Content-Type etc.) cannot be used for one reason or
> another?  Do any mailers understand messages whose first (text) line
> begins "MIME-Version..." or something?

There is a proposal for using a MIME-like syntax to extend the kinds
of body parts that can appear in X.400(84) messages that does
something like what you suggest...if a body part of a particular type
begins with "MIME-Version:", the body part is assumed to be in MIME
format.  The application of this proposal is supposed to be limited to
gatewaying X.400(88) messages to X.400(84) messages, though it could
be used for RFC 822-to-X.400(84) gatewaying as well.

The current version of this proposal is in the file
internet-drafts/draft-ietf-mimemhs-harpoon-00.txt, available from your
favorite internet drafts repository (nnsc.nsf.net is one).  Please
note that the proposal is still under development.

Similar conventions might be useful for other non-Internet mail systems.

But there isn't any such convention for RFC 822 messages in general,
nor should there be.
--
Keith Moore / U.Tenn CS Dept / 107 Ayres Hall / Knoxville TN  37996-1301
Internet: moore@cs.utk.edu      BITNET: moore@utkvx
Let's stamp out ASN.1 in our lifetime.

ag129@cus.cam.ac.uk (Alasdair Grant) writes:

> Is there any convention for transmitting MIME messages if extra
> mail headers (Content-Type etc.) cannot be used for one reason or
> another?  Do any mailers understand messages whose first (text) line
> begins "MIME-Version..." or something?

The MIME-headers should be in the headers only.

Well, "my ideal" MTA would only analyse the headers of a message
needed for routing (if at all), transfer everything without changing
any bit (except adding "Received"-lines perhaps) and forward the
message to next next MTA on the way to the receipient.

It's the MUA's job to interpret the content of the message, only,
but the MUA must know about the encoding used and stuff like that.

RFC 821 explicitly forces you to cut the MSB, so SMTP MTAs fully
conforming to RFC 821 will not be able to transfer binary or even
8bit data. Quoted-printables and base64 may be transmitted without
any problems, but you'll have to tell your MUA manually to convert
the message, if at all possible. It's like using uuencode/uudecode.

What's your problem changing header lines? Maybe we can help you to
do this somehow.

        Kosta


-- 
  Kosta Kostis, Talstrasse 25, D-6074 Roedermark 3, Germany
  kosta@blues.kk.sub.org                                        (home)
  sw authors: please support ISO 8859-x!      dv|DV\_ = aeoeueAEOEUEss

In article <wBk7wB2w165w@blues.kk.sub.org> kosta@blues.kk.sub.org (Kosta Kostis) writes:
>What's your problem changing header lines? Maybe we can help you to
>do this somehow.

My problem is
  (a) that half the time my mail domain is neither RFC 822 nor X.400,
      and does not allow arbitrary header fields;
  (b) that I seem to be unique in thinking that MIME could be a general
      solution for all kinds of file structuring applications, such as
      those currently handled by ODA, SGML and various ad hoc encodings,
      or by context, or by making guesses based on file content or file
      name, in applications where the concept of "headers" is not present.
      For example I see no reason why program source code should not use
      the MIME tagging mechanism to indicate which language it is in, and
      cause the appropriate compiler to be invoked on its content.

On 10 Jan 93 21:31:55 GMT, kosta@blues.kk.sub.org (Kosta Kostis) said:

kosta> (Alasdair Grant) writes:

Alasdair> Is there any convention for transmitting MIME messages if
Alasdair> extra mail headers (Content-Type etc.) cannot be used for one
Alasdair> reason or another?  Do any mailers understand messages whose
Alasdair> first (text) line begins "MIME-Version..." or something?

Good question, and good subsequent discussion. In particular I agree
with your idea that MIME can be used outside RFC based mail, for non RFC
based mail, or indeed for any sort of document encoding.

kosta> The MIME-headers should be in the headers only.

Is is so difficult to contemplate that this is not an option in some
mail systems, which are *not* RFC based, and have nothing to do with the
Internet? The Internet is large, but it is only one of many mail
domains.

kosta> Well, "my ideal" MTA would only analyse the headers of a message
kosta> needed for routing (if at all), transfer everything without
kosta> changing any bit (except adding "Received"-lines perhaps) and
kosta> forward the message to next next MTA on the way to the
kosta> receipient.

Within the Internet this is (barely) possible; within other mail systems
it is not. All they undertake is to deliver message bodies.

kosta> It's the MUA's job to interpret the content of the message, only,
kosta> but the MUA must know about the encoding used and stuff like
kosta> that.

kosta> but you'll have to tell your MUA manually to convert the message,
kosta> if at all possible. It's like using uuencode/uudecode.

What about defining an in-band, very obvious, "magic string", sort of
cookie, that says to a MUA (or to *any* file manipulation program), that
'hey this is a MIME thingie'? Then cookie aware MUAs can apply metamail
or whatever MIMEry automagically, even if it is impossible to tag the
message envelope appropriately or even if there is no envelope.

As long as the cookie is *standard*, and damn unlikely to occur as part
of "normal" text.

There ought to be an option within the MUA/file viewer with three
values:

  CHECK:	ask every time if the file should be MIMEd.
  ALWAYS:	MIME the file every time there is a MIME cookie.
  NEVER:	don't MIME the file even if there is a MIME cookie.

kosta> What's your problem changing header lines? Maybe we can help you
kosta> to do this somehow.

Often this is not an option. Some mail systems have fixed headers.
--
Piercarlo Grandi, Dept of CS, PC/UW@Aberystwyth <pcg@aber.ac.uk>
  E l'italiano cantava, cantava. E le sue disperate invocazioni giunsero
  alle orecchie del suo divino protettore, il dio della barzelletta