Re: HELO versus MAILFROM results

Alex van den Bogaerdt wrote:
> True, under very limited circumstances.  And I doubt that these
> circumstances would occur for people publishing SPF.  Even if they
> do occur, why would this be an argument not to check every other
> case?  Where domains are used, they have to be the FQDN of the host
> making the connection.  The owner of this FQDN is able to specify
> that you and I are not allowed to use his/her domain name.
>
> Your argumentation: "... the results of a DNS loookup on them
> would be *undefined*" (sic) doesn't hold.  Either the argument
> is a FQDN, one which can and should be checked, or it is an
> address literal which can be checked by other means.
>
> Yes, some (many?) domains do it wrong nowadays.
> Yes, they aren't all spammers or other malicious types.
> No, this does not mean we should remove the check.
It has been customary so far for spammers and phishers to exploit the
weakest link.

Initially, they would put "viagra" in the subject line.
Then, a procmail rule was invented to kill mail with such words in the
subject.

Then, they put v1agra in the body.
Then, a spam filter was invented heuristically calculate the probability
of a message being unwanted.

Then, they started sending mail "from paypal.com"
Now we are inventing SPF.

Next, they will use IP literals in their HELO to bypass the SPF check
partially, and maybe look up records that are liberal enough to
authorize IP's that are available to the spammer.
Next, we'll give up checking the HELO with SPF, because it's only used
for the honest guys, and the bad guys can easily bypass it. At that
point, it costs DNS traffic for those senders that would pass on
MAIL-FROM alone, but does not help any forgery prevention.

What happens after that is only speculation, and it seems that my
imagination can come up with scenarios that are worse than most people
are willing to accept today. So, I won't go into them :)

The reason why we should remove the HELO check is because it's a hack
with temporary effectiveness. Maybe it will work for a little while, but
 in the long term, its likely the DNS traffic spent on it is a waste.

Furthermore, when the HELO check stops working on a grand scale, it will
be obvious that the time we are now spending to implement it could be
better spent on other things.

Remember, all it takes for the HELO check to stop working is that the
next version of the spam/phish engines use a different string value for
their HELO. A 2 line change in the source of spamware, plus 1 year to
allow for market penetration of the new version is enough to render this
HELO check useless. In fact, as you mentioned, much spamware already
uses IP literals, so we are half-way there already.

> > The fact remains that the word following the HELO is not guaranteed to
> > be an FDQN.
>
> In such cases, it is clear that it is not a FQDN so SPF checking
> does not apply.  In all other cases, SPF can be setup such that
> HELO can be checked.
>
> Pseudo code:
>
> usual_helo_checks($helo)
>    such as local blacklist
>    such as local whitelist
>    such as checking for being malformed
>    such as spoofed local addresses/names
> if _argument_to_helo_is_fqdn($helo)
> then
>    check_host($helo)
> fi
That's good. I fully support the HELO string being checked against other
 local databases, as the local admin sees fit.

I do opose the check_host, as it sends DNS traffic uselessly to innocent
parties (ie forged domains will get DNS traffic that largely doesn't
help the recipient at all).

Regards,
Radu.

-------
Sender Policy Framework: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
Read the whitepaper!  http://spf.pobox.com/whitepaper.pdf
To unsubscribe, change your address, or temporarily deactivate your 
subscription, 
please go to 
http://v2.listbox.com/member/?listname=spf-discuss(_at_)v2(_dot_)listbox(_dot_)com

smime.p7s
Description: S/MIME Cryptographic Signature