Radu wrote:
However, I still think there is no point checking the HELO.
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 SPF check is so easy to bypass, it's not funny.
Mark wrote:
As per 2.1, The HELO Identity, if the HELO test returns a "fail", the
overall result for the SMTP session is "fail", and there is no need to
test the "MAIL FROM" identity. 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.
If a spammer starts the mail conversation with "HELO sci.fi" he has
essentially thwarted your attempt to get a "FAIL" from the HELO.
This is what I call bypassing the HELO check.
Of course I didn't mean that the entire SPF suite of checks can be
bypassed, just that the HELO check is extemely easy to render useless.
The remote spammer has full control over what SPF result you will
evaluate at HELO. That's what makes it useless to check.
If the spammer wants you to see "NONE", he says "HELO sci.fi"
If he wants you to see "PASS", he does as follows:
To add insult to injury, if he said "HELO I.am.a.spammer.com", and published
I.am.a.spammer.com TXT "v=spf1 +all"
1. So what are you going to do? Block HELO's that resolve with "PASS" ?
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.
Since *nothing else* depends on the words whispered in helo, it can be
any arbitrary string that meet a very simple requirement: it should
exist in the "global DNS database".
Unfortunately there is no required relationship between the domain name
in MAIL FROM and the name in HELO. If there were a way for a domain to
say "I only send mail through these mail servers identified by their
HELO", then perhaps HELO would be worth something.
As per 2.2, The MAIL FROM Identity, when the reverse-path is null, this
document defines the "MAIL FROM" identity to be the mailbox composed of
the localpart "postmaster" and the "HELO" identity. So, all a spammer can
do with a fake HELO/EHLO name, is send a DSN (with MAIL FROM: <>).
It's a good idea to have _this_ check (ie, postmaster(_at_)HELO, but only if
it is a non-returnable mail (FROM <>)).
It is not a good idea to do the HELO check if the MAIL-FROM is a proper
email address because:
1. The HELO tells you nothing.
2. The HELO is not something the sender has authorized with his SPF
policy. The SPF policy authorizes IP addresses, not HELO names. (Yes,
you could bridge the gap by adding a series of a:{HELO names} to an SPF
policy). Indeed most policies do exactly the equivalent of this.
Your whole idea of 'bypassing' is flawed; in your definition, you could
simply 'bypass' SPF checks by using a domain in HELO/EHLO for which no SPF
records are published.
You misunderstood. You can bypass the HELO check this way, but not the
MAIL FROM.
As I pointed out before, the MAIL-FROM is not so easily bypassed. I'll
give an example:
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.
On the other hand, a random domain name such as sjdjfhasdj.blah.com gets
the suspicious treatment (+3) until my tools figure out if this is a
spammer or not. If the tools figure it's a spammer, the score increases,
otherwise it automatically decreases.
This difference of reputation between known domains and unknown domains
is the incentive for a spammer to try to forge as reputable of a domain
as it can find. This is because using the Bayesian derived spam score,
his letter gets +3.
So, if he forges yahoo, the overal spam score will be +1, if he uses a
random name for his MAIL FROM, his overal spam score will be +6.
Due to this difference, it's not smart for a spammer to use random
strings in the MAIL-FROM.
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)
That is like saying I can 'bypass' DomainKeys
checks on a receiving MTA, by not doing DomainKeys!
In fact, that is precisely how you can bypass DomainKeys. :)
This is because when you receive mail from a domain, there is no way to
know if you should be expecting to find a domain key or not.
A domain key is also only as good as the reputation earned by messages
signed with it. So a domain key from a brand new domain that you know
nothing about is not worth anything. In fact, you don't even need to
bother checking it until your MTA figures out that the respective domain
sends mail that is wanted.
A proper case of real
bypassing, however, would be, if you managed to use a domain in MAIL FROM
/ HELO / EHLO which, under normal circumstances, would yield a 'fail'. For
instance, if you succeeded in using 'asarian-host.net' in your HELO of
MAIL FROM identity, sending through an unauthorized relay, and avoided a
'fail' at the receiving MTA doing SPF checks.
Let's keep focus here:
I'm not objecting at all to MAIL-FROM checks with SPF.
It is only the HELO checks that I object to (and even then, I agree with
the use of HELO in case of <>, but *only* in that case)
Perhaps it would help to think about the possible combinations:
HELO Check MAIL-FROM check what to do
PASS PASS
FAIL PASS
PASS FAIL
FAIL FAIL
I think the PASS-PASS and FAIL-FAIL cases are obvious.
I think this table should look like this
HELO Check MAIL-FROM check what to do
PASS PASS deliver
FAIL PASS deliver
PASS FAIL reject
FAIL FAIL reject
I deliver for FAIL-PASS because even though the mail may be arriving
through a misconfigured MTA, the sender domain would want me to deliver.
I reject in the PASS-FAIL case, because even though the connected MTA
wants me to deliver, the sender domain wants me to reject.
It's the sender domain's policy that I care about ultimately, not the
connected MTA's. The connected MTA may be under the administration of an
incompetent ISP. That should not prevent the actual vanity domain owner
to express with his SPF policy, how he would like his email treated.
since in the table above, the "what to do" column is equivalent to the
"MAIL-FROM" column, the HELO column seems to have no effect, and thus
it's a don't care.
Remember that *any* domain publishing a wildcard is a good
candidate for an endless supply of randomly generated HELO names that
mean nothing. but could be inserted into SpamAlot v12.9
Yeah. And remember that *any* domain for which no SPF records are
published can be used by a spammer to 'bypass' (ahem) SPF checks. So? The
point of SPF is not so spammers can find domains for which no SPF records
are published yet, but to protect those domains that do!
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. Even if you do do a PTR lookup on it, what does it mean?
But that's not SPF, and it can also be
easily faked with the [1.1.1.1] notation.
Faked? That logic is as specious as it is false. Since an address literal
enclosed by brackets is not a domain name for which SPF might offer
protection to begin with, nothing is really faked, nor bypassed by this
notation. See my above comment: in such cases (and it were not a DSN), the
software would simply fall back to doing a regular SPF check against the
MAIL FROM identity. And if it were a DSN, you managed to 'fake' [1.1.1.1],
a non-SPF protectable entity to start with.
Ok, ok... 'faked' is not the right word here. Perhaps "the host name is
conveniently unavailable so I am forced to use my IP". The spammer is
lying, because he could very well do a reverse lookup on his IP address
and find the name to put in the HELO, or sign up for dyndns, and provide
you with a name in a different domain, but which resolves to the same IP
address.
Would the HELO SPF check not be bypassed if the spammer says "HELO
[12.34.56.67]" ?
And would the MAIL-FROM SPF check not be also bypassed if the spammer
said "MAIL FROM <>" ?
At that point, the MTA is left with the only recourse to check the RBL
lists, or its own IP-based local reputation database.
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.
Regards,
Radu.