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

ls flag

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, 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.

in flag

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: and several other MTA's.

ls flag
Ugh, gonna have to compile it myself. :sadpanda: You're right that that looks like the correct thing to do, though, I'll try it out.
ls flag
No, standard SRS does not appear to help. smtp2go (which is who I'm using to route outbound mail since gmail doesn't like my IP anymore) will only send stuff if it likes the *header* From address, which SRS doesn't appear to rewrite, and with SRS on *not* routed through smtp2go, gmail continues to just reject them.
ls flag
However!, SRS rewriting the envelope *and* header From addresses seems to work fine, and gmail accepts it without forwarding it through smtp2go; possibly confusing for the end user, but replies *do* work so meh.
ls flag

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 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.


Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.