example configuration for an imaginary service that handles inbound mail routing

email_routing.yml

---

# The key ideas of integration tools is that the entire routing solution should be implemented
# between the input/output borders. This provides some nice properties: for any input, you can
# determine where it will go. For any output, you can trace back all the possible inputs.
# If you have a service that will only send to exactly one email address (eg. AWS) then you
# can set up fan-out rules. If you are deprecating a service (eg. Slack) then you can identify
# and redirect all emails that have Slack as a destination. Unlike a forwarding rule on an
# Exchange account, you end up with version history. And unlike an Exchange forwarding rule,
# you always know where the email is coming from, so you can shut it down at its source.
# By making routing rules independent and separate from individuals email accounts, the
# routing is preserved even as people join and leave the organization. If you want to deprecate
# an email address (eg. changing domains) then you have knowledge about all the sources that
# are producing messages, so you can visit their sites or contact support to change your address.
# The email routing tool should always map outputs to distribution lists, not individuals. It is
# the responsibility of your email admins to ensure that distribution lists are populated correctly,
# whether that process is manual or automated with some kind of ERP.
# This approach allows comments. And I always love comments.
# There is a temptation to build a service like this on Amazon, but SES inbound requires
# set up for each individual inbound address. And SES outbound requires the From: header
# to be validated, so you can't operate as a transparent mail relay. Perhaps this could
# be implemented with Lambda, or if not that, then maybe by wrapping Postfix on a
# traditional EC2 instance. Actually, I think SES outbound only validates the address
# used on the message envelope, not the internal `From:` header. that could work well!
# If you bring a new person onto your team, how sure are you that they are receiving all
# the emails they should be? If you have somebody leave, how sure are you that they are
# no longer receiving work-related emails at their personal email? When you set up things
# like WHOIS records and you provide an email address, where is that documented and how
# do you ensure that the email address continues to be valid and deliverable?

# TODO: Could Logstash, or at least the ideas behind Logstash, be used to implement this?

smtp-listener: yes

fetchmail:
  foocompany
    server: mail.foo.company.com
    username: bob
    
sendmail:
  smtp_server: smtp.my.company.com
  probe_smtp_addresses_valid: weekly # On a weekly basis, ask the SMTP servers if all of the known SMTP destinations are still valid.

classifications:
  AWS:
    from: aws@pulseenergy.com
    subject: ".*Amazon EC2 Maintenance.*"
  VendorOps:
    from:
      - alerts@vendorA.com
      - notify@vendorB.com
  VendorGeneral:
    to: vendors@pulseenergy.com
  VendorMarketing:
    from:
      - marketing@vendorC.com

routing:
  NoClassification:
    - EmailSRE
  AWS:
    - Battlefield
    - EmailSRE
  VendorOps:
    - VendorDistributionList
    - EmailSRE
  VendorMarketing:
    - VendorDistributionList
  VendorGeneral:
    - VendorDistributionList

outbound:
  Battlefield:
    slack:
      url: FOO
      key: FOO
      channel: FOO
  EmailSRE:
    email:
      recipients:
        - SRE_distribution_list@company.com