How to provide /etc/aliases / .forward functionality in the current anti-spam environment?

The actual problem I'm having:

My email server (exim, but it hardly matters for this), which I've been running for years, forwards email via /etc/aliases (i.e. [email protected] points to ~5 people) and individual user's .forward files (i.e. my .forward has "[email protected]"). This has been problematic off and on for years, with various services refusing to accept mail for various periods, but recently gmail has gotten very serious about just refusing these mails.

I have DKIM, SPF and DMARC setup, but DMARC doesn't apply for these forwarded emails. The only thing I'm doing against best practices is that my IP's reverse DNS points to 50-250-232-19-static.hfc.comcastbusiness.net., which is certainly not great. I'm skeptical that just fixing that would solve this, though.

I've started passing the mail from the actual domains I control though a service (smtp2go, but again I don't think it matters), but they will only accept mail that is actually from my domains.

I think at this point, forwarding in the traditional MTA sense just isn't really workable in the modern anti-spam landscape.

I could try moving all my mail handling to an external service (a friend uses purelyemail, for example), but the disruption to my users, some of whom use local maildir with like alpine and mutt, would be substantial, and I think I'd just be kicking the can down the road: maybe MTA-style forwarding via such a service would work for now, but some day it'd fail, I bet.

What I'm trying to figure out is what is the minimum I can do to get mail flowing without having to make huge changes to my entire setup.

These are the options I can think of:

1. Use a mail syncing tool (there seem to be several of them; OfflineIMAP, isync, imapsync, others; if anyone has one they prefer that would be extremely helpful) to just shove the mails from a local maildir directly into the user's IMAP account. This is what I plan to do instead of my own .forward file, but that's not going to work for random board members, especially since as far as I know IMAP creds are all-or-nothing.

2. Have the MTA forward the mail but rewrite the sender to an address in my domain, so that DMARC works and so on. In other words, forward like an MUA instead of an MTA, but at the MTA level. Weirdly, I'm not seeing much info online on how to do this; I'm sure I could roll my own with procmail and formail, but I kind of expected this to be well solved. There's some definite detail work there, like making the Reply-To correct and so on. I know that mailman will do the correct kind of rewriting here, as I've configured it to do that for a mailing list, but that's about all I've found.

I would love to here about other possible solutions. Failing that, I'm looking for specific advice on how to do either #1 or #2, as I expect to do a mixture of both.

The "solution" to deal with how traditional e-mail forwarding breaks SPF is SRS ; the Sender Rewriting Scheme.

SRS can be used to modify sender addresses when forwarding so that SPF verification does not object to them. It operates by encoding the original envelope sender in a new sender local part and using a domain run by the forwarding site as the new domain for the sender. Any DSN message should be returned to this new sender at the forwarding site, which can extract the original sender from the coded local part and forward the DSN to the originator.

This is a way of avoiding the breakage that SPF does to forwarding.

It is supported by exim: https://www.exim.org/exim-html-current/doc/html/spec_html/ch-dkim_spf_srs_and_dmarc.html and several other MTA's.

Comments break formatting, so here's how to rewrite the From header (as well as the envelope From) with SRS using Exim.

The docs at https://www.exim.org/exim-html-current/doc/html/spec_html/ch-dkim_spf_srs_and_dmarc.html have this:

  return_path =         ${srs_encode {SRS_SECRET} {$return_path} {$original_domain}}

Add this as the next line:

  headers_rewrite = *@* "$return_path" f

For better recipient experience what I actually ended up doing was:

  headers_add = X-Forwarded-For: $reply_address
  headers_add = Reply-To: $reply_address
  return_path =         ${srs_encode {SRS_SECRET} {$return_path} {$original_domain}}
  headers_rewrite = *@* "$return_path" f

That way, reply actually works without having to route back through my server, although if it does route back through my server it does work.