[Top] [All Lists]

Re: 2821bis and address rewriting

2007-11-22 03:18:35

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


   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.


Hector Santos, CTO