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.