Open xelxebar opened 1 year ago
@leahneukirchen @stacyharper Mind weighing in on this?
About the use case I had, I only had one Delivered-To. If the fix continue to pick it, rather than the useless To, it is okay to me. Choosing the first Delivered-To seems okay and predictable to me
I guess both could be argued for, e.g. if you have multiple alias expansions they'll all end up as a Delivered-To..
I agree that maddr should parse repeated headers.
I also found multiple mailing lists ending up as Delivered-To...
Jumping on this, I received a mail on an account I've put into my Alternate-Mailboxes
setting but when replying to it via mrep it reverts the From:
to default.
Is there a setting which lets me always use the To:
address if it's inside the Alternate-Mailboxes
setting? I couldn't find such a thing inside mcom
.
If not, I may open a PR.
Overview
Commit e1e5bfe5 introduces a potential regression against 282de650. In cases where there are multiple
Delivered-To
headers, it is most likely that we wantmrep
to populate the sender address from the most public-facingDelivered-To
, i.e. the first one; however, at the moment we are setting it to the address in the final (i.e. topmost and most internal-facing) one.Why?
We have a posix setup that aliases multiple addresses into a virtual mailbox---e.g. all mails going to
mars.*@example.com
get glommed intomars@example.com
. The problem is that postfix aliases end up adding an additionalDelivered-To
header for each of these alias redirections. This is necessary to detect alias loops and related problems.Patch points
The proposed change boils down to munging mcom:377. I believe we just need to reverse the order of headers passed to
maddr
and thentail -n 1
instead ofhead -n 1
. However, it appears thatmaddr
doesn't currently have a-M
switch likemhdr
, so maybe a patch there is needed as well?Comments
Thoughts? Does the above sound reasonable?