[Top] [All Lists]

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

1995-02-24 11:22:26
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

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

   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

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

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

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!!give!up