dmquigg-spf at yahoo
Feb 6, 2008, 4:58 PM
Post #10 of 11
At 06:09 AM 2/6/2008 -0800, Michael Deutschmann wrote:
>The only way to avoid backscatter of non-SPF-pass messages is for them to
>always be delivered forward. Within a single administrative domain, this can
>be arranged, with inner mailservers told to suspend all judgement of mail
>relayed in from a border MX.
>It gets problematic when more than one administration is involved, such as
>an externally administered backup MX, or of course forwarding. Here, the
>border MTAs can fear being "betrayed" by the inner MTAs, via an
>To make betrayal a poor option for the inner MTA, I suggest that border MTAs
>should apply the following brutal tactics:
>1. Add a state to each message in the queue, which can be one of:
> B - bouncable
> U - unbouncable
> H - unbouncable, held
> R - unbouncable, re-queued
>2. Every message begins in U state, unless it has a non-null MAIL FROM that
>recieves an SPF Pass, in which case it begins in B state.
>3. If a B state message fails to deliver (in-transaction 5xx or
>in-transaction 4xx for "too long"), it is bounced normally.
>4. If a U state or R state message fails to deliver, it is not converted to
>a bounce, but instead transformed to H state and left frozen on the queue.
>No automatic attempts are made to deliver H messages.
>5. A border-MTA administrator can manually issue a command that all H-state
>mail targetted at a specific address or domain be transformed to R-state,
>which will re-start delivery attempts. This is an explicit, manual exception
>to the general rule that 5xxes are final.
>6. So long as a single R-state or H-state message is on the queue for an
>endpoint, no new e-mails that would be U-state will be accepted for the
>target. Instead, they will recieve in-transaction 4xx or 5xx.
>7. The border-MTA administrater will be alerted when a message enters
>H-state. Normally he will then contact the inner-MTA admin to let him know
>he needs to fix his system. If the inner-MTA admin assures him the problem
>is fixed, then the border-MTA gives the requeue order, and once the
>resurrected deadletters exit the queue, normal relaying resumes.
Excellent! This is good text for a BCP, if we decide to write one.
We might be able to reduce the burden of this procedure on Forwarders, if we "redistribute" some of the responsibilities to other Agents, in particular the Recipient. If the Recipient is required, when he sets up a Forwarder, to provide a reliable alternate path for communications (e.g. another email address, a postal address, or a phone number), then the Forwarder can contact him to let him know there was a problem at his MDA.
If the alternate path fails, or the Recipient simply abandons his responsibility, then discarding the dead message after 30 days is appropriate. It's no different than what his MDA would do. It's also a procedure that can be fully automated by the Forwarder.
Again, the situation I'm thinking of is:
|-------- Recipient's Network ---------|
--> / --> Receiver/Forwarder ~~> MDA ==> Recipient
Sender Policy Framework: http://www.openspf.org
RSS Feed: http://v2.listbox.com/member/archive/rss/735/
Modify Your Subscription: http://v2.listbox.com/member/?member_id=1311532&id_secret=94625558-8b4c32
Powered by Listbox: http://www.listbox.com