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 mail.winserver.com (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,
https://secure.santronics.com
https://twitter.com/hectorsantos
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp