[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Internet draft draft-onions-822-mailproblems-00.txt
Julian Onions <firstname.lastname@example.org> writes (17 Feb 1995 09:09:56 +0000)
in message <>:
> 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 <email@example.com> 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
> 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
could be replaced by:
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
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 <firstname.lastname@example.org>