[Top] [All Lists]

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

2021-03-02 08:02:47
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: ietf-smtp(_at_)ietfa(_dot_)amsl(_dot_)com

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 (Wildcat! SMTP Router v8.0.454.10)
          for hsantos(_at_)isdg(_dot_)net; 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: hsantos(_at_)isdg(_dot_)net

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,

ietf-smtp mailing list