On Feb 6, 2006, at 11:25 AM, Frank Ellermann wrote:
| If an SMTP server has accepted the task of relaying the mail
| and later finds that the destination is incorrect or that the
| mail cannot be delivered for some other reason, then it MUST
| construct an "undeliverable mail" notification message and
| send it to the originator of the undeliverable mail (as
| indicated by the reverse-path).
And yes, I think we must keep this MUST as is, and therefore we
can't keep 1123 5.3.6(a) as is, in a world with forged "reverse
paths" everywhere this causes havoc for innocent bystanders.
Replacing the return-path in every case when modifying recipients is
rather complex. In the event of auto-responses with a return-path,
messages sent to this new return-path will require that the recipient
be modified to that of the original return-path, and the current
return-path be changed as well. It would seem not having the ability
to copy the return-path when changing RCPT TO parameters makes for a
high level of complexity.
This unfortunate MTA now needs to track modified return-paths going
both directions. The number of these addresses tracked would not
scale like that of a one-person list-server. There are not
subscriptions constraining the range of addresses being handled.
This auto-response scenario often represents a fair amount of
traffic. Of course, this assumes that the return-path can be
qualified before being processed. Assume a EHLO verification is
within the domain of the return-path. When it is not, a forward
lookup of a PTR record could return a list of acceptable EHLOs for
this return-path. This verifies both the EHLO, and, by adding one
more lookup in the odd case, the return-path is validated as well.
This return-path replacement could be accomplished using a compressed/
encrypted return-path, a nested/signed return-path embedded within
the new local-part, or a local-part as a randomized index into a
table of original return-paths. A table index approach allows
determinant sized local-parts. The nested/signed return-path
requires syntactical conventions be adopted for this to be
beneficial. While table entries could be purged after a period of
inactivity, the size of this table could grow to be extremely large
and would need to be a shared resource within the domain making this
a security problem at least. The compressed/encrypted or nested/
signed schemes could overflow the local-part capacity, although this
problem is not likely. The compressed/encrypted approach would
likely be the fastest technique.
-Doug
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg