I don't want to burst bubbles, but postfix with few lines of config can redirect all email to DEVs.<p>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.<p>apt-get install postfix, postfix-pcre bsd-mailx, config and done.<p>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)...<p><pre><code> /etc/postfix/header_checks (adds a header with original TO)
/^(.*)@((?:(?![^\.]+.corp-domain1.com|anotherdomain.ca|localhost).)*)$/ PREPEND DEV-ENV-REDIRECT: ${1}@${2}
</code></pre>
This MUST be the same as the above regex, so that the TO preservation + redirect are both done in tandem..<p><pre><code> /etc/postfix/recipient_canonical_map
/^(.*)@((?:(?![^\.]+.corp-domain1.com|anotherdomain.ca|localhost).)*)$/ externalredirect@localhost
</code></pre>
Then in main.cf<p><pre><code> # 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
</code></pre>
Then in /etc/aliases:<p><pre><code> #
externalredirect: dev
# dev's email.. (default unless set)
dev: /dev/null
</code></pre>
Preserving the original TO as another header ensures you can debug if required, whilst preserving 100% the original mail body.<p>Using a second redirect in aliases, allows you do something such as:<p>/etc/aliases:<p><pre><code> #
externalredirect: dev, another_email_address_for_logs
# dev's email.. (default unless set)
dev: /dev/null
</code></pre>
So it's super easy for a dev to just change:<p><pre><code> dev: /dev/null
</code></pre>
to<p><pre><code> dev: dev@corp.com
</code></pre>
Without the need to worry about overall redirect stuff.<p>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.<p>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".<p>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.<p>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.<p>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.<p>That way monitoring / emerg emails get through unvarnished.