----- Original Message -----
From: "Hallam-Baker, Phillip" <pbaker(_at_)verisign(_dot_)com>
To: "Carl Hutzler" <cdhutzler(_at_)aol(_dot_)com>;
<scott(_at_)kitterman(_dot_)com>
Sent: Saturday, May 28, 2005 12:25 AM
Subject: RE: SPF PASS (was: "If you believe that the SPF concept is fundam
entally flawed, please subscribe at http://www.imc.org/ietf-mxcomp/";)
[mailto:owner-ietf-mxcomp(_at_)mail(_dot_)imc(_dot_)org] On Behalf Of Carl
Hutzler
Never even knew there was helo checking in SPF. I might have
to do some reading. My bad!
It was in at the very start, then it got taken out, then it got put back
in again.
And I guess, in regards to SPF, I was probably had most of the blame for the
debate surrounding this.
The issue started with DMP which SPF is based on.
DMP has a return path domain check and a HELO client domain (CD) logic:
Check Return Path Domain
if not pass then check Client Domain
When we implemented DMP, it protected our local domains spoofing when the
client tried to emulate a internal network client.
DMP was extremely simple to explore and implement. Then SPF came along, it
was more complex. Not sure of what direction it will take, we held off on
it. Once AOL.COM announced support, we began to implement it.
SPF had a HELO check but only when the Return Path was NULL
if Return Path is NULL
check Client Domain
else
check Return Path
Once SPF was implemented, DMP was deprecated. Almost immediately, we began
to see spam from clients spoofing our HELO client domain once protected by
DMP coming in. It was fairly obvious that the above logic of only checking
the HELO domain when the return path was null was not only illogical, it
allowed for a spammer loophole into the spec.
So I argued for a SPF helo check as well regardless if the return path was
null or not.
However, by this point, the other implementation issues of DNS based
proposals was becoming more obvious - DNS overhead of open-ended lookups.
So I understood that there was a concern for redundant checks and given the
fact that traditionally the client domain can not relied upon for being
correct, my suggestion was to make it optional for implementators but more
importantly, I wanted to highlight that the best protection the LMAP
protocol had to offer was the protection of local domains (your own). The
LMAP results of local domains are more trusted. You can't trust the results
of remote domains.
Meng and others were not sure which way to go. I thought it was simple
issue to realize and important be considerd. It simply can't be ignored.
But at the very least, all systems should perform a local domain check and
in the final analysis, as we have it today, local domain/IP matching can be
done internally and more efficiently. We call it DIP rules (DOMAIN/IP) that
is part of our White/Black list filtering before any DNS-based protocol is
triggered.
In addition, for our implementation, we provided an optional list file to
define domains that should be check for SPF client domain names.
So we leave it to the administrator as to how much checking he wants to do.
The point is basically HELO is important to consider and possibly with the
introduction of CSV emphasizing client domain checking, maybe Meng and et
decided that it is important to have as well, if only for "competitive"
reasons.
My argument has always been that if we use a Return Path Domain checking
concepts, then this presumes a compliant client. Therefore, it is a new
system, and therefore it should never have a invalid HELO client domain
name.
My assertion has been that it would be illogical to have a SPF return path
domain and an non-SPF client domain name. Not possible without something
being wrong with the setup, a malicious transaction or a hetergenous
topology of mixed systems.
result1 := LMAP(ReturnPath, IP)
result2 := LMAP(ClientDomain, IP)
These mixed policies MUST be consistent (pass or fail) in order for it to
work. Its part of the "chain of trust" methodology.
I tried to illustrate this point in:
http://www.winserver.com/public/antispam/lmap/draft-lmapanalysis1.htm
A quick example would be:
HELO: localdomain
MAIL FROM: remotedomain
Which basically says, that if the MAIL FROM domain is remote (meaning, not
yours), then having a local domain for HELO is a LMAP violation.
In addition, I went further to show that "automated decisions", overhead is
further reduced by taken into account a vital piece of the transaction
parameters - the forwarding path (RCPT TO).
if RCPT is remote then
Standard Authentication Required
else Rcpt is Local and Not Authenticated Session
then check LMAP
Anyway, this is what DMP protected. SPF lost focus with HELO with its NULL
only rule. The above example is very typical spoofing transaction, about
12% of our total transactions where clients are trying to "fake" the server
into thinking it is a internal network machine.
In short, if HELO says
xxxx.winserver.com
xxxx.santronics.com
then the IP better be within our IP network, regardless of what the MAIL
FROM says.
So HELO checking is important and is part of the total scheme of things.
But it can't be used by itself like CSV advocates.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
I think that there had been some discussion about putting HELO checking
back in before your comment at the FTC but after that event it became a
no-brainer. First there was a major ISP that found that the check had
value, second there was absolutely no point in having a standards war
over how people make use of SPF records when there is precisely nothing
the sender can or should be able to do to dictate how the information is
interpreted.
I think that all this discussion and techno-politics have caused folk to
loose sight of the fact that all we are doing here is providing the
receiver with information that might help a recipient decide that he
really wants to accept a piece of email.