----- Original Message -----
From: "Matti Aarnio" <mea(_at_)nic(_dot_)funet(_dot_)fi>
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.
So you haven't seen everything? :-)
You have seen everything, but like me for a long time, we were stuck in a
time warp of not doing anything about it for a long time.
For me and for many, the last straw was when SORBIG started to forge
addresses and exploiting every loophole in the SMTP level.
SPAM? I could care less, thats an administrative/user policy.
I am more interesting in securing the SMTP TMS (Transaction Management and
Security) process to the highest degree possible
with maximum backward compatibility.
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 ?
Maybe the ultimate way, especially if the 2821bis document isn't going to
address any of the TMS issues. If so, I don't mind saying I would be
greatly disappointed because to me, there is some form of stubborness and
even incompetence in not understand the reality of today. Any SMTP "old
hand" that chose to ignore the MARID, SPF and SENDERID/PRA, well, to me, is
disturbing. I have full respect for people, but we can't ignore these
issues any more. Something got to give.
So I personally prefer if there is going to be a new 2821bis document, I
would like it to include the new considerations.
Following details have been seen to be escaping client
implementers attention (this includes both user agents,
and servers as SMTP client):
My comments are geared towards the significant level as
far as TMS in a vendor that have to operate with other SMTP servers as well.
- Adding spaces into what specification does not specify
them, most commonly as: "MAIL FROM: <...>"
Due to the wide spread. Tolerance is preferrable. This is
the current status in ~100% of all mail servers.
- Sending MAIL and RCPT without angle brackets
Instant reject in the majorit of servers.
- Sending utter junk and/or wrong syntax in HELO/EHLO line
Due the existence relaxed provision in HELO, most servers ignore everything
about the client domain name.
We need to address this at the most simplistic and purist level. I cited two
possible ways that I believe should not have any effect on reliable
operations:
- domain literals syntax and IP verifcation
- Local Domain Spoofing.
- Not sending HELO/EHLO greeting at all
Inject STATE machine violation.
- Failing to do reply data collection properly, and just
presuming that single network read will always yield
all of the reply.
Each system handles this differently. But technically this is a state
machine violation, so many systems have a count of the number of sequential
50x errors and do a drop.
The problem with drops is that the sender might call back again. So you
have to be careful.
A good dicussion item (which if I remember, is already there), but it might
be worth a revisit.
- Missing the requirement to support multiline replies
from servers, and that in multiline replies the last
line value is what determines the reply.
This is a BIG item for stopping BULK senders who try to blast/stream SMTP
sessions.
What I have seen here is that the sender drops on their own when they don't
see the final non-dash response code.
So I don't think you have any control here because it is the sender that is
broken and will drop.
Nonetheless, a good discussion item about developer and operations who offer
multiple/extended response lines.
- 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.
I have seen issues here, but I suspect you are trying to use
extended codes to define text presentations or meanings?
If anything, is that that senders might not honor temporary vs permanent
response codes. I believe this is already discussed
and well understood.
This might be a good discussion item about "GreyListing" considerations.
- 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.
Ok, however, keep in mind that there is good reasons to not "feed the
hackers/spammers" more information then they need.
But IMO, I don't see this as a SMTP thing. It is a administrative concept.
- 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..)
This is already convered in implementators as options.
However, I think they might be a discussion in how RSET is used to restart a
session.
- 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.
ESMTP is an option. Not a requirement.
Is this more of a RFC 2476 issues?
- 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.
Isn't this a STATE machine issue? This is covered I think.
- 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.
RFC 2476?
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.
Ok, RSET considerations? Limits discussion for operators.
- Requiring sender authentication at inbound MX servers for
inbound message traffic is serious configuration mistake.
Expand please? if I understand, we have a basic backward
compatibility issue:
router (authorization required)
vs
final destination (no authorization required)
- 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.
Ok, but these are pre-arrangements issues.
- 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.
Our server does separate the two. I think this should be an excellent
discussion item.
- Servers pay too much attention on EHLO greeting data,
which from behind a NAT box may well be other than what
the server sees.
Example?
If I understand you, right now, servers don't do anything with the client
domain name. That's the key issue here IMO.
For our implementation, this is one of these reported reasons why some
operations turn off the domain literal checker, because they see one or two
false positives. But at the same time, once they turn off it off, they see
a higher increase of spam activity.
So in our experience, the problem is often reduced to white list issue since
the sender who might have this NAT/Firewall issue, is often known..
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com