nanog mailing list archives
RE: Discovering policy
From: <michael.dillon () bt com>
Date: Thu, 16 Aug 2007 15:42:00 +0100
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
Current thread:
- Re: [policy] When Tech Meets Policy..., (continued)
- Re: [policy] When Tech Meets Policy... Simon Lyall (Aug 15)
- Re: [policy] When Tech Meets Policy... Mark Andrews (Aug 14)
- Re: [policy] When Tech Meets Policy... Douglas Otis (Aug 14)
- Re: [policy] When Tech Meets Policy... Chris L. Morrow (Aug 14)
- Re: [policy] When Tech Meets Policy... Mark Andrews (Aug 14)
- Discovering policy Douglas Otis (Aug 15)
- Re: Discovering policy Mark Andrews (Aug 15)
- Re: Discovering policy Douglas Otis (Aug 15)
- Re: Discovering policy Mark Andrews (Aug 15)
- wierd dns thread (Re: Discovering policy) Paul Vixie (Aug 16)
- RE: Discovering policy michael.dillon (Aug 16)
- Re: [policy] When Tech Meets Policy... Barry Shein (Aug 15)
- Re: [policy] When Tech Meets Policy... Al Iverson (Aug 15)
- Re: [policy] When Tech Meets Policy... Steve Atkins (Aug 15)
- Re: [policy] When Tech Meets Policy... Andrew Sullivan (Aug 15)
- Re: [policy] When Tech Meets Policy... Douglas Otis (Aug 15)
- Re: [policy] When Tech Meets Policy... Barry Shein (Aug 15)
- Re: [policy] When Tech Meets Policy... Fred Baker (Aug 15)
- Re: [policy] When Tech Meets Policy... Douglas Otis (Aug 15)
- Re: [policy] When Tech Meets Policy... Bill Stewart (Aug 20)
- Re: [policy] When Tech Meets Policy... Tony Finch (Aug 14)