The draft claims to be informational, but purports to make
requirements of implementations.
Many of the issues in the draft (like a restatement of the
prohibitions aganist just-send-8) are covered in the upcoming 822 and
SMTP Applicability statements. The author should look at
and comment on draft-ietf-mailext-smtpas-00.txt.
On some more specific points:
5.6. Rejection of SMTP connections due to DNS failure.
There are a number of SMTP implementations that either do, or can be
configured, to reject SMTP connections if the calling host is not
registered in the DNS. This is seen by some as a breaking of the
spirit of RFC-1123, and by others as a useful get-out-of-jail card.
I'd say this most certainly breaks the spirit, if not the wording of
1123 section 5.2.5. The fact that such servers decide to refuse to
accept a message before the client can send a HELO command is a mere
technicality.
In any case, there is no reason for SMTP clients to pander
specifically to such sites. The servers are the ones who decided they
don't want to accept mail.
Implementors are therefore
encouraged to use back up MX routing in the case of a connection that
succeeds but no data is received before the connection is dropped.
This is a good idea outside of the context of servers that try to do
reverse-name lookups. One should roll over to the next MX if a
connection fails, is dropped unexpectedly, ore one gets a 4XX reply
code on MAIL, DATA, or the final '.'.
One failure mode I have seen is for one of several MX servers to run
short on disk space and return a 452 reply after the final '.'. Some
SMTP clients, such as older versions of sendmail, don't know to roll
over to the next MX when this happens.
A resilient server MAY detect that the EHLO caused the connection to
That would be a resilient *client*.
Alternatively it can be treated as a bad connection and subsequent MX
records tried if available.
Usually, there won't be a subsequent MX host that does handle EHLO.
In this case, the message will sit in the queue for five days, then
bounce.
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).
This is a real mess that needs to be straightened out, instead of
being merely documented. Unfortunately, a proper straightening out
would require a design change in sendmail to allow per-incoming-mailer
rewrites, I have yet to work that out with Eric Allman.
6.2. Received Lines
The syntax of the Received: lines in RFC-822 messages is reasonably
straight forward. It requires as a minimum a date stamp following a
semi-colon. Unfortunately some implementations cannot seem to
generate this. This can cause problems when gatewaying to other
systems that also have trace fields. This is seen as a good way to
cause general confusion when tracking messages.
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.
Relay agents should not muck with the existing contents of the
message, this breaks the message/envelope separation. They should
most certainly not be mucking with existing Received: headers.
Gatewaying is distinct from relaying. What should happen with
Received: headers when gatewaying depends on what kind of system the
message is being gatewayed to/from.
7.1. Badly formatted Content-Type: fields
Implementations have been known to produce lines of the form
MIME-version: 1.0
Content-Type: text
That is, a MIME type, without the mandatory subtype. This is illegal
as a MIME header and means the content may be subject to
misinterpretation.
This is a syntatically illegal MIME Content-Type header. My MIME
readers ignore syntactically illegal Content-Type headers, causing them
to treat the part as the default "text/plain; charset=US-ASCII". I've
seen others apply "default subtypes".
It is a legal RFC 1049 Content-Type header field.
7.2. Multiple Content-Type fields
Messages may contain multiple Content-Type fields,
Messages are not permitted to contain multiple Content-Type fields, it
is not the case that composers MAY generate multiple Content-Type
fields.
It is possible for multiple fields of any type to appear in an invalid
message, be that Content-Type, Content-Transfer-Encoding, From,
Sender, Subject, whatever. Content-Type is not special in this
regard.
7.3. Badly structured multipart messages
Message that contain fields such as
Content-Type: multipart/mixed
have some great potential for causing indigestion in mail systems.
They're certainly illegal. I have no idea what advice the text is
trying to give on the subject.
--
_.John G. Myers Internet: jgm+(_at_)CMU(_dot_)EDU
LoseNet: ...!seismo!ihnp4!wiscvm.wisc.edu!give!up