Re: SPF and bouncing

Alessandro Vesely <[email protected]> Mon, 07 May 2012 13:17:15 +0200
Newsgroups gmane.mail.spam.spf.discuss
Message-ID <[email protected]>
On Mon 07/May/2012 10:46:16 +0200 Michael Deutschmann wrote:
> On Sat, 5 May 2012, Alessandro Vesely wrote:
>>> 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.
> 
> No, it has nothing to do with [] in addresses.

In any case, address literals are a limit for evaluating HELO.

> The problem is that the HELO domain is of no use in determining if an
> incoming MAIL FROM: <> has anything to do with a message you actually
> sent in the past month.

You seem to imply that messages bearing a null-mailfrom must be
bounces.  Actually, it is the opposite way around: bounces must bear a
null-mailfrom.

BTW, during the weekend I run three tests on different samples of
about 25K domains each, counting how many domains reject a "bad"
sender but accept a good one upon a RSET.  Reject/accept percentages
result as follows:

reject-on-fail a:     1.11%
reject-on-fail b:     1.21%
reject-null-mailfrom: 0.24%

> gmail.com's MXes and smarthosts are kept within the domain of their
> corporate sponsor, google.com.  If gmail.com were ever to issue a bounce,
> it would likely bear a HELO ending in .google.com.  So a naive algorithm
> that said "let a purported bounce through if the HELO is SPF-approved and
> is equal to or a subdomain of any domain we have mailed to in the past
> month" would fail badly for at least one major site.
> 
> Drop the "is equal to or a subdomain" requirement, and any spammer who
> wants to exploit the <> loophole will do so using a HELO domain that he
> fully owns.  Then it's trivial for him to engineer a genuine SPF Pass.

It is equally trivial to engineer such a pass using MFROM.

You have a point there, though.  The helo identity is not a 1st class
citizen of any reputation system.  Even if it were mail.gmail.com, it
would not be reliable to make guesses at zone cuts.  Moreover, as Alan
points out, many helo names are unrelated to the branded domain.  For
the tests above, I found about 50% unique MXes/domain;
thus, if outgoing mail flows symmetrically, an helo identity serves
about two domains, on average.