...
Choose your upstream relay
First If you have installed things on Debian/Ubuntu before, you know that the apt-get install
process asks you some configuration questions. So before diving in, we need to decide how Postfix is going to deliver emails. Typical options are:
...
Rather than send email via someone, why not just email users directly? I.e. when Postfix is asked to email joe@example.com, it will looks up the example.com
MX record and fires off an email to it.have our mail server send to their mail server directly? You know, like email was designed to work - decentralized, peer-to-peer, not beholden on giant gatekeeping corporations?
Well, you can do that, and it is in fact my favourite option. Email is the last great decentralized protocol that still more or less works. The problem is spam, and more specifically the countermeasures that large email providers take to avoid spam. Your little mail server, sending legitimate Jira emails, may not be trusted when it connects directly to a recipient's mail server, and your Jira notifications may not be delivered. You can increase the deliverability odds by following best practices, but you may be unlucky, e.g. if you unknowningly share a IP netblock with a known spammerSending email directly is generally not recommended due to deliverability concerns: your emails might be marked as spam, particularly if your Jira server's IP address block does not have a good sender reputation.
Despite legitimate worries over deliverability, sending directly is my favourite option because:
- it avoids the arbitrary sending limits imposed by most email service providers.
- It generally works:
- This is anecdata, but I administer a few smaller instances, and one very high volume 2000-user Jira, sending about 17k emails per day to many academic domains. We very rarely (say, once a year) have problems in the form of bounced mails, or complaints from users.
- My theory is that the sheer volume of Jira email works in its favour. Spam filters track reputation: a torrent of similar emails, once marked as legitimate, will continue to be let through. Spam filters won't even bother to track reputation of a sporadic email sender. Your recipient could mark an email as legitimate and it won't matter: by the time you send another email, the spam filter has forgotten.
- when it works, it is zero cost
- ...except from the initial setup cost of learning and configuring TLS, SPF, DKIM, DMARC and Postfix. But that's fun! Read Small Mailserver Best Current Practices to see what
- when it doesn't work, it's not catastrophic. A few users might find Jira notifications in their spam folder, and will have to click 'Not spam' until the filter learns.
- Email As noted earlier, email is the last great decentralized part of the internet, and we (technical folks) should do our part to keep it open. Every independent SMTP server promotes diversity and helps to keep the bastards honest.
...
Run apt-get install postfix
to install Postfix. You will be prompted to enter values in a series of 'debconf' setup screens. The first screen confronts us with the relay-or-send-directly choice discussed above:
The options mean:
Option | Incoming Mail | Outgoing Mail |
---|---|---|
Internet Site | Accepts outside connections, delivering to local mailboxes | Sent directly |
Internet with smarthost | Accepts outside connections, delivering to local mailboxes | Relayed |
Satellite system | Accepts connections from localhost, delivering to local mailboxes | Relayed |
Local only | Accepts connections from localhost, delivered to local mailboxes | No sending or relaying |
Pick Satellite system if you wish to relay through a mail service provider, or Internet Site if you wish to send email directly. Then accept the defaults.
...
- 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 thesmtpd_tls
lines are not strictly necessary, unless you tick the 'TLS' box in Jira's Outgoing Mail config.
- We're only listening on
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=<joe.bloggs@example.com>, 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
...