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.
pgp9OyyNaegDu.pgp
Description: PGP signature
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp