-----Original Message-----
From: owner-spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
[mailto:owner-spf-discuss(_at_)v2(_dot_)listbox(_dot_)com] On Behalf Of Radu
Hociung
Sent: zaterdag 7 mei 2005 3:20
To: spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
Subject: Re: [spf-discuss] Re: HELO versus MAILFROM results
If a spammer starts the mail conversation with "HELO sci.fi" he has
essentially thwarted your attempt to get a "FAIL" from the HELO.
But I also said: In your case, if software starts with a HELO check
against sci.fi, nothing is 'bypassed', as domain of sender sci.fi does not
designate mailers, so a regular SPF check against the MAIL FROM identity
is done after all.
The remote spammer has full control over what SPF result you will
evaluate at HELO.
And the spammer also has full control over what SPF evaluates at MAIL
FROM. Your point being?
That's what makes it useless to check.
No. You have to look at HELO checks in the larger scheme of things. The
introduction of a more pronounced HELO check at the beginning of the
process was primarily done to 'spice up' SPF performance with early-out
mechanisms -- as a man going on about excessive DNS queries, surely you
can appreciate that. :) So, you could do an SPF check against HELO,
without looking up the A record even, and treat an immediate 'fail' as a
quick early out.
If you care to do the A record lookup, HELO checks can become very useful
in "karma" checks (against reputation services). Instead of whitelisting
ever-changing IP addresses, a properly resolving HELO name means you could
suffice with whitelisting just a handful of trusted 'key-words' (FQDNs, at
HELO). Until such time HELO checks are widely used for this purpose (it is
always hard to predict what the market will do), you can already use HELO
checks to get the early-out 'fail' result -- without even having to do the
A record lookup.
Or you could continue to use HELO checks in the case of MAIL FROM: <>
only. Your choice.
If the spammer wants you to see "NONE", he says "HELO sci.fi"
Perhaps you do not fully realize the fact, but SPF was actually designed
so spammers would use your 'bypass'. :) Seriously. The whole purpose of
SPF is so spammers will avoid using SPF-protected domains! That's not a
flaw; it's the whole point! We want spammers to say: "I am not going to
bother phising domain X any more, because of those pesky SPF checks; lets
use domain Y instead." In fact, if you can bring solid evidence that
spammers are already doing this, then we have cause to celebrate. :)
I.am.a.spammer.com TXT "v=spf1 +all"
1. So what are you going to do? Block HELO's that resolve
with "PASS" ?
I could. If I did an A record lookup on the HELO, and it appears to be a
known spammer, I may well avail myself of this early-out and toss him out
of the nearest airlock. "pass" just means SPF says the relay is
authorized; I, on the other hand, decide who I want to receive mail from.
2. Put the HELO strings in a reputation database? Recall that for each
DNS zone file, there are an infinity of possible HELO strings, each
unique. That makes for an infinitely large and infinitely useless HELO
reputation DB.
No reputable service would ever create an infinity of possible HELO
strings. Besides, it is entirely up to me how many TLD (sub)levels I deem
relevant, and in what order I will check them. Say, I check
"mx01-dom.earthlink.net" as HELO name, and it resolves properly, then I
would probably use 2 DNS queries to a reputation service: one for
"mx01-dom.earthlink.net" and one for "earthlink.net". And if it really
became the far-fetched case that spammers would create an infinity of
possible HELO strings, I would simply reverse the order, and evaluate
"earthlink.net" first. Problem solved (if there even was one).
Unfortunately there is no required relationship between the
domain name in MAIL FROM and the name in HELO.
Make that fortunately. :) I host many virtual domains, and they are all
rigged to use my SMTP server. And my mail server only uses one single HELO
name ("mail.asarian-host.net"), identical to the PTR. And I like to keep
it that way. :)
It is not a good idea to do the HELO check if the MAIL-FROM
is a proper email address because:
2. The HELO is not something the sender has authorized with his SPF
policy.
If the HELO domain name is SPF-protected, then the owner of that domain
determines who can use that domain name in HELO, or MAIL FROM. It is
therefore entirely appropriate to do an SPF check against HELO. Perhaps a
nuance, but it is, of course, not the sender who authorizes anything, but
the domain owner. And if you use for HELO a name for which the domain
owner has not authorized you, then too bad.
The SPF policy authorizes IP addresses, not HELO names.
The SPF policy authorizes IP addresses *against* HELO names and MAIL FROM
domains. You cannot separate the HELO and MAIL FROM domain names from the
authorized IP addresses: the latter are only authorized, or not, based on
the inalienable relationship with the former.
At my site, the name "yahoo.com" gets a spam rating of -2, because I
have some friends that write me from there. I get a lot of spam that
forges yahoo.com, but -2 is the average that my tools automatically
found to pass most ham through and reject most spam.
I 'fail' to see what this has got to do with anything. You are talking
about post-processing, long after the SMTP session has closed. Whatever SA
score you assign to the mail, later on, has no bearing on the
determination, inside the SMTP dialogue, on whether the name "yahoo.com"
was used in an unauthorized fashion (SPF-wise).
(N.B. You could do spam checks inside the SMTP dialogue, but it would
still be post-processing, as you would do the SPF check against
"yahoo.com" first).
The HELO is a completely different matter, as spam filters do
not care, or assign any type of reputation information to HELO names,
which means a reputable name is as good as the sleaziest of names (like
I.am.a.spammer.com).
You can assign as much value to it as you wish. I mean, if a spammer
announces himself, in HELO, as "i.am.a.spammer.com", and it resolves
properly, then you are free to ignore what you want, and wait for SA to
examine the content of the mail. I, on the other hand, would go for the
early-out.
The only check that might be remotely valid is to check the A
record to ensure it matches the IP address.
Which would not be 'remotely valid', but 100% safe (barring
DNS hacks, of course).
Not exactly 100% safe as long as the IP address notation is
legal, since it can only be compared against the connecting IP address,
but cannot be looked up.
You missed the point: the bracketed IP literal is not an SPF-protectable
domain name that needs looking up even.
Would the HELO SPF check not be bypassed if the spammer says "HELO
[12.34.56.67]" ?
If by 'bypassed' you mean the spammer no longer uses an SPF-protected
domain name, then yes. :)
And would the MAIL-FROM SPF check not be also bypassed if the spammer
said "MAIL FROM <>" ?
No, because a check would be done against postmaster(_at_)HELO(_dot_)
At that point, the MTA is left with the only recourse to check the RBL
lists, or its own IP-based local reputation database.
See previous paragraph.
But I diverge slightly. Even though SPF cannot be used in this case,
using <> in this way will not help the spammers much, because the
postmaster itself will earn a bad reputation score, and we're back to
what I said above about the reputation difference between a familiar
domain name and an unfamiliar domain.
Since SPF is targetted at protecting domain names (the RHS of an email
address), I do not see how the reputation of the local part (LHS) plays
into this. SPF examines the legitimacy of the relay in question; a check
against postmaster(_at_)HELO will serve to make that determination; no more, no
less.
Regards,
- Mark
System Administrator Asarian-host.org
---
"If you were supposed to understand it,
we wouldn't call it code." - FedEx