Re: SPF and bouncing

At 08:35 06/04/2012  Friday, Michael Deutschmann wrote:
>On Fri, 6 Apr 2012, alan wrote:
>> either way no possible way to determine this (except spf fail) all
>> passes and neutrals are still possibly forged
>
>SPF-neutral is indeed unbounceable.

?? no mail is legitimatly bounceable, accept or reject there is no need to ever accept and later bounce

>  But if an SPF-pass mail is forged,
>it's the sender domain's own fault.  They signed off and should have known
>better.

the user sending from envelope from [email protected] is both likely and common
do-not-reply@xxxx is painfully common, which is why you reject (leaving the dead letter issue with the sender) or accept, but never bounce

>If they want to disclaim responsibility for a portion of the mailstream
>putatively from themselves, yet want to plead with people to accept it
>anyway, that's what SPF-neutral is for.

spf (generally) makes no claim as to the existance /non existance of the mailbox, just the authorised/non authorised status of the sending ip (for the domain)

>Configuring a smarthost to prevent end-users from using identities that
>they do not own (but that the same smarthost is indeed responsible for),
>is a far easier problem than arranging bounce-free handling of incoming
>mail.

not really, we do both, and i can tell you the submission server is way more work to setup and maintain, but its work thats both necessary and prudent to ensure our users do not become other peoples abusers

>> (few and far between, 3 users on my systems whitelist batv using
>> senders, and a .many-zeros1 percent of mail)
>So it doesn't scale to *automated* whitelisting and greylisting.
>
>Note that if the user actually tells you, "I want to whitelist
><[email protected]>, and I *know* they are using the BATV family of
>VERP", then you can add example.net to a local list of domains for which
>you can demangle the VERP before consulting the whitelist and greylist.

the user does this they whitelist x@y at rcpt
the system informs them that x@y has never had a rejection/acceptance (they usually don't read the docs) so call me to complain
i suggest that as we have seen a/b/c/d/e@y maybe the far end is using batv we look they are and they re-add x@y to their from: whitelist
or in many cases they whitelist *@y in rcpt as they doubt bob has any spammers working in the same company/domain

you see our users have no reason to whitelist by envelope-from in most cases as 
A its easily forged, B its easier to find why it was rejected and whitelist that ip/domain for that error

if mail from bob@example gets rejected cos bobs server greets with made-up_hostname.local then its easier for that user to add that ip/name to his whitelist of invalid but accepted by him helo's
or if bobs ip gets regularly in some rbl, whitelist that ip from rblchecks when sending to you user

all whitelists are per user so a users dumb whitelisting effects no one but themselves
(all users control their own policy most become adept at referring the sender to the rejection reason and insisting they fix it so they can use more draconian filters on their own address, rather than dealing with whitelisting dodgy senders)

the fact that bob@example uses batv becomes a non-issue
(actually few batv senders have ever had any cause for whitelisting, as few have any issues with ip-reputation,helo,spf dkim or anything else)

>But to do that without specific hints from the end-users, I'd want some
>kind of signal, such as a modifier in the VERPing domain's own SPF record,
>that tells me how to derive a whitelist key from the envelope sender.

not in any way SPFs job, if you want batv domains to self identify then you have to use another protocol, go off write one

>For BATV the algorithm would appear to be discarding a prefix up to and
>including the first two '=' characters from the localpart, but non-BATV
>domains might use '=' in other ways.  BATV isn't even an RFC, so the
>standing orders are that localparts must be assumed opaque.

batv and verp are both usually handleable via whitelisting by regexp on localpart, the regexp in question differs each time, if the user cant figure it they call me, but its not usually necessary and so far 0 users have needed to setup any as they just whitelist the ip(s) from whatever check the mail failed


>---- Michael Deutschmann <[email protected]>
>
>
>-------------------------------------------
>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=20120406033552:2180CD86-7FBB-11E1-B22B-D03858600CB5
>Powered by Listbox: http://www.listbox.com