--On Tuesday, 05 July, 2005 13:00 -0400 Hector Santos
No Brackets ==> presumed DOMAIN
is not a practical idea to implement because systems will
endure a very high volume of HELO hits such as:
So what I have been trying to get a focus on is the syntax
field validation considerations not only for SMTP servers
adopting these new DNS proposals, but also view them as new
general SMTP related issues that may apply regardless if a
system implements one or more of the DNS-based proposals.
Here is a small set of invalid HELO/EHLO captured in the first
two hours of July 3:
If you use the No Bracket == DOMAIN rule, this would produce a
high DNS lookup overhead when you implement a DNS-based
Uh... So? 2821 doesn't require you to do a DNS lookup on the
HELO/EHLO domain at all. It also doesn't require you to
syntax-check it. If you do decide to syntax-check it, it
doesn't require that you reject [1.2.3.X] or even [184.108.40.206.5]
nor that you accept 1.2.3.Y.4. Regardless of which of these you
do (or don't) do, it significantly restricts the conditions
under which you can reject the command entirely: only the two
domain literal forms represent invalid syntax.
Of course, you can invoke the "protect myself from attack" rule,
at which mpoint any of the above can presumably be rejected, and
rejected without calling on the DNS.
2821 is a standard for mail transport and interchange. It is
very clear (I hope) that you are not obligated to accept mail
that you consider nefarious. Criteria for determining
nefariousness just don't belong in the transport standard: if
nothing else, they are too controversial and too transitory.
I don't believe this has anything to do with semantics. A
SMTP system designed to address today's needs can benefit by
having rather logical and simple syntax field validation
Sure. But beyond the above, IMO, not in the standard. The
problem with the sort of rules you are trying to develop is that
"looks suspicious" can easily evolve to exclude all sorts of
valid things -- TLDs that weren't valid a few years ago, but are
now, domain names with odd constructions (e.g., not many years
ago, if you saw a DNS label with two consecutive hyphens, it was
probably bogus; today it may be part of an important standard),
local parts with "odd" characters in them like "+" or "=" or
"/", and so on. So we get back to the bottom line of how much
risk you want to run of rejecting legitimate mail in order to
stop spammers. 2821 isn't about that: it is about how a client
and server deal with each other when the primary purpose of both
is to get presumably-legitimate mail through to a selected
destination mailbox. All of other cases, remedies for them,
are, IMO, appropriately outside the standard.
Hope this explains it better.
It was actually quite clear.