== What addresses we accept and reject during mail submission

Like many places, [[our mail setup CurrentMailerConfiguration]]
includes a dedicated mail submission machine ([[or two
AuthenticatedSMTPOurWay]]). I mentioned [[yesterday IPMIEmailBug]]
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 _RCPT
TO_s 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
WhiteBoxMailers]]), so we do.

(We also do some basic safety checks for certain sorts of bad
characters and bad character sequences in _MAIL FROM_ and _RCPT TO_
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 ../spam/SegregatingOutgoingMailII]].)

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
../spam/CallbackCheckDont]]. 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.