What addresses we accept and reject during mail submission
Like many places, our mail setup
includes a dedicated mail submission machine (or two). I mentioned yesterday
that this submission machine refuses some
MAIL FROM addresses,
so today I want to talk about what we accept and refuse during mail
submission and why.
When we were designing our mail submission configuration many years
ago, our starting point was that we didn't expect clients to deal
very well if the submission server gave them a failure response.
What you'd like is for the MUA to notice the error, report it, give
you a chance to re-edit the email addresses involved, and so on and
so forth. What we actually expected would happen would be some
combination of lost email, partially delivered email (if some
TOs failed but others succeeded), and awkward interfaces for dealing
with failed email sending. So a big guiding decision was that our
mail submission machine should accept the email if at all possible,
even if we knew that it would partially or completely fail delivery.
It was better to accept the email and send a bounce rather than
count on all of the MUAs that our users use to get it right.
(Some but not all
RCPT TO addresses failing during SMTP is a
somewhat challenging problem for any MUA to deal with. How do you
present this to the user, and what do you want to do when the user
corrects the addresses? For example, if the user corrects the
addresses and resends, should it be resent to all addresses or just
the corrected ones? There's all sorts of UI issues involved.)
Given that our recovery method for bad destination addresses is
sending a bounce, we need to have what at least looks like a valid
MAIL FROM to send the bounce back to; if we don't we can't send
bounces, so we're better off rejecting during SMTP and hoping that
the MUA will do something sensible. For email addresses in outside
domains, the practical best we can do is verify that the domain
exists. For email addresses in our own domain, we can check that
the local part is valid (using our list of valid local parts), so we do.
(We also do some basic safety checks for certain sorts of bad
characters and bad character sequences in
MAIL FROM and
addresses. These probably go beyond what the RFCs require and may
not be doing anything useful these days; we basically inherited
them from the stock Ubuntu configuration of close to a decade ago.)
We allow people to use
MAIL FROM addresses that are not in our
domain in part because some people in the department have a real
need to do this as part of their work. In general we log enough
source information that if anyone abuses this we can find them and
deal with this.
(You might say 'but what about spammers compromising accounts and sending spam through you with forged origin addresses?' My answer is that that's a feature.)
PS: In theory checking outside domain
MAIL FROM addresses is one
place where sender verification has a real justification, and you
can even legitimately use the null sender address for it. In practice there are all sorts of
failure modes that seem likely to cause heartburn and it's just not
worth it in my opinion.