ned+ietf-smtp(_at_)mrochek(_dot_)com wrote:
I suggest the following change to Section 4.5.5 (Messages with a null
reverse-path):
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.
--
Sincerely
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com