[Top] [All Lists]

Re: 2821bis and address rewriting

2007-11-18 20:07:34

ned+ietf-smtp(_at_)mrochek(_dot_)com wrote:

I suggest the following change to Section 4.5.5 (Messages with a null

If a reverse-path is null, it SHOULD NOT be modified as
>>   that is likely to cause a mail loop.

I think citing loop prevention as the reason for this recommendation is a good idea, but think this overstates things a bit - it creates a
> condition where loops are possible, but not necessarily likely. So
> change it to say "SHOULD NOT be modified as this can cause
> mail loops" and I'm happy.

Hi Ned,

Question, is a NULL return path a final destination idea?

If so, then maybe a statement or clarification could be finessed:

   A null return path is considered a final destination
   transaction.  To avoid the potential of creating mail loops,
   if a reverse-path is null, SMTP accepted messages handled
   by automated email processors or gateways MUST|SHOULD NOT
   modified or create a return path after final destination
   and mail delivery decisions are firmly established.

I think the key is making that final destination distinction.

Some examples flows:

Example 1:  NON-NULL

   SMTP RECEIVER - mail accepted, adds Return-Path: <!null>
   mailbotA - does something, set Return-Path: <>
   mailbotB - does something else, restricted from sending bounces

Example 2: NULL

   SMTP RECEIVER - bounce mail accepted, adds Return-Path: <>
   mailbotA - does something, set Return-Path: <!NULL>, adds to queue

In example 1, final destination is not necessarily established, especially if the host in example 1 is acting as relay or router. But if mailbotA (gateway, local host importer) establishes final destination, it might want to set Return-Path: to prevent any other subsequent bot from erroneously sending a bounce. Note: There exist applications which will "prune" the unnecessary headers, including the return-path in order to make it presentable or useful to users in multi-device reading environments, and this is only allowed because the final destination has already been established.

In example 2, having a NULL return path signifies "final destination" and therefore no mailbot SHOULD NOT modified it if the message has the potential to be put back into an outbound queue mail stream.

So I think SM's other statement about proper POST SMTP handling is important.


Hector Santos, CTO