[b112]

I don't want to burst bubbles, but postfix with few lines of config can redirect all email to DEVs.

You really want, whenever possible, to test everything using real tools. Doubly so, using tools you'll use it PROD. However, at least postfix is de-facto standard.

apt-get install postfix, postfix-pcre bsd-mailx, config and done.

Here's an example redirecting ALL outgoing emails, UNLESS they are to your OK domains. Redirects are sent to an alias in /etc/aliases, which you can point to anything. (Easier for DEVs to modify when required)...

  /etc/postfix/header_checks (adds a header with original TO) 

  /^(.*)@((?:(?![^\.]+.corp-domain1.com|anotherdomain.ca|localhost).)*)$/ PREPEND DEV-ENV-REDIRECT: ${1}@${2}

This MUST be the same as the above regex, so that the TO preservation + redirect are both done in tandem..

  /etc/postfix/recipient_canonical_map
  /^(.*)@((?:(?![^\.]+.corp-domain1.com|anotherdomain.ca|localhost).)*)$/ externalredirect@localhost

Then in main.cf

  # added
  recipient_canonical_classes = envelope_recipient
  recipient_canonical_maps = pcre:/etc/postfix/recipient_canonical_map
  local_header_rewrite_clients = permit_mynetworks
  #
  header_checks = pcre:/etc/postfix/header_checks

Then in /etc/aliases:

  #
  externalredirect: dev

  # dev's email.. (default unless set)
  dev: /dev/null

Preserving the original TO as another header ensures you can debug if required, whilst preserving 100% the original mail body.

Using a second redirect in aliases, allows you do something such as:

/etc/aliases:

  #
  externalredirect: dev, another_email_address_for_logs

  # dev's email.. (default unless set)
  dev: /dev/null

So it's super easy for a dev to just change:

  dev: /dev/null

to

  dev: [e-mail]

Without the need to worry about overall redirect stuff.

NOTE that if you don't have a unique email for your company's DEVs to use, this won't work, HOWEVER... you can redirect with more refined controls above.

That is, instead of saying "if it's not to a company domain, then redirect this DEV TEST email!", you can "If not to this specific email address, then redirect to this specific email address".

The reason I have this setup to redirect of not corp domain, is that the env I have this deployed in is byte per byte 100% identical to PROD deployment, with only very, very, very, minor tweaks. About 20 bytes or so.

That way, all tests done in DEV are 100% identical to configs in PROD. You eliminate PROD deploy bugs more aptly this way. And so if local MTAs are postfix in PROD, then you can keep all of your PROD postfix configs, with these minor changes to lock down DEV. And, you can keep the all the config files, all the config, and just have empty header_checks, recipient_canonical_map files.

But this means that alert emails that might get send from PROD have genericized domains, so in such envs it's easier to NOT redirect corp dest emails carte blanche, and then send everything else to a redirect dest.

That way monitoring / emerg emails get through unvarnished.

[aeaa3]

Most people these days are using a service provider for SMTP in production, so it isn't really possible to keep your prod and test configs in sync.

I do agree about using testing everything real tools, which is why this (fakemail) uses OpenSMTPD as the mail server.

All the work is in configuring it (similar complexity to your postfix configuration by the looks of it), interfacing to it, and deploying it (currently using ansible but will probably dockerize it).

The fact that no emails can get through to a real recipient is a feature.

[Tepix]

Thanks. I think this is the way to do it because it will be a more realistic test.

[n2d4]

It's always fascinating to me when people say "not to burst your bubble but it's really simple to use this other tool which can already do the task", and then write an essay about all the workarounds they had to apply to make the other tool work

[b112]

The thing is, it's not "another tool", but instead "a tool deployed in at least hundreds of millions of *nix servers, which is rigidly compliant with SMTP RFCs, etc, etc".

If you want to debug issues with sending mail from code, then ensuring you have something that will scream if you "do it wrong" is a big bonus. And having something tested for 20+ years with rigid adherence to RFCs, deployed more widely than any other *nix MTA, is probably a good thing too.

In terms of "essay", I know it looks big on your phone screen (I presume), but a few paragraphs of background info is hardly that.

[Tepix]

Adding 8 lines to configuration files is too complicated?

[sunaookami]

Reminds me of https://news.ycombinator.com/item?id=9224

[hk1337]

And it only covers one scenario.