Re: Mail delivery from Postfix to remote IMAP

[Steffen Nurpmeso <steffen%sdaoden.eu@localhost>]

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.net%dmarc.ietf.org@localhost>

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 <rhialto%falu.nl@localhost> 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)