Re: draft-crocker-email-deliveredto

On Mon, Aug 2, 2021 at 12:45 PM John Levine <[email protected]> wrote:
>
> It appears that George Michaelson  <[email protected]> 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