Wietse Venema via Postfix-users wrote in
<[email protected]>:
...
|That is insufficient data to reproduce the observation.
As an idiot, i tried this again, locally.
mydestination = kent, $myhostname, lists.kent, $myhostname.$mydomain
localhost.$mydomain, localhost
virtual_alias_maps = lmdb:$meta_directory/virtual,
regexp:$meta_directory/virtual_re
In "aliases"
vietse: steffen
In "virtual_re"
/^(knodel(.*))@kent/ ${1}@lists.kent
/^knodel@lists\.kent$/ vietse
Then
/usr/sbin/sendmail -bv [email protected] knodel@kent
gives
May 16 17:15:17 kent postfix/pickup[24980]: 80E95219BDF: uid=1000
from=<steffen>
May 16 17:15:17 kent postfix/cleanup[24990]: 80E95219BDF:
message-id=<[email protected]>
May 16 17:15:17 kent postfix/qmgr[24981]: 80E95219BDF:
from=<[email protected]>, size=304, nrcpt=2 (queue active)
^ nrcpt=2
May 16 17:15:17 kent postfix/local[24992]: 80E95219BDF:
to=<[email protected]>, orig_to=<[email protected]>, relay=local,
delay=0.07, delays=0.06/0/0/0, dsn=2.0.0, status=deliverable (delivers to
mailbox)
May 16 17:15:17 kent postfix/local[24993]: 80E95219BDF:
to=<[email protected]>, orig_to=<knodel@kent>, relay=local, delay=0.07,
delays=0.06/0.01/0/0, dsn=2.0.0, status=deliverable (delivers to mailbox)
...
We get a fully recursive address expansion, but no deduplication
of the expanded addressees. That is open-ended: i can install
infinite aliases, they all get their own message instance, eg
Return-Path: <[email protected]>
X-Original-To: knodel@aua
Delivered-To: [email protected]
Received: by kent.sdaoden.eu (Postfix, from userid 1000)
id A444D219C05; Sat, 16 May 2026 17:24:16 +0200 (CEST)
Date: Sat, 16 May 2026 17:24:16 +0200
To: knodel@aua
I read in postconf(5)
Recipient deduplication
With "enable_original_recipient = yes", the cleanup(8) daemon
performs duplicate recipient elimination based on the content of
(original recipient, maybe-rewritten recipient) pairs. Other‐
wise, the cleanup(8) daemon performs duplicate recipient elimina‐
tion based only on the maybe-rewritten recipient address.
Please let me remark that neither
README_FILES/ADDRESS_REWRITING_README
nor
README_FILES/VIRTUAL_README
mention this important toggle. You only ever find it in
ADDRESS_VERIFICATION_README, under "Postfix 3.2 and earlier
workaround". I think it would be an improvement to normal people
if this toggle would be mentioned, it would be easier.
Btw i personally am a fan of "address-less traces", and i think
the Delivered-To:, but especially so as above that is ("who is
Vietse?"), reveals data noone but the very expanding host is
interested in. Not that it counteracts
7.2. Hiding Addresses from Trace".
There is no inherent relationship between either "reverse" (from the
MAIL command) or "forward" (RCPT) addresses in the SMTP transaction
("envelope") and the addresses in the header section. Receiving
systems SHOULD NOT attempt to deduce such relationships and use them
to alter the header section of the message for delivery. The popular
"Apparently-to" header field is a violation of this principle as well
as a common source of unintended information disclosure and SHOULD
NOT be used.
but i think traces should be completely anonymous except for the
unavoidable, and desired, IP addresses. At least optionally.
Yes, i wrote a "delivered-enc" draft. But/And i note that once
the DENIC messed the german DNSSEC for a short time, i immediately
(soon) got problems because my local dnsmasq got failures, whereas
all my upstream DNS servers (Google as well as my internet hoster)
simply hammered through the bogus data. I think dnssec is, or
could be, an important part of freedom for the people, and i think
the email protocol would be a nice companion, and, despite what
the IETF made out of it -- and soiling it further for whatever
reason --, an easy configurable and usable one.
Thank you.
--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]
