[Top] [All Lists]

Re: Strict RFC x821 Compliant: MAIL FROM:

2005-07-06 04:58:16

On Wed, Jul 06, 2005 at 05:55:25AM -0400, John C Klensin wrote:

None of  this is surprising, at least to me.  The question is
whether you think the SMTP spec should be modified to _require_
servers to accept the sorts of "variations" you outline and to
explicitly authorize (and thereby encourage) clients to send
them?  And, if so, which ones and why?

Yes John, we have been at this for way too long, and have seen 
everything...  I just wish  SPF specifiers have equally
old hands.

I have a feeling that we need a new part on the specification,
which in itself is informal, but..
Well, or a separate BCP RFC ?

  NNN. Pitfalls

  Following details have been seen to be escaping client
  implementers attention  (this includes both user agents,
  and servers as SMTP client):

   - Adding spaces into what specification does not specify
     them, most commonly as:  "MAIL FROM: <...>"
   - Sending MAIL and RCPT without angle brackets
   - Sending utter junk and/or wrong syntax in HELO/EHLO line
   - Not sending HELO/EHLO greeting at all
   - Failing to do reply data collection properly, and just
     presuming that single network read will always yield
     all of the reply.
   - Missing the requirement to support multiline replies
     from servers, and that in multiline replies the last
     line value is what determines the reply.
   - Missing entirely reply-code principles, e.g. that their
     treatment MUST go by the first digit, deeper semantics
     may be applied, but basic codes are so overloaded, that
     only first digit is usually meaningfull.
   - Not showing protocol exchange and remote end replies to user,
     when sending fails for whatever reason  (so that user can
     report them to helpdesk - or see right away, why the message
     or one of its recipients didn't go thru.)
     For 99% of things, showing last sent protocol line, and received
     error reply for it will do.  For the remaining 1% a full
     protocol exchange from the connection down to close is needed.
   - Single MAIL-transaction can not have more than 100 recipients,
     when more are to be sent, multiple transactions are needed.
     (Most servers allow more, some allow a lot less..)
   - If server advertises EHLO capability to do user authentication,
     it does not mean the client must do it.
     Especially strange client behaviour is that when the server
     does not advertise said capability, clients won't try to
     authenticate and just send message without trouble.
   - When server does not advertise some capability in EHLO reply,
     client MUST NOT go ahead blindly and try to use it anyway.
     Blind AUTH attempts are common.
   - There is only one (deprecated) case (port number), where
     in SMTP protocol extensions the TLS stream encryption is
     activated up front, in all other cases the processing
     follows STARTTLS specification.

  Following details have been seen to be escaping server implementers

   - There is NO limit in the number of MAIL-transactions per
     single connection.  High-efficiency MTAs will send entire
     accumulated queue in as few connections as possible.
   - If the server implementation is fundamentally compliant,
     PIPELINING support reporting is highly recommended at the
     inbound side.
   - Requiring sender authentication at inbound MX servers for
     inbound message traffic is serious configuration mistake.
   - Server may need radically different service subsets at
     different ports, e.g. SMTP does not support STARTTLS, nor
     any AUTH, whereas SUBMIT supports STARTTLS, and different
     sets of AUTH depending on TLS being active or not.
     Non-standard plain-text authentications should not be
     available except under TLS encryption.
   - Servers don't separate DNS timeouts and SERVFAILs from
     genuine NXDOMAIN replies, and in all cases report permanent
     five-hundred series rejects, where proper is temporary
     four-hundred series retry.
   - Servers pay too much attention on EHLO greeting data,
     which from behind a NAT box may well be other than what
     the server sees.

just off the top of my head...

At work we just spotted this client authentication behaviour goofup,
when we offered AUTH services at the SMTP port of our customer outbound
traffic SMTP servers.

After that debacle, we offer AUTH only at SUBMIT port, but there we
also support Outlook misbehaviour with TLS:  when connection starts, server
waits 2 seconds to read possible start of whatever the client may
send.  If that whatever begins with byte 0x80, that byte is pushed
back into input stream, and SSL is initiated, and then normal start
proceeds within the SSL stream.   If nothing comes in during those
two seconds, normal non-encrypted start proceeds.


/Matti Aarnio   <mea(_at_)nic(_dot_)funet(_dot_)fi>