Re: SPF and bouncing

On Wed, 11 Apr 2012, alan wrote:
> no spammers need to the forge the from

Most do so, preying upon senders who do not use SPF -all and recipients
who don't act on SPF Fail.  But others use their own domains, preying on
recipients who foolishly upscore on SPF Pass alone. (They also use DKIM
the same way.)

SPF Pass *and* a known sender is a quite strong indicator of non-spam.
But the known sender is essential.  {SPF Neutral or None, known alleged
sender} is a much more trustworthy mail stream than {SPF Pass, unknown
sender}.

> if the mailbox is full the backup MX should be 5xx or 4xx ing the mail

For there to be any point in a backup MX, the backup has to be able to
accept mail while it has no connectivity to the primary.  It thus cannot
rely on knowing precisely how full the mailbox is. 

A system can be engineered that is safe from out-of-disk problems.  While
in contact, the primary and backup agree on a space reservation the backup
can use when out of contact.  If the reservation runs out, then the backup
starts 4xxing outside senders.  When contact is reestablished, the backup
will unload the queue (always suceeding because the space was
pre-reserved), and attempt to refill its reservation (usually suceeding
but not if the mailbox is now over the quota promised to the end user.)

> >In the usual case where the primary does come back eventually,
> >then it can ETRN

The ETRN is purely in-bailiwick, between the primary MX and the backup MX
who are configured to use it.  It's never visible on the outside internet.
ETRN is a standard protocol to do this, but if it didn't exist I'd have
said "primary MX admin does something like `ssh backup-mx exim -qqf' "

> >and the waiting mail can be on it's way immediately.
>
> just as easily achieved

The point is that the recipient's backup MX is likely to know immediately
when the primary comes up, by explicit administrator action.  The sender's
smarthost does not.  Eventual delivery depends on the whims of the
sender retry schedule.

(I'll get to the rest of your original message later...)

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