Subject: Re: [ietf-smtp] spinning our wheels, was Fwd: New Version Notification for draft-crocker-email-deliveredto-02.txt

From: Hector Santos <[email-masked]>
Date: Mon, 01 Mar 2021 19:28:56 -0500

For the record, after 25 years, Wildcat! SMTP (or did Wildcat! UUCP) 
have never needed, nor considered, nor knew existed nor did we looked 
the "Delivered-To" header.

What problem does it solve?

-- 
Hector Santos,
https://secure.santronics.com
https://twitter.com/hectorsantos

On 2/21/2021 3:28 PM, John Levine wrote:
> The original motivation for this draft was to document the way that existing MTAs
> such as Postfix, Courier, and qmail have added Delivered-To headers for over 20 years.
>
> This draft does not do that.  What it describes is nothing like the behavior of those
> MTAs, so I don't understand what it is supposed to do.
>
> I have two suggestions of how to proceed. My preferred one is to
> abandon this draft, then we all go down the hall to emailcore and help
> with the updates of 5321 and 5322. That should be able to clarify what
> trace headers are and fix the ABNF in 5322 to deal with more trace
> headers than Received. After we've done that, people who are familar
> with the relevant MTAs (Sam and me, I think) can do a very short draft
> describing existing Delivered-To practice as a trace header.
>
> Alternatively, if we want to progress the current draft, change the header name to something
> like Recipient-Address so people don't confuse it with Delivered-To.
>
> R's,
> John
>
> _______________________________________________
> ietf-smtp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-smtp
>
>

---

From: Sam Varshavchik <[email-masked]>
Date: Tue, 02 Mar 2021 00:47:49 -0500

Hector Santos writes:

> For the record, after 25 years, Wildcat! SMTP (or did Wildcat! UUCP) have  
> never needed, nor considered, nor knew existed nor did we looked the  
> "Delivered-To" header.
>

One problem in definitely solved was detecting mail loop as soon as it's  
practically possible, without having to wait until a message ping-ponged a  
bunch of times between servers. You still need to count Received: headers,  
but most mail loops get broken right away.

Beyond that, it offered mail handling software a means to avoid the need for  
explicit configuration of their mailbox address. They'll just pick it up  
from the Delivered-To: header, and run with it. This is much easier than  
picking apart the bits of the topmost Received: header, looking for the  
"for", and hoping to find one.

---

From: Hector Santos <[email-masked]>
Date: Tue, 02 Mar 2021 09:02:21 -0500

On 3/2/2021 12:47 AM, Sam Varshavchik wrote:
> Hector Santos writes:
>
>> For the record, after 25 years, Wildcat! SMTP (or did Wildcat! 
>> UUCP) have never needed, nor considered, nor knew existed nor did 
>> we looked the "Delivered-To" header.
>>
> One problem in definitely solved was detecting mail loop as soon as 
> it's practically possible, without having to wait until a message 
> ping-ponged a bunch of times between servers. You still need to 
> count Received: headers, but most mail loops get broken right away.
>
> Beyond that, it offered mail handling software a means to avoid the 
> need for explicit configuration of their mailbox address. They'll 
> just pick it up from the Delivered-To: header, and run with it. This 
> is much easier than picking apart the bits of the topmost Received: 
> header, looking for the "for", and hoping to find one.
>

Appreciate the feedback.  Dupe checking, an important mail design long 
resolved, has always remained an internal proprietary design because 
Wildcat! supports more than one mail format, storage and network.

Trying to make sense of the "Delivered-To" header from what I see in 
the source for messages on the list, i.e. your response source contained:

   Delivered-To: [email-masked]

To you and I, that is obviously the list agent address.  For others, 
they may have to look at other headers to determine it is a list agent 
and not the ultimate end-user receiver.   So its could become a matter 
of trace interpretation.  For a 1::MANY (Groupware) mail network,  
what should each reception have in their headers?   Of course, the 
final Received line has been used. For my copy, I have:

   Received: by mail.winserver.com (Wildcat! SMTP Router v8.0.454.10)
           for [email-masked]; Tue, 02 Mar 2021 00:48:03 -0500

