Wietse Venema via Postfix-users wrote in
 <[email protected]>:
 |Steffen Nurpmeso via Postfix-users:
 |> Thanks, thanks.  But really, i had only missed aka did not realize
 |> what
 |> 
 |>     enable_original_recipient = no
 |
 |I exists so that domain-in-a-mailbox can distinguish different
 |recipiemts by their X-Orginal-To: header.
 | Wietse
 |
 |> really does.  It is exactly the configuration toggle that i need.
 |> (For myself.  Given Jaroslaw Rafa's statement it would likely be
 |> "super-cool" if the behaviour could be configured on a target
 |> domain or recipient base, like with regex flags or what do i know.
 |> I have that simple domain layout, with different names but only
 |
 |As a de-optimization feature for a niche use case, X-Original-To:
 |related support pervades Postfix allready more than desirable.

I think there was only one entry in this header field; you mean it
is not merged to a list when deduplicating, but still generated
(likely a kind of "first seen wins"), and this makes you feel
uncomfortable, and you do not like it(?).

That far i have not thought, honestly speaking.  Now i myself
never had a use case for Original-To:, so i can speak only as the
lucky one who now enables the above toggle -- which is much easier
and less resource hungry than for example writing a milter that
does it, or even trying to find other administrativa to get rid of
the @lists.DOM vs @DOM message doubling (possibilities).
Original-To: seems not to be standardized, and .. likely not being
capable of storing a list of addresses; .. and simply adding
multiple instances, how about this??

To be absolutely honest, i for myself would rather let that header
be for good i think is the term.  One may need it to debug
complicated mail routing?  Then it could also be encrypted, and
a postX program could dump out info of those hops of
administrative interest.  (And then the content of that header
could well be a list etc.) I am all for RFC 9788 (Header
Protection for Cryptographically Protected Email) and would love
to keep true envelope data out of message instances as then
delivered to users.  Yes, in the logs.  Yes, in the "modern"
internet, where certain service providers handle mail (MX++) for
their customers, "do something" on them, and pass it further (to
"real MX").  Yes, even in the true postal times, except for
certain stamps and rubber stamps, you do not keep the envelope.
No, not me that is, no addresses in Received: i would hope for,
and nothing else surrounding that.  All this data collection,
everywhere, i would not feed it; to me email should not be special
in this, and for other protocols hiding of such info is on the
radar, or even was so, long ago.  I am a total opponent of things
like that one-click-unsubscribe wonder, and that new DKIM2 as they
want it, which even goes into the completely opposite direction,
and places envelope data in long term storage, as i (unchallenged)
see it.  It was spoken out at the very beginning that ~"with the
'market power' of [certain US giants] we can get this through".
Now that is all off-topic for postfix and Original-To.  But
Original-To is envelope data, right.

Thank you very much!

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)
_______________________________________________
Postfix-users mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to