Re: [ietf-smtp] homework, not an experiment, draft-crocker-email-deliver

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 <dhc(_at_)dcrocker(_dot_)net> 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: something(_at_)domain(_dot_)com

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.

pgp7d57d_eHza.pgp
Description: PGP signature

_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp