Re: SPF and bouncing

At 12:08 05/05/2012  Saturday, Alessandro Vesely wrote:
>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.

helo authentication can be a great idiot filter (not spamsign but like ptr>A>ip FQRDNS check can be great reason to reject)
as long as whitelisting is possible for some idiots

non-pass if spf exists is pretty much a guarenteed reject for most of my users (except for facebook, as most of their servers have broken helo spf or broken helo A records)

>>>> 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.

not immediate reject (just like connecting from blacklisted IP, the reject happens at RCPT time the reject message says why)
its not mis-configuration its sanity checking, and a good way to filter both bots and mailservers that a setup badly (thus unlikely to be sending anything usefull/wanted)
as mail has gotten to the rcpt stage the user can see the mail-from helo-id ip and fqrdns in their reject log and whitelist if neccissary, more-often they will just point the far side at our 'how you should setup your mta' guide and let them fix the issue that caused the reject, rather than turning off the checks and maintaining their own whitelist. 

when you give users the option and they see the amount of spam it cuts from their spambox they usually exercise it, and thus senders are forced to distinguish themselves better from spammers/spambots. 

helo pass is trivial for a legit mta, any hardfail softfail or neutral is pretty inexcusable



>-------------------------------------------
>Sender Policy Framework: http://www.openspf.net [http://www.openspf.net]
>Modify Your Subscription: http://www.listbox.com/member/ [http://www.listbox.com/member/]
>
>Archives: https://www.listbox.com/member/archive/735/=now
>RSS Feed: https://www.listbox.com/member/archive/rss/735/13124949-0b42f103
>Modify Your Subscription: https://www.listbox.com/member/?&
>Unsubscribe Now: https://www.listbox.com/unsubscribe/?&&post_id=20120505070834:A702220E-96A2-11E1-BAEA-F4BFA65CF08C
>Powered by Listbox: http://www.listbox.com