[Top] [All Lists]

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

2021-03-02 17:09:08
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.

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

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.

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.

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 <mrsam(_at_)courier-mta(_dot_)com> is just an internal mail alias for <captainawesome(_at_)courier-mta(_dot_)com>. Every mail I receive might have

Delivered-To: captainawesome(_at_)courier-mta(_dot_)com
Delivered-To: mrsam(_at_)courier-mta(_dot_)com

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: mrsam(_at_)courier-mta(_dot_)com
To: mistresssam(_at_)courier-mta(_dot_)com

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.

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?

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.

Attachment: pgp9OyyNaegDu.pgp
Description: PGP signature

ietf-smtp mailing list