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
in-transaction 5xx.
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
/
Border
-- Dave
-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Archives: http://v2.listbox.com/member/archive/735/=now
RSS Feed: http://v2.listbox.com/member/archive/rss/735/
Modify Your Subscription:
http://v2.listbox.com/member/?member_id=2183229&id_secret=94581934-49a97b
Powered by Listbox: http://www.listbox.com