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
normalized:
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: ;
No-Orig-To:
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
<ojarnef(_at_)admin(_dot_)kth(_dot_)se>