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
Mailer-Daemon).
+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.
Once final destination has been been established, there is no need for a
return path, null or otherwise. 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, 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.
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.
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.
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
non-delivery notification.
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.
Correct me if I wrong, but the above logic applies to all systems -
transparently. I don't see any scenario that can alter this fundamental
long time practice - it is all part of what makes it all works.
The only issue I think that is partially lost in this thread is *when*
or at what point is *final destination* established.
This is very important design and implementation point because old mail
models did not have the SMTP receiver did not make Final Destination
decisions. Typically it was the SMTP ROUTER that made that decision:
Older model:
Receiver (no final destination decision made)
temp msg received --> msg stored in spool\queue
Router:
Local mail --> queue\msg is stored in spool\inbound
Relay mail --> queue\msg is stored in spool\outbound
And in more current models, the same may be true, but the Receiver may
make a preliminary Final Destination decision as part of the logic to
implement bounce attacks:
Current and more model model:
Receiver (preliminary: final destination decision made)
C: RCPT TO:<some address>
250 - USER FOUND
45x - USER FOUND (For some policy reason, temporary reject)
55x - USER NOT FOUND (domain is locally hosted)
55x - RELAY AUTHENTICATION REQUIRED (domain is remote)
The point is that in the newer models the Return-Path value increases
and is more reliable at this point. Regardless if NULL or not NULL, in
this model, it is meaningless. It has no value. In fact, adding the
Return-Path for some post smtp mailbot shouldn't be a consideration
because it no longer applies.
--
Sincerely
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com