----- Original Message -----
From: "Frank Ellermann" <nobody(_at_)xyzzy(_dot_)claranet(_dot_)de>
To: <spf-discuss(_at_)v2(_dot_)listbox(_dot_)com>
Sent: Tuesday, December 14, 2004 2:27 PM
Subject: [spf-discuss] Re: SPF HELO checking
The sender simply to provide logical information that can
help the server do its job.
And how do you interpret SOFTFAIL or UNKNOWN for HELO ? I'd
interpret it as "bad" and reject, but what I say is _theory_
You're right. I stated this from the gitgo of all my helo discussions. :-)
It is illogical to have a relaxed LMAP provision for the client domain name.
This is what CSV preaches. This is what the chain of trust shows.
MUA --> MSA ---> MTA ---> MDA
For MDA to trust the MTA, it must presume there is a chain of trust along
the path from MUA/MSA and MSA/MTA to finally MTA/MDA. If this is not part
of the network topology design, you might as well drop all this work and go
home. You will be beating a dead horse. :-)
Its about SMTP compliancy and getting admins to secure their networks. If
we think we can provide a solution with the idea that people don't have to
secure their networks, again, its a lost cause.
In addition, I show it in my trust analysis work. In fact, you can even use
the result in some case to help correct or increase of the trust weight of a
SPF(MailFrom) SoftFail or Forwarding problem - in some cases.
Here is one example:
Using the topology above, at the MDA, the SPF(MAILFORM) result is a
SOFTFAIL/NEUTRAL.
The question is now, is there something else in the process environment that
can help validate this result in direction or another.
Well, #1, the fact that you got an SPF result implies that someone in the
chain is purporting to be SPF compliant.
Therefore in theory, assuming current SMTP compliancy in the chain, all you
need to do is look at the hops (Received headers) to get the IP of each
chain to see where the transistion took place.
But this requires a PAYLOAD transfer and it is not ideal mode of operation.
You would do this as a last resource (One reason why I am preaching a HEAD
command at SMTP). [Side note: Dave Crocker talks about hop analysis in a
paper 2-3 years ago. Microsoft? Prior art - patent voided!]
In any case, there could be other rules, like HELO/IP rDNS, domain literal
checking and also more intelligence rules processing:
#1 Equal Domains, relaxed SPF(MAIL FROM) result
if the domain for HELO = MAIL FROM,
and SPF(MAIL FROM) in [Softfail, Neutral]
then final Result = FAIL
#2 Equal Domains, Fail SPF(MAIL FROM) result.
if the domain for HELO = MAIL FROM,
and SPF(MAIL FROM) = FAIL
then final Result = FAIL
Why? because you should not get a SOFTFAIL, NEUTRAL or FAIL on
SPF(MAILFROM) if the domain is the same or part of the sender network.
The question is how much trust you put into this automated "intelligence:"
I would say:
#1 has a trust value less than 100%, where #2 has a trust value of 100%
#3 UnEqual Domains, relaxed SPF(MAIL FROM) result.
If the domain HELO != MAIL FROM
and SPF(MAIL FROM) in [Softfail, Neutral]
then final Result = undeterminant
You can possible try to do SPF HELO checking here:
#3.1 SPF(HELO) = FAIL, final result FAIL
#3.2 SPF(HELO) = PASS, final result PASS, Forwarding Problem??
Whats the trust? I say:
#3.1 100% ?
#3.2 < 100%
So as you can see, a HELO spf check "can" be used to evaluate a forwarding
problem.
Anyway, when you sit down and do a total theoritical trust analsys on all
this, you will see the possible states can climb as high as 55 or more (if I
remember). In the end, it comes down to producing an inequality trust
equation for the result.
This is one reason I say that really need to get away from the relaxed
provisions baloney. This is what got SMTP in trouble in the first place.
The "relaxation" of SMTP rules which SPAMMERS exploited to the nth degree.
Thats why we are here today. If people don't think this is not going to be
exploited in SPF with its relaxed provisions, well, all I can say, it is
very disappointing to see this continuing. I wish we took the opportunity
NOW to make it impossible for the specs to be exploited, not later, when its
too late. SPF2 might be too late because SPAMMERS will stick with SPF1.
Sincerely,
Hector Santos, CTO
Santronics Software, Inc.
http://www.santronics.com
305-431-2846 Cell
305-248-3204 Office