Frank Ellermann wrote:
> <Valdis(_dot_)Kletnieks(_at_)vt(_dot_)edu> wrote:
>> you really *don't* want to have to poke around in the 822 headers
>> to find a 821-style return address (especially since if you *do*
>> that sort of grovelling, you will almost certainly Do The Wrong
>> Thing if you ever get a bounce with an 822-From *other* than
> +1 Or as RFC 3834 put it:
> If the response is to be generated after delivery, and there is no
> Return-Path field in the subject message, there is an implementation
> or configuration error in the SMTP server that delivered the message
> or gatewayed the message outside of SMTP. A Personal or Group
> responder SHOULD NOT deliver a response to any address other than
> that in the Return-Path field, even if the Return-Path field is
> missing. It is better to fix the problem with the mail delivery
> system than to rely on heuristics to guess the appropriate
> destination of the response. Such heuristics have been known to
> cause problems in the past.
Well, I think it goes back to "Final Destination" distinction.
I'm not entirely clear on this whole "final destination" thing you're talking
about - do you perhaps mean "final delivery"? If so, then we're talking about
totally different things here. If not, I guess you're referring to some point
past which the RCPT TO address is no longer subject to change, and I completely
fail to see how that is in any way relevant.
The main sort of automated agent that's a concern here is autoforwarders. A
nasty and hard to detect loop can form If an aufoforwarder changes a NULL MAIL
FROM to point at the autoforwarder itself while redirecting the message to a
remote address that turns out to be invalid.
In this situation the autoforwarder is acting before final delivery has
occurred. Moreover, the autforwarder in general has no way to tell if the RCPT
TO address is the "final destination" or not, and even if it did know, I don't
see any way the information could be used to cause it to "do the right thing".
Once final destination has been been established, there is no need for a
return path, null or otherwise.
Not that it is relevant, but RFC 3798 is an obvious counterexample here -
proper MDN generation depends critically on return-path information and MDNs
are routinely generated long after the actual destination has been determined
and final delivery has occurred.
It is quite possible that a gate will
eliminate useless network control lines when final destination is a
foregone conclusion. The same is true for any post smtp mailbot.
The key is the automation that is transparent of the policy reasons.
All the above paragraph means is that the SMTP receivers needs to
support adding the return-path,
Stuffing the MAIL FROM into a return-path header is part of final delivery.
We're talking about routing modifications made before final delivery takes
place and often without any information about whether further routing will
and that its remains persistent through
out the entire routing and/or mail processing until final destination is
established, at which point it no longer applies.
Again, this appears to be at odds with MDNs semantics at a minimum.
It also seems apppropriate to caution against any more stringent restrictions
on MAIL FROM modifications. Changing a non-NULL MAIL FROM to some other value
isn't exactly uncommon.
What happens after that is out of SMTP automation controls.
Consider the automation logic:
1) If the return path is NULL, then no response related the current
transaction is expected to be generated. What an external mailbot does
with transaction is out of the controls of SMTP, so all you can provide
is insight for post smtp mail processing authors to understand that no
response is expected as part of the automation process.
OK, but again, this all seems to concern actions taken after final delivery.
2) If the return path is NOT NULL, then responses are possible to this
address. (AFIK, there is no known common user part that restricts a
response to this non-null address)
3) The return path must remain persistent until the routing and final
destination is completed.
MAIL FROM information is persistent but mutable. And that's the problem -
one particular type of change can cause serious problems and needs to be
4) If final destination is negatively established (i.e, address or user
dosn't exist), then the persistent return-path MUST be used for the
5) Once final destination is successfully established (user exist and if
applicable acceptable by local or user policy), the return path value is
no longer applicable - Not Needed.
It's no longer needed in the sense of reporting errors for the current message
transfer activity. However, the field's semantics are broader than message
transfer error reporting.