spf-discuss
[Top] [All Lists]

Re: Re: HELO versus MAILFROM results

2005-05-06 06:02:02

----- Original Message -----
From: "Radu Hociung" <radu(_dot_)spf(_at_)ohmi(_dot_)org>

I am partially guilty for the beginning of this "fud", as I said once
that anything goes in the HELO name. I'm sorry. A lot of stuff goes, but
not quite everything. I should have been more clear.

However, I still think there is no point checking the HELO.

So you would skip the obvious local domain spoofing?

All a spammer has to do is find a host name, *any host name* without a
TXT record, and use that in the HELO.

This would be a good thing:  Force the Spammer to Change!

This SPF check is so easy to bypass, it's not funny.

But the same applies to the MAIL FROM too.

The fact that the name in the HELO is inconsequential for the rest of
the SMTP conversation means you can't tie the helo to anything else in
that email communication... so what's the point assuming it has
any meaning?

It has meaning. It must be FQDN.  Spammers are indeed learning that SMTP
compatibility is becoming more important, not less.

There is no doubt the trend is to be more correct with the conversation than
not.  Even if spoofed, the trend is to fake you out with a "emulated"
correct conversation.

Here's a short list of good candidates.

my-hostname-is-longer-than-yours.mit.edu
didnt.doit.wisc.edu
com.com.com
sci.fi
pearly-gates.vatican.com
diplomatic.passport.ca

And an adaptive system can quickly adjust itself.

The only check that might be remotely valid is to check the A record to
ensure it matches the IP address. But that's not SPF, and it can also be
easily faked with the [1.1.1.1] notation. Rejecting those is also not
SPF stuff.

No system worth its salt will rely on just one system.

So what does SPF have to do with HELO ?

The best you can do is to protect local domains and this gives you 100%
trusted results.

Actually, before it is proposed that HELO should be done, it should be
experimented with, to see how much junk it keeps away. Then, if the
results of this experiments were favourable, we could discuss including
it in a spec.

This is why I say that SPF is still at the early stages of experiment.
There are more things we haven't learnt yet than things we have.

Many have already learned all this.  This isn't today's news!

Mind you,  in general HELO validation is weaken by tradition because the
specs pretty much allowed it to be broken and the conversation can continue.
But that is still up to the implementation.

New augmented specifications add the mandate that the client domain must be
a FQDN which opens the doors for client domain validation techniques.

The theory is simple, if a system purports to be SPF ready via the MAIL
FROM, then it must be SPF ready at the HELO domain.   If it is not, then it
raises suspicion.    The only technical loophole is once again, the
forwarding (routing) problem where there is a transition and the HOP may not
be SPF ready.   But for a direct transaction:

         LMAP == IP::MFROM  == IP::HELO

This must be true, or LMAP is broken.   Whats common here?  The IP!

SPF evolved from the work of DMP and RMX.  DMP  had both a MFROM and a HELO
check.   DMP enforced a DNS record publishing for the email domain and the
client domain.  SPF screwed up by ignoring the HELO checked that DMP was
doing because MENG did not understand why it was needed.

The weak consideration of allowing an HELO check when MFROM equal NULL was
illogical.   People who were using DMP but turned if off for SPF,  quickly
realized that HELO spoofing increased.

Remember, the #1 protection that any LMAP concept can give you is 100% trust
in local domain protection.  The trust in protecting remote domains is less.
No one should be using YOUR domains on your server and this represents
atleast 12-15% of the transactions in the vain attempt by spammers to
emulate an inner network machine.

Now, the WHOLE problem with LMAP in general is the DNS overhead issue.  DMP
knew that it has a DNS overhead issue with its dual lookup.   Meng tried to
minimize this by bypassing HELO altogether .  But that was a mistake.  It is
illogical.   Again, if you can' t be SPF ready at email domain without being
SPF ready at the client domain and the exception to this is
rouiting/forwarding issues.

Look at this:

    Client IP:  1.2.3.4
    HELO mail.santronics.com
    MAIL FROM: address(_at_)spf-ready-domain

Even if the email domain is validated agaist the IP, this is an obvious
SPOOF because a) not only is the client domain local (I own it), but b)  it
would fail the SPF check.

There is NO possible topology that makes this a valid transaction.  We know
it because its our domain, thus 100% trust.

But what if its another domain?

Yes, the trust is lower.   What the SPF specs is suggesting is that you have
the option to perform an SPF check.

This is how I see for the above example when the client domain is remote
(not local, we don't own it).

Given  SPF(MFROM) = PASS

    SPF(HELO) -> NXDOMAIN -->  overall result ->  FAIL  (High Trust)
    SPF(HELO) -> FAIL -->  overall result ->  FAIL  (High Trust)
    SPF(HELO) -> PASS -->  overall result ->  PASS  (High Trust)
    SPF(HELO) -> NONE -->  overall result ->  PASS (Lower Trust)

Thats it.  There is no temporary or "Relaxed" provision here.  Again, the IP
is important.  If the IP is SPF ready at the email domain, then it must be
SPF ready at the HELO domain.

Now, in theory,  you can make a correlation with the number of hops.

If this is a single hop, then  its a direct transaction and thus:

       SPF(MFROM) == SPF(HELO)

If the # of hops if greater than one, then the decision making process is
more complex.  Yet,  the spectrum of SPF results can only be NXDOMAIN or
NONE.  It can't be PASS or FAIL and yet be valid when SPF(MFROM) = PASS!

This has all been discussed Radu.  SPF must take HELO into consideration and
allow implementations to work with it.   You can't exclude it.     Even if
the SPAMMERS adjust, that would be a great thing because we are making them
do things in OUR direction.

The best thing a spammer can do is not be SPF ready at all by making sure
they don't use SPF email or client domains.   A partial usage or spoofing
will catch them one way or another.

This is why that the more professional AVS system can not rely on SPF or any
other protocol.  Backward compatibility is still a requirement thus other
concepts are still required.

- RBL is still a top item.
- SMTP compliancy has become a top item in our weoponry.
- Delay Verification (checking RCPT first)
- Callback Verification is the final check for our system.

----
Hector Santos, CTO
Santronics Software, Inc.
http://www.santronics.com
http://www.winserver.com/wcsap (Wildcat! Sender Authentication Protocol)
http://www.winserver.com/spamstats  (WcSAP Anti-Spam Stats)