Re: SPF and bouncing

At 08:50 08/04/2012  Sunday, Michael Deutschmann wrote:
>On Sat, 7 Apr 2012, alan wrote:
>> may i suggest we take this offlist as I'm sure the debate about
>> bouncing is really of no interest to (and definitely not really relevant
>> to SPF at all)
>It is so germane to SPF, because we are discussing how SPF Pass changes
>(or doesn't change) the situation.

you may be I'm saying It doesn't and shouldn't

>As regards the no-SPF and SPF neutral-or-worse cases, I support the
>Conspiracy unreservedly.
>
>> we do not allow users to block for <> alone ever,
>
>What if they blacklist an IP address range, and whitelist a specific
>e-mail address that happens to come from a smarthost in that range?

then the block is on ip and thus dosn't reference mailfrom as the issue obviously


>Goldlisting is just the subset of that case where 0.0.0.0/0 is on the
>private host blacklist.

gold listing actually involves blacklisting mail from <*@*> except the goldlist
ip is not a factor in goldlisting

why i said our users are advised to use more secure methods
(if you blacklist an ip then from is no longer even considered whitelisted or not)

>> ok this is the one time bounces MAY legitimately occur (disk quotas)
>Ooooooooooooh.  So you're not a full conspiracy member after all.

there is no conspiracy, there is only constructing systems in a way that they are useable
(dont bounce or blackhole any mail)
and do not cause an abuse burden for others due to administrative lazyness or poorly engineered solutions

>Back in 2009, I was part of an argument on the now defunct
>news.admin.net-abuse.blocklisting group with a guy named D.Stussy.  He
>was protesting that some of UCEProtect's backscatter list traps did not
>have SPF records.

why would they need spf records if not sending mail
(but equally yes every a or mx in a non-abusing domain should have an spf of "v=spf -all" if not doing mail or used in helo, and v=spf ~all if just a disbeliever in spf and doing mail)

>He considered it impossible to avoid bounces due to quota issues, and
>thus held that only people with strict Pass-or-Fail SPF records,
>allowing every last forgery to be detected and refused at the edge, were
>entitled to freedom from backscatter.

no one is entitled to freedom from backscatter/spam/abuse/annoying people/etc/etc??
we ARE entitled to complain/report/refuse all of the above ONLY

we equally have a duty to our users to not disrupt their mail and to others to not pollute the ecosystem.
so refusing bounces that may be legitimate to our users (which they want and need) would be stupid
(knowing many systems out there DO generate them)

equally we have a duty to not allow our systems to generate bounces to others (except when entirely unavoidable) and even then to ensure we minimize them (by in say overquota situations causing our user (the cause of the issue) to have extended problems receiving due to mx caching of the overquota status rather than generating 1 bounce per mail to innocent 3rd parties if we didn't)

also in the above case (say my domain with -all) how does this free me from backscatter from sender-smarthosts that allow their users to send mail forged from me, refused and then sending me the bounce??
(why i would then report them and add them to our own backscatter source list) so my users can choose to drop <> mail from them if they want to avoid backscatter or block all mail from them (if they want to avoid the spam that would be sent from such an abusable smarthost also)

>I wonder which side you'd have been on, were you there.  Remember, we were
>explictly discussing *ALL* bounces, not just those arising from stubborn
>end-users who want to contentfilter away from the edge.

subbourn end-users don't and cant generate bounces, dumb/lazy/badly engineered receiving systems can and do, not their users.
(why shunning such systems causes the to get fixed or have their users leave)

you simply cant deal with all <> mail equally its idiotic to do so
as these can be 
NDRs (bounces)
DSNs (mail not delivered yet)
autoreplys several ticketing systems and transactional mails where the sender is uninterested in knowing if the target received the message or not.

we on the other hand only generate <> (as far as were aware) for user overquota (DSN and NDR) or system down for over 8 hours (DSN)
we currently havn't had a customer system down for long enough to switch to 5xx to avoid excessive DSNing senders
(but we would rather cause them the pain than cause the net a DSN flood)
and ensure overquota causes 1 NDR per 15 mins max

I know some idiots do drop all incoming <> 
(their systems their problem)
but i equally know of many companies that due to this had to change mail provider to someone who didn't