Mail submission by users versus by your machines

January 5, 2017

Generally the simplest way to handle making sure that system email works is to set your machines up with a 'null client' mailer configuration that dumps all of their outgoing mail on a single designated smarthost machine. When you are setting this up, it is natural to use the same machine and mailer configuration that you have for users, with the exception that you don't require your machines to do SMTP authentication before they send email.

That 'with the exception' I threw in there is the sign of the important way that mail submission by users is significantly different than mail submission by your fleet of machines. To put it simply, you want to accept all mail from your fleet of machines while rejecting at least a certain amount of email from your users, because they are different sorts of senders.

If one of your machines tries to send out an email message, you almost certainly want to see it. It doesn't matter what envelope sender address it has (or even if that envelope sender is kind of broken) and it mostly doesn't matter what the destination is, including whether or not it exists in your mail system; it should all get accepted and then generally all wind up in your mailbox or perhaps your monitoring system.

By contrast, if one of your users tries to send email with many sorts of broken configurations (such as an invalid or wrong sender address), you want it to not get accepted. Indeed, certain sorts of user problems can only be handled by rejecting the message at SMTP time. And often you'll want to partially or completely force the use of SMTP authentication, so that you know it actually is one of your users that's sending email and not some random person on the Internet.

If you have some system that insures logins and passwords are reasonably in sync on all of your machines, you can often get away with treating a normal mail submission machine as a machine mail submission machine. Most of the time machines will send email from addresses (such as root) that do exist in your global environment, and will be sending to system addresses that you can intercept. When they aren't and you know about it, you can deploy hacks like manually adding valid addresses to your global system (so that eg postgres is a valid address that goes to you). But it takes some attention and the result is not perfect.

It's possible to do better, but you need more complicated mailer configurations on one or both of your fleet of client machines and your central mail collection point. What I currently think of as an ideal setup would likely require special configuration on both sides.

(We use the 'single mail submission machine' version of this approach currently, partly because almost all of the machines that send out email are part of our password distribution system. Also, when a single server mixes user-generated email and machine-generated email, you generally have to treat it as all user-generated email.)

Written on 05 January 2017.
« Make sure that (system) email works on every machine
Web adblockers and the potential for recreating the Usenet killfile problem »

Page tools: View Source, Add Comment.
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Thu Jan 5 00:25:17 2017
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.