Discovering policy

Thu Aug 16 14:42:00 UTC 2007

> Section 5.1 of the updated version of 2821 allows A or AAAA 
> when there is no MX.  This allowance must become obsolete and 
> the process ends when there is no MX record. 

This idea is fundamentally flawed.

There is an assumption in the Internet that email is a universal
service. In otherwords, everyone can potentially be contacted via an RFC
822 et al. email address. Part of this fundamental assumption would
require every Internet connected domain to have some means of email
contact for various default addresses such as abuse at example.com. This
does not mean that domain owner must run an email server. They may rely
on someone else for email service and divert email with an MX record.
But if a domain exists to service a single point on the Internet, i.e. a
single server, then even if we say that domain owners MUST publish an MX
record, we should still be liberal in what we accept, and search for an
A or AAAA record to see if this device will possibly accept email for
the domain.

Note that there are other possible ways to change the email architecture
to accomplish what an MX record does today, but these things need to be
done from an architectural point of view, considering the entire email
architecture, not just point changes in one narrow area. It may be that
we can build a better email architecture if we remove the universal
email assumption. Or maybe we could remove anonymous email relaying to
any arbitrary port 25 with a system of email peering (like BGP or USENET
peering) based on prearranged agreements. In that case we may assume
that email to a domain can be delivered by looking at the last hop IP
address, checking the PTR and then doing an RR lookup for the
destination domain name. Or some sort of redirection protocol such as
HTTP so that every domain must have an A or AAAA record and that device
must accept connections and identify the correct email relay agent for
incoming messages to the domain.

The key to this is not to propose or make point changes in one narrow
area, but to open up the entire architecture, look at what works,
identify the areas that need to be fixed, agree on goals and then fix
all the weaks spots at once. Personally, I am tired of seeing solutions
to the SPAM problem. I don't agree that there is a SPAM problem with
email. Instead, we have an inconsistent email architecture that was
never designed as an integrated entity and this architecture does not
have an end-to-end chain of accountability built out of bilateral trust
arrangements. If we did have such a chain, then the ISP at the end of
the chain could escalate problems up the chain until they either resolve
it or discover a breakdown in trust. At that point, blocking email
becomes easier because all relays in the chain of accountability up to
the trust breakdown can be identified and mail can be blocked, returned
to sender, or whatever. There will be several orders of magnitude less
trusted links than there are email senders, i.e. there may be 2 billion
email senders but only 20,000 trusted mail relays worldwide.

This makes problem resolution far more scalable than in todays world
where any of those 2 billion email senders are allowed to send email to
any arbitrary email server. Flat architectures do not scale, hierarchy
does. The existing email architecture is largely flat. It needs to be
made hierarchical and therefore scalable.

I hestitate to get into any in-depth discussion on any particular
technical proposal because I believe all of them are fatally flawed as
long as we have no overall agreed email architecture. Today different
groups have different understandings of what the email architecture is.
People who like SPF don't see the same architecture as people who like
DKIM or people who like Bayesian filtering or people who like blacklists
or people who like whitelists or people who use Yahoo or Gmail. In this
schizoid environment all we do is force the criminal classes to get
smarter than us, and to increase their exploitation of us. In order to
bring order back into Internet email, we need to come together and agree
on what we want from email, what is a scalable Internet email
architecture, and only then, what needs to be changed to make it so.

--Michael Dillon