I've been thinking about a BCP for SMTP-time address verification, which
has turned up some ideas which may be useful for the email architecture
document.
In particular (and to summarize the following) one of the distinct
functions of the MDA is to be the final authority for which local parts at
a given domain are valid. This implies that its function is more on behalf
of the domain and the message store as a whole rather than on behalf of an
individual user, as is the case for the MUA. I use this to further my
argument that aliasing is an MDA function not an MUA function.
The reasoning for the above comes from analysing the roles of an MTA with
respect to a domain in the context of address verification.
A common distinction for an MTA to make is between local domains and
remote domains. Messages to addresses at a local domain are usually
delivered locally, and messages to addresses at a remote domain are
relayed to another host via SMTP. The MTA will usually know which local
parts at a local domain are valid, and will usually be ignorant of which
local parts are valid at a remote domain. However, neither of these is
necessarily the case, as I shall show with some examples below. Therefore
some different terminology is needed to talk about address verification.
An MTA is "authoritative" for a domain if it knows which local parts are
valid at that domain. An MTA is "advertised" for a domain if there is an
MX record for that domain pointing to the MTA. In order to reduce the
amount of "collateral spam", we would like all MTAs that are advertised
for a domain to be authoritative for it, and we would like them to check
recipient addresses at SMTP time so that they do not accept misaddressed
messages and bounce them later to a possibly-forged return path.
Time for a couple of examples.
It's often the case that a secondary MX will accept all messages for the
domain for which it is advertised regardless of the local part, and relay
the messages to the primary MX when it's available. The MTA in this case
is advertised but not authoritative.
When an organization's primary MX is outside their firewall and their
main email server is inside, it is sometimes the case that the advertised
MTA is not authoritative, in a similar way to the previous case.
Obviously there are plenty of ways that authority for a domain can be
propagated outwards to the advertised MTAs to reduce the propagation of
badly-addressed email. (This involves making MTAs authoritative for remote
domains.) But what if we turn our point of view around and look what
happens when authority is minimised?
An extreme case is the example of the last hop MTA sending email to the
message store's MDA over LMTP. In this case it's possible for the MTA to
be ignorant of which local parts are valid, leaving that to the MDA. I.e.
the MDA is authoritative and the MTA is not, although the domain is local
to the MTA.
A more intricate example is a setup where the MTA and MDA functions are
integrated into the same software, In this case the last-hop MTA is
usually entirely authoritative. However say it supports local-part
suffixes such as local_part+suffix(_at_)domain under the control of the user's
filtering script. In this case the script is usually not run until
delivery time and invalid suffixes aren't discovered until then. In this
case the final MTA is only partially authoritative, and the MDA still has
the final say.
I have argued that the MDA is the final authority on which local parts are
valid at a domain, and that this implies it is acting on behalf of the
domain rather than the users. This implies a certain privilege, as do
other requirements of local delivery like enforcing quotas and acting on
behalf of different users at different times. There's a security boundary
between the MDA and the MUA, which can only act for one user.
There's another security boundary at the submission end of the process,
where the MSA has privilege required for performing authentication and for
ensuring proper message formatting; in particular it may ensure that the
Sender: header refers to the user submitting the message.
Note that the submission fix-ups do not occur when aliased addresses are
handled, which implies that this is performed within the privilege
boundaries, not in the MUA which is outside them. These fix-ups occur for
all the actions I listed starting with mailing lists (including
re-sending, forwarding, replying) and not for those that came before
(gatewaying, firewalling, aliasing, and relaying).
--
Tony Finch <dot(_at_)dotat(_dot_)at> http://dotat.at/