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

[Hector Santos <[e-mail]>]

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.
>>
>> What problem does it solve?
>
> 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: [e-mail]

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 [e-mail]; 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: [e-mail]

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.

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