Re: SPF and bouncing

Alessandro Vesely <[email protected]> Sat, 05 May 2012 13:08:00 +0200
Newsgroups gmane.mail.spam.spf.discuss
Message-ID <[email protected]>
On Sat 05/May/2012 11:42:27 +0200 Scott Kitterman wrote:
> On Friday, May 04, 2012 08:45:33 PM Alessandro Vesely wrote:
>> On Fri 04/May/2012 20:20:10 +0200 Scott Kitterman wrote:
>>> On Friday, May 04, 2012 05:12:14 AM Michael Deutschmann wrote:
>>>> To avoid spammers using "MAIL FROM: <>" as a "skeleton key" that opens
>>>> all the mailboxes, a whitelisting site would have to use VERP such as
>>>> BATV.  But automatic whitelisting fails when other people VERP in the
>>>> same way.  We have a sustainability problem.
>>> 
>>> The way that SPF attempts to deal with null mail from now is with HELO
>>> based checks.  These are arguably far less useful.
>> 
>> Why?
> 
> Because the HELO name can be anything, so arranging for an SPF HELO pass is 
> trivial.

You must mean address literals, which are mostly used by MUAs AFAIK.
Addresses like <postmaster@[66.39.2.7]> most likely don't work.
With that exception, the domain of an MFROM can be anything that a
HELO name can be.

At any rate, arranging for an SPF HELO /neutral/ is trivial.  A HELO
/pass/ is as reliable as a DKIM pass: both of them authenticate a
relay by referring to the corresponding DNS zone.

>>> Spammers have not adapted to SPF by moving to null mail from's.
>> 
>> That's a well known recipe to get your message rejected, see
>> http://www.rfc-ignorant.org/policy-dsn.php
>> 
>> I wonder whether reject-on-fail is statistically more relevant than
>> reject-null-mailfrom.  In any case, from a spammer's POV, it makes
>> sense to try and avoid both of those pitfalls at the same time.
> 
> True.  So maybe SPF just shouldn't care about that case.  No Mail From, not 
> our problem.

I agree that HELO checking is somewhat ambiguous by design, since it
is optional, but its result can neither cause rejection[*] nor be
merged with the result of the mandatory check.  However, pruning it
doesn't seem to yield grand simplifications either.

[*] HELO checking won't deliver a fail, unless misconfigured.  That
is, anyone can say "HELO hostnotfound.google.com" and get away with it.