On Sun March 13 2005 16:41, John C Klensin wrote:
MTAs that are not the
submission server should not even be looking at the headers to
determine that the information is missing. The delivery MTA
may look (although it doesn't have to), but there is a strong
case to be made that, if it doesn't like what it receives, it
should bounce the message rather than trying to fix it up. The
standard doesn't require that-- it encourages delivery on the
basis of the envelope only, i.e., not looking at the headers to
determine what might be missing.
Which begs the question, what is the minimum requirement for
an valid RFC header required by a x821 process?
There is an old controversy about this. One interpretation is
that, unlike 2821 with MIME, 821 does not require any particular
message format at all and, in particular, does not require any
822-style headers. Some people have taken the position for
many years that a header-free message was essentially required
for an implementation of SEND to make any sense at all.
If one takes a strong version of the "MTAs don't look at the
headers" principle, and states your question as above, the
answer is "none". Of course, one might then claim that
delivery from the delivery MTA into the mail store (or to the
receiving MUA) is not part of the "x821 process".
[...]
So what logic should a x821 receiver have to determine whether
there is a valid RFC header?
If it is not the final delivery MTA, it doesn't need any
"logic", because it should not be asking.
Note that both 821 and 2821 require prepending a time-stamp
line (a.k.a. Received field) to the message. Clearly, if
there is already a message header, that means prepending
a field, and if there is no message header (body only) it
means prepending a field *and* the empty line that separates
header from body.
So, to handle the hypothetical case of a message with no
header, all MTAs would have to look at the message content
(to determine whether or not there is a header) and require
logic to handle the two distinct cases (message with existing
header vs. message that needs to have a separator line as
well as a time-stamp line).
In practice, I suspect most MTAs assume that the DATA is a
message with at least one header field, and consequently
simply prepend a time-stamp line w/o checking.
Prepending a time-stamp line to something that isn't an
RFC [2]822 message with a header makes little sense; if
mucking about with header fields is wrong, mucking about
with body content is more wrong (gateways are permitted
to do so in very specific ways for specific reasons, e.g.
applying transfer encoding). SMTP MTAs aren't even
theoretically capable of transfer of something which isn't
in Internet [Text] Message Format; prepending a Received
field (a component of that Message Format) precludes that
(unless transparency of transfer is immaterial) -- and that
goes all the way back to RFC 788, which also prepended a
time-stamp line (with a different name).
In practice, therefore, SMTP always transfers Internet
Message Format payloads (with modification, at least by
addition of a Received field). Since all valid RFC [2]822
Internet Messages must contain at least one field (Date
has been mandatory since long before SMTP existed; at least
as far back as RFC 724), that leaves only non-message
(= non-compliant content) as the only (slightly) interesting
case. As noted above, I suspect that MTA authors tend not
to worry about it; the reasonable choices are:
1. prepend a time-stamp line to the DATA and pass it along.
if the content is already broken, it won't be more
broken.
2. check content for lack of header, insert separator if
there is no header, then prepend time-stamp line. If
the previous hop screwed up (or detection is faulty),
that can result in effectively putting the (screwup and)
previous header in the message body (I've seen the
results of that).
3. check for lack of header, bounce if there is none, else
prepend time-stamp line and forward.
Note that only the first choice involves neither peeking
at content nor logic, and that is predicated on the
assumption that content is always an Internet Message with
an existing header. The other choices involve both looking
at content and some logic based on the findings.