[Top] [All Lists]

Re: Internet draft draft-onions-822-mailproblems-00.txt

1995-02-20 07:40:17
Julian Onions <j(_dot_)onions(_at_)nexor(_dot_)co(_dot_)uk> writes (17 Feb 1995 
09:09:56 +0000)
in message <17350(_dot_)793012196(_at_)nexor(_dot_)co(_dot_)uk>:

I would like to submit the following as a new information internet
draft to highlight some of the pragmatic problems found in the 
internet with RFC822 based mail.

I am not too sure which working group this is most suitable under at present.
Any suggestions are welcome.

It seems to me that most of the content of this draft should be
possible to incorporate in the proposed SMTP Applicability
Statement (draft-ietf-mailext-smtpas-00.txt) currently under
discussion on the <mailext(_at_)list(_dot_)cren(_dot_)net> mailing list, and in
the forthcoming proposal for an RFC 822 AS.

Here are a few comments on RFC 822 issues.

6.1. Illegal format RFC-822 messages

   Some implementations of RFC-821 check the message  for  adherence  to
   RFC-822  minimum  requirements  as the message is received. These are
   that the message contains in the header a From field,  a  Date  field
   and  a  recipient  field  of some type. However, some user agents use
   RFC-821 as a submission protocol and assume  that  messages  will  be
   made  legal  RFC-822 as part of the submission process (as some MTA's
   already  do  this).  Implementations  MAY  therefore  allow  strictly
   illegal  RFC-822  messages as data and make them legal by addition of
   new headers, or MAY reject the message as illegal data.

Sendmail, to take an important implementation, inserts an empty
line, if an RFC 822 header field is immediately followed by a
line that starts with a graphic character other than space and
tab, and doesn't contain a colon.  This also seems to be an
acceptable way of making a submitted message legal.

(Sendmail in fact accepts as a header field a line starting with
a colon, although empty field-names are not allowed according to
RFC 822.)

6.2. Received Lines

   When gatewaying or examining these  elements,  the  invalid  elements
   should  either be discarded or else the current time inserted to make
   them legal. The illegal Received: lines can be changed  to  be  Orig-
   Received: to ensure the relayed message is now legal.

I like the Orig- scheme. Couldn't this be made general?

Whenever an MTA or mailing-list exploder or gateway needs to
change the content of a header, it should retain the original
header, but with an "Orig-" prefix in its field name.

This could e.g. be done when pseudo-domain addresses are

   To: ojarnef(_at_)sekth(_dot_)bitnet

could be replaced by:

   To: ojarnef%sekth(_dot_)BITNET(_at_)SEARN(_dot_)SUNET(_dot_)SE
   Orig-To: ojarnef(_at_)sekth(_dot_)bitnet

If an original header needs to be made harmless, it's name is
prepended by "Orig-". No new header is inserted.

If a new header, not included in the original message, is
inserted, it's accompanied by a header showing that it wasn't
there originally:

   To: undisclosed-recipients: ;

This would mean that the parts Orig-* and No-Orig-* of the
header field namespace would be reserved, like Resent-* already
is. Whenever a new header Abc: is defined, also Orig-Abc:
and No-Orig-Abc: are implicitly defined.

6.4. Resent- fields

   For pragmatic reasons, and because it seems closer to the  intent  of
   RFC-822  in  this  case, the Resent- fields should be taken as a set.
   However implementations  SHOULD  allow  the  individual  fields.   In
   practice  this  sort of forwarding is not very common, but does arise
   from time to time.

Now that we have the Message type defined in MIME, the use of
Resent- headers should be phased out in favour of a new
Message/Forwarded subtype, in my opinion. (In practice this only
means that the original message is prepended by the headers
referring to the forwarding operation, and an empty line.)

One definite advantage of this is that forwarding an already
forwarded message is trivial. If Resent-* headers are used in
that case, either the already existing Resent- headers have to
be discarded (removing perhaps useful trace information), or
Resent- headers will be doubled, the semantics of which is said
to be "undefined" in RFC 822.

Olle Jarnefors, Royal Institute of Technology, Stockholm