On Mon, Aug 2, 2021 at 12:45 PM John Levine <johnl(_at_)taugh(_dot_)com> wrote:
It appears that George Michaelson <ggm(_at_)algebras(_dot_)org> said:
The utility of having envelope available in canonical form for eg
procmailrc or delivermail processing is high. I know I'd want this and
have argued with operators of my MTA about it in the past.
This version of the draft is better but it it still says nothing about
the existing use of Delivered-To.
Postfix, Courier and qmail have added Delivered-To for a very long
time, more than 20 years for qmail. They use it for loop detection. If
a message already has the same Delivered-To it's about to add, they
bounce the message. Exim adds a similar header but calls it
Emvelope-To:.
Prior use is a problem, I agree.
It turns out not to be useful for procmail. MTAs invariably have other
ways to tell procmail what the current delivery address is, via a command
line argument or environment variable, and it's up to the local
configuration whether to add the Delivered-To before the message is
passed to procmail.
I simply don't agree John. The lack of promotion of the envelope to
header means there is one, and one only point where you can "know" the
value which in your model is out of scope/standards, and doesn't work
all the time: Thats the basis of my argument with the MTA operator:
they don't tell me this in a single, consistent manner.
These "other ways" only work during initial delivery. They cannot be
re-applied because the ENV/CMDLINE information is lost. So, in an
MTA->MS model, the envelope data has been long shredded, if I run an
IMAP fetch to local processing. I can't process the data because it
was lost, when the MTA handed off.
"up to local configuration" is handwaving for "not my problem" and
"turns out not to be useful" is highly conjectural, its your opinion.
I disagree. It's useful.
-G
R's,
John
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp