Greg A. Woods wrote in <m1rz2Wo-0036s2C@more.local>: |First off let me second what Steffen says!
SPF should never have been introduced as it breaks any mail forwarder; just spring last year i contacted postmaster@ of FreeBSD because i got bounces when i replied to some @freebsd.org that forwarded to @gmail. I mean, that is practically any university or project which offers permanent addresses to their (former) members as they live on. And it is so funny given how SMTP started hopping. Ditto DMARC that breaks any mailing-list. Well in fact the DKIM key breaks, of course, if a ML footer or subject tag is added. (If it would be me DMARC would be dropped and a minimally updated DKIM would take its part and signal the necessity of the presence of a DKIM signature through the existence of a "new" DNS entry. Ie, that *always* fails then.) (There is a possibility that is used for eg IETF lists: if you lookup the DMARC policy, and it announces that a modified email would cause failure, you can setup a permanent alias, here one of a well-known person who does 5322: From: Pete Re...ck <resnick=40his-host....@dmarc.ietf.org> ie real-address@dmarc. etc, so From: checks go for other DMARC entries etc. Well. |At Mon, 22 Apr 2024 21:15:08 +0200, Rhialto <rhia...@falu.nl> wrote: |Subject: Re: Mail delivery from Postfix to remote IMAP |> |> and neither can you change the |> envelope FROM address because bounces (as far as they happen) won't work. | |I haven't verified this works right with Postfix, but if you're doing |forwarding with ~/.forward files then this should happen automatically. | |It does of course mean bounces do end up going to the account on the |forwarding host, not the original sender, but this is (in theory) what |people using ~/.forward files want -- the forwarding itself caused the |bounce, not the initial delivery to the forwarded account, so sending |the message back to the original sender is arguably wrong. | |Maybe you can increase your storage capacity and simply run local IMAP |service for all your domains and users? Every modern IMAP client (MUA) |I've encountered has been able to easily handle multiple IMAP accounts, |and many of them have simple ways to aggregate all INBOXes, for example, |into one meta INBOX. If there really is not other way, the MUA i maintain speaks IMAP a bit; even though the new version is still not ready (and will change configuration), and v14.9.24 is very old (and has quite some bugs, and i have forgotten anything about it), it *could* be that scripting it to move all mails forward to another box on another server could be the solution. With v14.10 (that is still not what i long for) as of hopefully summer one could place your desire in a pipe even: </tmp/xbox s-nail -:/ -Squiet -Snoheader -Rf \ -Y 'copy * /tmp/ybox' \ - Where /tmp/ybox could be mbox:// or maildir:// or imaps:// etc (for which you then need credentials and such, of course). The [next] branch on which this works is stable (i am working on this branch for four years; but currently mostly not as i still develop a DKIM signer), but IMAP has not yet been updated to the new configuration syntax. Note that for OAuth i have developed an external (python3) script (usable by itself -- as long as one claims OAuth to be usable, especially for Microsoft where one seems to have a need to go via the browser once an hour; Google once a day, Yandex once a year; whatever) that is not yet included in the repo etc. Client certificates are supported. Ie, just in case. --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)