-----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: vrijdag 6 mei 2005 7:04
To: spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
Subject: Re: [spf-discuss] Re: HELO versus MAILFROM results
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.
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.
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: <>).
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. That is like saying I can 'bypass' DomainKeys
checks on a receiving MTA, by not doing DomainKeys! 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.
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).
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.
- Mark
System Administrator Asarian-host.org
---
"If you were supposed to understand it,
we wouldn't call it code." - FedEx