Re: SPF and bouncing

On Mon, 7 May 2012, alan wrote:
> ok so basically your wanting to add stuff to spf because you want an easier way to do goldlisting
> (seems to be the crux here)
> so your assuming anyone wanting to talk to your goldlisting implementation will
> choose to use your new spf (if they use batv/verp
> care to pass your filters

I'm actually more concerned about the outgoing side of the equation.  I
want to keep it easy for other people to whitelist and greylist *me*.

To that end, assuming no reform possible in any protocol, I'd rather be
"RFC-ignorant" and reject <>, than use VERP and tangle up other people's
sorting of my (non-bounce) mail.

But if a standard SPF VERP modifier was added, and there were signs that
greylist and whitelist using recipient sites were listening for it, then
my scales might tip away from rejecting <> and towards VERP....

> (ie more so than nether side being informed of the mail dissapearing
> into the void)

It doesn't have to disappear into the void.  The proper way to handle it
is to declare that for handoffs from MX to internal mail store, there is
no such thing as a permanent mail failure.  Smarthosts react to a 5xx or
prolonged 4xx by generating a bounce (they can avoid backscatter with
AUTH), but the procedure for an MX should be to place the failed message
in a special hold queue, only flushed by explicit admin action.

When such a 5xx occurs, the MX automatically sets a flag to start 4xxing
everything incoming to the failed destination domain, then alerts its own
admin, who attempts to contact the internal mail store admin to fix the
configuration problem leading to 5xx.  When the internal mail store admin
reports the problem is fixed, the MX admin flushes the hold queue, and
then only after that delivery is complete, releases the 4xx flag.

Yes, this does mean the internal admin can be forced to let a mailbox grow
into disk space the actual end user never paid for.  My faction of the
conspiracy is aware of this but doesn't care.

A nice side effect of this hard-handed approach is that it blocks the
kind of bounces you agree are unacceptable for free.

Delivery is only truly impossible when the destination address doesn't
actually exist.  But failing to detect that problem in-transaction is
just as bad as doing spam filtering late.

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