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@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