Re: [Asrg] Re: More e-mail oddities; SPF thoughts

[Douglas Otis <dotis at mail-abuse.org>]

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.org
https://www1.ietf.org/mailman/listinfo/asrg