On Wed, Jul 06, 2005 at 05:55:25AM -0400, John C Klensin wrote:
Matti,
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 et.al. 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
attention:
- 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.
john
....
--
/Matti Aarnio <mea(_at_)nic(_dot_)funet(_dot_)fi>