Show HN: A fake SMTP server for software integration testing

I have a rule that any time someone ships a server, they're required to also ship a version that supports client testing purposes.

Of course nobody has ever observed my rule.

Doesn't make it a bad rule...

I use papercut too.

Maybe one request is one Too Many at this point. ;)

Call it a very dynamic rate limit that autoscales all the way down to zero.

Don't they all "allow receiving emails from your prod env"? They all speak SMTP. What am I missing?

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: dev@corp.com

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.