Page tree

Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Fix the type of virtual_alias table

...

  • The first part, up to and including inet_protocols = all  is boilerplate 'Satellite system' content.
    • We're only listening on loopback , and our only SMTP client will be Jira/Confluence, so the smtpd_tls lines are not strictly necessary, unless you tick the 'TLS' box in Jira's Outgoing Mail config.
  • myhostname is the EHLO address the server identifies itself as to others, and as such:
    • must be a fully qualified domain name ('jiraconfserver.example.com')
    • ..with a PTR record for ipv4 and (assuming inet_protocols = all ) ipv6. Here is a handy function for testing:

      Code Block
      validate_spf()
      {
              a=${1}.   # Add trailing dot
              ip=$(dig +short A $a)
              ptr=$(dig +short -x $ip)
              [[ $a == $ptr ]] && echo "ipv4 correct" || echo "$1 ipv4 resolved to $ip, whose PTR is $ptr, not $a"
      
              ip6=$(dig +short AAAA $1)
              ptr=$(dig +short -x $ip6)
              [[ $a == $ptr ]] && echo "ipv6 correct" || echo "$1 ipv6 resolved to $ip, whose PTR is $ptr, not $a"
      }
      
      validate_spf jiraconfserver.example.com


    • The address (or IP) must be listed in your SPF record, e.g:

      Code Block
      dig TXT example.com | grep spf
      example.com. 284     IN      TXT     "v=spf1 include:_spf.google.com a:jiraconfserver.example.com ~all"


  •   smtp_tls_connection_reuse  tells Postfix to cache and reuse its outgoing TLS connection to SMTP servers. If you enable this, also ensure master.cf  has the line:

    Code Block
    tlsproxy  unix  -       -       y       -       0       tlsproxy

    The hope is that when sending dozens of emails to one provider (like smtp.gmail.com), we could make them all over just one TLS connection, and hopefully avoid "Too many login attempts" errors.
    With this flag you'll see /var/log/mail.log  lines like:

    Code Block
    Jul 22 21:45:19 example-jiraconf postfix/smtp[650976]: Trusted TLS connection reused to smtp.gmail.com[2404:6800:4003:c03::6d]:587: TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256)

    you'll see a new conn_use=  field indicating how much connection reuse you're getting:

    Code Block
    Jul 22 21:45:21 example-jiraconf postfix/smtp[650805]: 25839197990: to=<[email protected]>, relay=smtp.gmail.com[74.125.130.109]:587, conn_use=5, delay=27, delays=0/22/0.26/5.3, dsn=2.0.0, status=sent (250 2.0.0 OK  1595418321 c139sm23292217pfb.65 - gsmtp)

    The most reuse I've seen is conn_use=9 . I have also not verified whether TLS connection reuse actually affects GSuite's "Too many login attempts" at all.

  • message_size_limit  is, as the comment states, increases the size limit for giant Jira attachments from JETI.
  • I have not done DKIM signing, and probably should.
  • See below for more on re-routing mail with virtual_alias_maps

...

  1. Create a system account whose mailbox will accumulate catch-all emails:

    Code Block
    useradd --no-create-home --comment "Postfix may re-route to this user mailbox" usercatchall 

    (or skip this step and just use root  below)

  2. Add a virtual_alias_maps parameter to your /etc/postfix/main.cf :

    Code Block
    # Map *@monitoring.redradishtech.com to [email protected]
    virtual_alias_maps = hashregexp:/etc/postfix/virtual_alias

    and postfix reload 

  3. Create /etc/postfix/virtual_alias  containing:

    Code Block
    # Reroute all email, sending it to root's local mailbox
    #/.*@.*/        mailcatchall


  4. Then make virtual_alias.db   (assuming you installed the Makefile shown earlier)

...