Currently all mail services run on
tools-mail. A few pointers:
- Exim is hard. This documentation is not: http://bradthemad.org/tech/notes/exim_cheatsheet.php
- Most relevantly:
exim -q -vto manually run over the queue once
- Log files are in
A diamond collector(ExtendedExim) written for phab:T96898 publishes to: tools.tools-mail.exim.*
Testing outbound email on the Grid
jsub echo -e "Subject: Test message subject\n\nTest message" | /usr/sbin/exim -odf -i <email>
Blocking a sender from sending outbound mail
/etc/exim4/deny_senders.list and add the envelope from address that you want to block on a new line.
$ echo 'email@example.com' | sudo -i tee -a /etc/exim4/deny_senders.list firstname.lastname@example.org $ sudo -i cat /etc/exim4/deny_senders.list # Add MAIL FROM address to block. One per line email@example.com
Stopping all in/outbound mail
If an incident seems to be occurring, be safe and stop exim before you spend a lot of time digging into the root cause. Having our MX address put on a blacklist for spamming is worse than some downtime.
$ sudo -i puppet agent --disable "Investigating exim incident -- $USER" $ sudo -i puppet agent -tv # Check to see that Puppet is actually disabled $ sudo -i service exim4 stop $ ps axuww | grep exim # Did it really stop?
Now you can proceed to investigate the queue without more messages going in or out. SMTP is robust to network segmentation so even leaving things down for a few hours is not a huge problem. Messages will be delivered eventually.
Exim runs as a queue on each exec node
Each exec node (and most other hosts actually) run a local copy of exim that queues messages for outbound delivery via the
tools-mail smarthost. Even if you have purged the queue on the smarthost before restarting exim following an incident, there may be messages queued across the grid ready to flood in as soon as the service is back online.