Since it was added by the local software, its would also understand 
the format and if required, sysop tools could easily extract the "for 
address" part. It would only look for the local host name and also the 
product tag and normally, the first one (last one prepended).  I am 
not sure of other product backend methods, but mail is stored with 
primary and secondary lookup keys, one key of course, with be the 
recipient primarily required for direct mail pointer chains -- "You 
got new mail!!"

If WcSMTP was supportive of Delivered-To,  I have some questions:

Should it strip/replace any current Delivered-To: header with

    Delivered-to: [email-masked]

Can there be more than one with the idea the order is top down?

Correct me if I am wrong, If I follow it logically, there should only be:

- One "Delivered-To" header for a 1::1 direct/private netmail, email, or
- Two "Delivered-To" headers (MAX) for a 1::manly list, groupware message.

Where would "Delivered-To" fit with DKIM header hash binding with the 
signature?  Should the Resigner (Mailing List Manager/Server) have a 
MUST or SHOULD or MAY hash bind to the signature?

Finally, one last comment, more food for thought for the IETF cogs to 
consider. Why would this proposal that is 100% and absolutely 
optionally and not necessary be proposed as "Standard Track?" Afaik, 
its not even a BCP.   I always advocated for a new IETF I-D status 
that is better fitting for this and many other ideas called "Internet 
Method" (maybe similar as Informational) because it is just be one 
additional Internet method copy from a product standpoint.  It wasn't 
a past IETF proposal or was it? My query was null.  A lot of the 
proposals would be better classified as "Internet Method" (or even 
Informational) but I digress.

---

From: Sam Varshavchik <[email-masked]>
Date: Tue, 02 Mar 2021 18:08:47 -0500

Hector Santos writes:

> and normally, the first one (last one prepended).  I am not sure of other  
> product backend methods, but mail is stored with primary and secondary  
> lookup keys, one key of course, with be the recipient primarily required for  
> direct mail pointer chains -- "You got new mail!!"

The Delivered-To: header is not meant to be an authoritative source that  
specifies which mailbox the message "is" delivered to, but rather "was"  
delivered to. This is a nuanced distinction, with some unspecified  
interpretation of what "was" means for the mail server that adds this  
header. The details of mail storage are not in scope here. What "delivered  
to" means and what goes into it is entirely up to the recipient's mail  
server discretion. It's the entity that assigns a specific meaning to its  
own Delivered-To: header.

>    Delivered-to: [email-masked]

No. Otherwise this would defeat its primary benefit: mail loop detection.

Do you strip off existing Received: headers before adding your own? Do you  
strip off any existing header before adding your own? Why would Delivered- 
To: be stripped off?

> Can there be more than one with the idea the order is top down?

Of course. Just like there can be more than one Received: header.

> - Two "Delivered-To" headers (MAX) for a 1::manly list, groupware message.

Neither. The existence and the contents of a Delivered-To: header have no  
explicit relationship to the number of recipients.

So it's possible that <[email-masked]> is just an internal mail alias  
for <[email-masked]>. Every mail I receive might have

Delivered-To: [email-masked]
Delivered-To: [email-masked]

prepended to it, in addition to any new Received: headers sprinkled around  
or below them. This has no relevance on any other Delivered-To: headers  
later, such as the Delivered-To: header of the mailing list server that  
remailed this message. Its Delivered-To: header would remain intact.

Or, if there was no alias and the same message was sent

To: [email-masked]
To: [email-masked]

Even though it's one copy of a message sent by SMTP to the same domain, and  
delivered to two mailboxes, it's possible that both of us will see both  
Delivered-To:, for us both, in our own copies of the original message. Or  
each one of us might see our relevant Delivered-To: header. It's up to my  
mail server.

It's entirely up to the mail server implementation to define how it creates  
its Delivered-To: header and what it puts there (hopefully it resembles the  
actual SMTP recipient). And whether or not the message was sent to any other  
recipient (same or different domain) is immaterial.

> signature?  Should the Resigner (Mailing List Manager/Server) have a MUST or  
> SHOULD or MAY hash bind to the signature?

I don't expect any existing Delivered-To: headers to be modified once  
they're there. But any MTA that ends up getting this message in the future  
has every right to add its own Delivered-To: (if it feels like it). So,  
without being very familiar with DKIM's details: it seems to me that it's  
rather difficult to add a cryptographic signature that includes an  
additional header yet to be added to the message.