Re: SPF and bouncing

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

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

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.

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

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

---- Michael Deutschmann <[email protected]>