> On May 3, 2018, at 11:13 PM, Phil Ingram <p...@communityds.com.au> wrote:
>
> 1. Cron email from things we don't care about and while these are mostly set
> as &>/dev/null anyway, but we need to ensure that we have a catch all for the
> 'just in case' scenario where someone makes a furfy (i.e. >&/dev/null).
> 2. Cron email from things we do care about. (reports, logwatch, maintenance
> tasks, etc.)
> 3. Application emails; password resets, new account registration,
> notifications etc. that are sent to our customers
>
> Depending on which product the email is coming from we have a need to handle
> email differently between dev/stag/prod; i.e. permit production servers to
> send emails to our customers, but with staging/uat redirect everything to an
> internal dist list for developer review. We use Ammutable infrastructure
> (custom built AWS images that are partially configured post launch) and
> having to update each and every image then deploy it to make a small change
> is a larger overhead than we would like as it's easier for us to just
> 'relayhost' to a central postfix instance where we can more easily filter out
> and redirect the emails we care about.
This is not actionable information. You need to provide more detail, such
as e.g. someone would need to attempt to route each type of traffic to the
right place.
Also, though you might prefer to take care of everything on the mailhub,
if the trasition from the hosts to the mailhub loses critical differences
as to the type of mail being handled, then the correct solution is to
do appropriate rewriting at the sources, before delivery to the mailhub.
--
Viktor.
