Re: SPF and bouncing

At 03:42 06/04/2012  Friday, Michael Deutschmann wrote:
>On Thu, 5 Apr 2012, alan wrote:
>> ok firstly "unbouncable"? i assume you mean "possibly non-existant
>> address" as there is no way to determine this
>
>No, more like "possibly forged addresses".

either way no possible way to determine this (except spf fail) all passes and neutrals are still possibly forged

>Specifically, if it is dangerous for you to neither violate the RFCs nor
>deliver it forwards, then it's unbounceable.  (One quirk of this
>defintion is that <> is not as unbounceable as a random no-SPF-record mail
>address, as the RFCs say not to try...)

if you do not wish to deliver forwards you reject, there is no 'bounce'

>Bouncing to a real but forged and non-SPF-validated address probably won't
>result in a deadletter.  But it's still dangerous because it will get
>people ticked off and sending their antispam gurus to contain you.

bouncing is never acceptable, reject or accept, there is no need to ever bounce
bouncing again is accepting and then rejecting afterwards

>The only mails that are bouceable in 2012 are SPF-pass mails (maybe...),
>and mails that bear putative sender addresses that are within your own
>bailiwick.

no mail is ever bounceable (receiver side) the idea of accept then bounce (instead of just rejecting during transaction is pure stupidity)

>> > But you often won't succeed, because a large proportion of *desired*
>> > mail has no SPF information.  (I see 72.9% year-to-date)
>> spf is only a tiny tiny factor in the accept/reject decision
>
>I don't mean "lack of SPF information causes you to fail to identify the
>message as bad in time to reject it in-transaction".  I meant:
>
>Lots of mail will pass all reasonable spam tests, because it actually
>isn't spam.  And a bit more spam will squeak through in practice.  But most
>of this stream has no SPF information, so mail in this stream can neither
>be rejected in-transaction nor be rejected via bounce.

all mail you wish to reject in transaction is rejectable (spf or not)
the only person who could suffer is the sender (who may backscatter the forged users in response)
and they should suffer, and through the blacklisting they receive either cleanup or get out
either way their problem isn't your issue, and has zero effect on your reputation

>> maybe back in the days when all ran open relays (thus you could make
>> any of these a backup MX for yourself with/without permission simply by
>> adding their servers to your MXs)
>
>Open relays were common then, although the practice was already regarded
>as a great offence.
>
>Back in 2001, I was acting as an unofficial advisor to my own ISP on spam
>issues.  The admin there asked me about the safety of deploying sender
>verify on Exim, in order to reduce a flood of deadletters that was
>annoying him.  (Note: this was oridinary sender verify, where just the
>existence of an MX is checked -- not the abusive callout feature.)
>
>I advised him that there was no danger in doing so, but that the
>deadletters were just part of an underlying problem that would not be
>fixed by the measure.
>
>So he was running a system that was a backscatter hazard by today's
>standards, and didn't care very much except where (via deadletters) the
>problem impacted him.
>
>> you have to let the connection go to data for DKIM, spamassasin, av
>> scanning etc etc too, dealing with multi RCPT mails has been no issue
>> for any of those.
>
>But letting everything go to DATA in hopes that a content analyser will
>"rescue" a mail where the RCPT-level checks give a negative vote is
>rather radical.

it only goes to data for users who use sender whitelists for batv senders
and only if mail-from-domain == one of the batv whitelisted domains
(few and far between, 3 users on my systems whitelist batv using senders, and a .many-zeros1 percent of mail)

I never suggested going to data to rescue from rcpt level fail (and never would)
connection/helo/mail-from/rcpt level fails 5xx at rcpt
rcpt level passes still have to pass possible data level checks
and if userA counts a spamassasin fail at score 5 and userB uses 6
then as i explained a mail sent to both passing rcpt level checks for both (as both can set these seperatly too)
would get a success for first recipient and a 4xx on second
so userA gets his data check on first try and rejects after data if score 5 or above
userB is the only recipient of the retry and rejects after data if a score 6 or above


>---- 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=20120405224216:1DD7E878-7F92-11E1-A647-8BF664F78E3D
>Powered by Listbox: http://www.listbox.com