Re: SPF and bouncing

At 00:52 05/04/2012  Thursday, Michael Deutschmann wrote:
>On Wed, 4 Apr 2012, alan wrote:
>> >that means that mailservers have to be prepared to accept
>> >unbounceable mail.
>>
>> the opposite they should accept or reject at their edge, once the
>> decision is made though they should not later change their minds.
>
>They can reject *some* of the unbounceable mail at the edge.  But even if
>we optimistically assume that SPF-pass mail is bounceable, rejecting an
>email (in-transaction, of course) *solely because* it is not bounceable is
>a non-starter in 2012.

you don't reject based on if its bounceable?? (as you never bounce any mail so its a non-factor)
also spf pass says nothing about the from address's validity (except in a few edge cases like me who have per user spf)

you reject based on, spammyness, sender reputation, local policy, content, spf-fail dkim-fail whatever ONLY

>> what conspiracy??
>
>The "Conspiracy Against Bounces".  I call it that because it is a
>substantial change in the ground rules of SMTP that was never codified in
>an RFC.  It's just a majority of admins on the ground deciding "We hate
>backscatter, and we can fight it the same way we do direct spam.".  The
>fact that now any mail accepted at the edge must be delivered all the way
>in (unless you break RFC and blackhole) was an accepted consequence.

this is not recent thinking, this is more a reaction (backlash) against the increase in idiotic setups that emerged that did stuff like accept (spamfilter) then test if recipient-exists, and create bounce.
additionally the spam/av filters that didnt reject but bounced to the obviously forged from

so yes at some point we collectively decided no-more of this idiocy

>Note that I support the CAB.  So do you (quite enthusiastically!).
>
>> if worried about forged <>
>> BATV is a simple and easily implemented way to reject forged bounces
>
>BATV is a kind of VERP, and VERP interacts poorly with whitelisting and
>greylisting.

there are ways round the whitelisting issues as long as your users are allowed to whitelist by ip+from: (from as opposed to envelope-from) (mail gets past rcpt by envelope-from domain being within one thats later from: whitelisted)
(as if they use batv the sending ip is quite predictable)

>Lately I've been considering programming my mailserver to automatically
>whitelist anyone I send to.  But if the other guy uses VERP, the envelope
>recipient I mail to is not the same as the envelope sender who will reply.

simply whitelist the domain from RCPT-reject, if from:(in data) differs from whitelisted address then reject after data IF you would have otherwise rejected at RCPT 

i find its a lost cause as most spam i see is from old friends accounts (long abandoned) now cracked/harvested and re-abused
so i whitelist few but by IP (trusted senders who are known non-emitters) or by from: when from otherwise untrustable fremailers (but only if received from validated sending ip's for those freemailers)