Re: homework, not an experiment, draft-crocker-email-deliveredto

Sam Varshavchik <[email protected]> Fri, 06 Aug 2021 08:38:25 -0400
Newsgroups	gmane.ietf.smtp
Message-ID	<[email protected]>
Alessandro Vesely writes:

> On Wed 04/Aug/2021 16:11:38 +0200 Viktor Dukhovni wrote:
>>> On 4 Aug 2021, at 8:38 am, Dave Crocker <[email protected]> wrote:
>>>
>>> I don't see anything in either that prohibits what you've described.
>>
>> The main thing that's implicit is that MUAs can't generally expect
>> to find a usable recipient address in the recorded "Delivered-To"
>> mailbox.  This may be true for some operators for some period of
>> time, but is not a requirement of the field semantics.
>
>
> A MUA can use Delivered-To: to compare the address therein with the  
> configured user addresses so that replies can have a From: field that  
> matches the original recipient.  Some agents are even able to unwind various  
> Received:/Delivered-To: pairs.  Obviously, internal codes or HMAC break such  
> usage.  Fields reordering breaks it too.
>
> Would it make sense to define, alternatively:
>
>
>     "Delivered-To:" FWS Mailbox [CFWS] CRLF
>                     ; Mailbox is from [SMTP]
>
> where a comment may contain an opaque crypto token whereby an MTA can  
> recognize itself and break mail loops only in that case?

An MTA that wants to use its own tailored mail loop logic is always free to  
insert some X header that it understands.

I think what we want to do here is just document how this header's been used  
for 20+ years, to avoid someone coming along and doing something different  
with it. Even in that case the chances of that creating a problem for  
others, I think, are very small.

Speaking very loosely and imprecisely:

Delivered-to: [email protected]

An MTA that controls domain.com is entitled to add this header, and it's up  
to the MTA to decide what "something" is. It may correspond to the actual  
recipient, or it may not. This is the MTA's record of delivery, and it only  
means something to that MTA.

It MAY be inferred to indicate the recipient's actual e-mail address, but it  
only MAY do that.

The entire mail loop subject matter is just a derivative of this. Since the  
MTA own this header, it is certainly reasonable for the MTA to assume that  
noone else could put it there, so if it sees that the message already has  
it, it can reasonably conclude that the mail looped.

_______________________________________________
ietf-smtp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ietf-smtp
signature.asc (application/pgp-signature, 833 B)