There are a few different types of mail we deal with: 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. Phil Ingram Infrastructure & Security Manager Community Data Solutions <http://www.communityds.com.au> 214 Greenhill Rd Eastwood, SA 5063 1800 503 981 On 4 May 2018 at 12:06, Viktor Dukhovni <postfix-us...@dukhovni.org> wrote: > > > > On May 3, 2018, at 8:37 PM, Phil Ingram <p...@communityds.com.au> wrote: > > > > We are using postfix as a central email relay that forwards to an > external provider for trusted sending to our customers. Centralising this > relay is a must to limit the distribution of sasl creds required for > sending to our external provider. We have several products, each with dev, > staging and production environments and each with their own defined Class A > address ranges (10.0.0.0/16). Every server has an FQDN which makes email > sent to accounts such as 'root' from CRON easy to filter - "To: root@ > $host.app-environment.local". > > There's your mistake, you're trying to route mail based or header regular > expressions. Don't do that. Route mail based on the envelope recipient > address, your address rewriting tables (aliases, virtual aliases, etc.) and > transport settings. If needed, consider a separate null-client instance > for cron-generated mail. > > But first explain in more detail where the mail that needs to go to the > provider originates from, and how it is different from the mail that > should not go to the provider. > > -- > Viktor. > >
