Greg,
GC> A HELO check can catch some really obvious bad cases (like spam or viruses
GC> using the receiver's own name) and some obvious good cases (like people we
GC> want to whitelist).
With respect to CSV, I think this needs to be phrased quite
differently, even though the semantics will probably seem similar, or
at least not contradictory. The reason for this need is that I think it
leads to a very different perspective on the implications of a CSV
mechanism versus an SPF-like mechanism.
HELO makes an assertion about the operation and accountability of the
MTA. There is quite a bit of history and current use of services that
vet sending SMTP clients and their network operators.
A HELO mechanism check can be used to produce a domain-name based
codification of such checking, rather than requiring that white/black
lists be maintained in terms of IP Addresses. The benefit of having a
domain name base involves all of the reasons we all like domain names
better than IP Addresses, for use by humans.
GC> CSV also uses HELO to tie a reputation to the sending MTA.
The concern about accreditation (of which "reputation" is a subset) is
rather interesting, here. What folks seem to be missing is that ALL
mechanisms that involve acceptance or rejection based on a name or
address has an accreditation component. Accreditation is, in fact, the
acceptance or rejection policy engine.
CSV merely specifies two external standards for such a mechanism.
So, yes, a mechanism that only seeks to detect forgeries does not have
an accreditation mechanism. But forgive me if I am wrong: I thought
folks were interested in detecting and preventing spam, and spam is
very, very much about accreditation, not forgery.
Forgery is a current symptom, rather than a core aspect of spam and
virus sending. Eliminate forgery and there will still be masses of
spam and virus sending.
I had rather hoped we were trying to get at core issues nof fighting
spam, what with the scale of the problem and the cost and delay
inherent in any standards effort.
GC> This seems to
GC> be based on the assumption that good mail comes from good MTAs, and bad
GC> mail comes from bad MTAs, which some have suggested is not well-supported.
"Some have suggested" is language that applies to any interesting
topic, for every possible point of view on the topic. Hence, it does
not carry any useful information. (Yeah, I am saying that a bit
sharply. It is a pet-peeve of mine about so-called news reporting and
I really hope the content-free utterance does not seep into serious
technical discussions.)
To move this particular point into something that might be productive,
please refer to the thread "who are we accrediting?" and note John
Levine's posting. I'll post a response to it.
GC> I think checking the HELO *alone* is not an adequate solution to the
GC> problem set.
I agree. RFC2822 author/sender based accreditation is also going to
be needed. The nature and form of that accreditation is a different
question.
GC> If the main thing we want out of MARID is to stop people forging mail
I do not have access to the working group charter as I write this, but
I sure hope that forgery is not the primary concern of the working
group.
Otherwise, there is a rather large community of email users and
providers who are going to rather upset that we spent all this time
and did nothing that is intended to reduce spam.
On the other hand, I could see how "DNS-based MTA authentication" could
cause one to think that forgery is the focus.
GC> apparently-from and bouncing-to our own domains, a MAILFROM/PRA check is
GC> going to be required.
Some sort of rfc2822 author/sender accredition is going to be
required... in some cases.
GC> Mechanically, CSV and SPF are both capable of checking HELO.
Mechanically, CSV and SPF are both fruit. But let me tell you, you do
not want to think about or use durian the same way you think about and
use oranges.
However, your statement highlights a deeper problem in most of the
efforts to discuss CSV and SPF differences: Such efforts are almost
entirely tied to mechanical and syntactic issues and do not focus on
underlying concepts.
CSV and SPF are fundamentally different pardigms.
CSV vets an MTA's traffic.
SPF vets an RFC2822 author/sender's message.
They are orthogonal informational-theoretic areas of consideration.
Where the confusion comes in, of course, is that SPF involves the MTA,
albeit through an indirection.
Let's try for some concise descriptions of the two paradigms:
SPF:
Per-message MTA path validation, based on Author/Sender
authorization and accreditations.
CSV:
MTA traffic validation, based on MTA operator authorization and
accreditation.
SPF vets an MTA's sending a single message. It accredits the MTA
based on the RFC2822 author/sender. While introducing a
path-dependency into the mechanism, it simply defers the hard
question, namely accrediting the author/sender.
CSV vets an entire MTA session. It accredits the MTA based on the
operator of that MTA.
Current whitelist and blacklist services focus on the MTA network, ie,
the operator of the MTA. So CSV provides a standardizing mechanism
for existing practise.
The limitations of that practise are demonstrated every day, but so
are the benefits.
GC> - If the MTA name is also used as a HELO name for one of the MTAs
I do not understand what that means. What is an "MTA name", other
than the string it puts into the HELO parameter?
GC> - In most cases the existing SPF record should be sufficient, since
GC> it probably includes that MTA.
My guess is that you are talking about the narrow case in which the
RFC2822 author/sender has the same domain name as the MTA HELO. While
a popular scenario, it is a long way from being the ONLY popular
scenario. And that's the problem. SPF is problematic for a number of
other such popular scenarios.
GC> Semantically, there is some difference in the understanding between what
GC> the CSV check means, and what the SPF+HELO check means.
It is rather more than "some".
GC> It would be better to use ?include:comcast.net or ?ptr:comcast.net. That
GC> way the mail from those domains is still allowed, but not "guaranteed" to
GC> be from you.
This begs for an obvious question: What is the benefit to the
anti-spam world of something which offers no guarantees? Is that not
the same as saying "I enforce no anti-spam policies, since anyone can
claim to be part of my domain"? No accountability is a rather serious
deficiency.
GC> If the result comes back unknown, you can't attach reputation
GC> or whitelisting to that transaction, you just have to proceed in "legacy"
GC> mode.
And the value-add of SPF, in this scenario is what, exactly?
What does the administrator of the domain and/or the operator of the
receiving SMTP client get for their effort?
GC> If people are really worried about others forging their name in HELO
CSV's anti-forgery component is not it's focus. Its focus is upon
accrediting MTAs.
Authentication is merely a necessary step along the path to assess
accreditation.
Is it clear to you that CSV has definite security advantages
over SPF/Sender-ID?
GC> There is general agreement that the smaller problem
GC> of HELO checking
"smaller problem"?
I hope you do not mean that identifying spam spigots is a small
problem or that doing it will be a small benefit.
That is one of the things CSV is useful for, that SPF is not. Entire
networks of compromised machines can be blocked with a single
accreditation entry, no matter what the domain names they use for their rfc2822
author/sender.
GC> CSV may have a better security story, but I believe this is a direct result
GC> of deciding to include fewer features and less flexibility.
Methinks there is a lesson in protocol design, here.
GC> Regarding DDOS concerns, I think they can be solved by placing some limits
GC> on the amount of recursion possible and the total number of queries needed
GC> per mail message, and that should satisfy most concerns.
Offhand, I am not sure what you mean and I am certain I do not
understand how it pertains to protection against DDOS attacks.
GC> I think there is enough consensus in the group that we need to protect PRA
GC> and/or MAIL FROM,
There is agreement that we need a mechanism that identifies and
accredits rfc2822 author/sender IN SOME CASES.
GC> and that HELO is of secondary importance.
I'm not sure whether you noticed, but there is a rather different tone
in the comments about HELO checking now than there was a month or so
ago.
GC> Not everyone
GC> agrees with this, but I think a majority of folks think that HELO checking
I am confused. Were the chairs asking each of us to perform a rough
consensus assessment of the working group?
GC> So, if we are going forward with PRA/SenderID or
GC> something like it, it should be easy enough to adapt it to HELO checking as
GC> well.
I'm sure we all look forward to the specification that satisfies your
expectation.
d/
--
Dave Crocker <mailto:dcrocker(_at_)brandenburg(_dot_)com>
Brandenburg InternetWorking <http://www.brandenburg.com>
Sunnyvale, CA USA <tel:+1.408.246.8253>, <fax:+1.866.358.5301>