John,
I don't think I am suggesting anything that is not A) backward compatible,
B) "nefarious" in providing a new level of fuzziness.
No, quite the opposite. I have a product in the market so it serves me no
interest to "break" operations. I am as pure as you can get in
understanding the purity of transport/interchange model. I've done it for
atleast 3-4 networks.
What I am merely highlighting are new possible considerations that may be
"generic" and "independent" and strictly SMTP based.
For one specific issue:
HELO #.#.#.#
I believe you are saying that we don't have a reliable way independent of
DNS to determine if this is valid or not.
If so, then we solve that issue. However, does this say you have don't
include a discussion item in 2821bis about this? I believe you can't
exclude such a item.
And so on with other similar considerations. Again, please hear what I am
saying, I am NOT suggesting anything that is "fuzzy" or random in its
principle idea. I am talking raw SMTP level considerations.
In my view, this simple consideration alone will GO a LONG way in assisting
all the new proposals, including Dave Crocker's CSV. The one big reason it
suffers (as well as SPF HELO provisions) is because we still have a relaxed
provision for HELO, and what I am saying, is even though that might continue
to be the consider, how much of it can be classified as invalid at the SMTP
level.
So we are not talking about requirements, but new considerations.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
----- Original Message -----
From: "John C Klensin" <john+smtp(_at_)jck(_dot_)com>
To: "Hector Santos" <hsantos(_at_)santronics(_dot_)com>;
<ietf-smtp(_at_)imc(_dot_)org>
Sent: Tuesday, July 05, 2005 4:37 PM
Subject: Re: Strict RFC x821 Compliant: HELO/EHLO
--On Tuesday, 05 July, 2005 13:00 -0400 Hector Santos
<hsantos(_at_)santronics(_dot_)com> wrote:
No Brackets ==> presumed DOMAIN
is not a practical idea to implement because systems will
endure a very high volume of HELO hits such as:
HELO #.#.#.#
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.
Sigh.
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
proposal.
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 [1.2.3.4.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
considerations.
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.
john