On 18 Jun 2005, John Levine wrote: > >In between the choice of accepting mail from *anybody* by default > >which we have now and the choice of accepting mail from *nobody* by > >default that explicit peering agreements represents there is another > >solution; which is to accept mail only from IPs that have *some > >relation* to the sender's From domain, for example by MX record or by > >reverse DNS (we implemented that test and call it MX+). > > This has the same problem as all of the other duct tape authorization > schemes -- it breaks a lot of valid e-mail, so that you have to > maintain a painfully large manual exception table, or write off a lot > of mail that your users will not forgive you for losing, or more > likely, both. > > In this particular case, the biggest issue is forwarders, commercial > ones like pobox.com, associations like the ACM and IEEE (I get some > odd mail being uucp at computer.org), and large numbers of colleges > and universities which let graduates keep their email address. In all > of those cases, the users send mail from their own ISPs, whatever they > are, inbound mail is forwarded back to the ISP accounts, and there is > no way to enumerate the valid sources of mail.
This gets into the discussion of what percentage of mail a user gets that is like this. It varies widely. From our measurements for most users this is less than 1 percent. For me or you its definitely much higher than 1 percent (I definitely agree with you). > There's also plenty of domains where the inbound and outbound mail > servers are different, and neither one matches the domain name of the > mail. For example, I host about 300 small mail domains on a pop > toaster here. The MX is mail2.iecc.com, and the outbound host that > many but not all of them use is xuxa.iecc.com. (Mail for iecc.com > itself is on another host.) The IPs all happen to be in the same /24, > but guessing whether two IPs are "close enough" is a poor way to > authenticate or authorize anything. In between the two extremes of spam growing at the rate of Moores law and not using email anymore there are all sorts of solutions. Pick a solution or solutions that you like, or not. Virtually all of them will result in some sort of reduction in the current ability of anybody being able to send mail as anyone from anywhere. > Before you point out that they could change the way those systems work > to be compatible with your scheme, well, duh, sure. Nope wasn't going to. They'll break when sending to people who filter or reject based on MX+. > But if you're going to make people change their existing working mail > setups, there's little point in going through the vast cost of a > widespread change for such a marginal benefit. Read archives of SPF > mailing lists for endless flamage on this topic, since SPF has the > same problem. Oh yeah. The only different here is that this is simpler, doesn't require any interpretation of the SPF/Microsoft policy/patent wars, and doesn't involve a complex virtually turning complete macro language embeded in DNS. You don't have to understand any new DNS entries because there are no special DNS entries with MX+. With regards to the marginal benefit, this a measurement thing that only you can determine for your specific userbase. We can measure the results from MX+ and greylisting for our users. For the people that use it, they are really happy. Perhaps they correspond with more users of large ISPs and companies that satisfy the test criteria. If you assert that it won't work for your users, that's completely within the realm of normal decision making, who am I to tell you what is going to work for your users. You only have so much time in the day, you have to make your own judgement calls for whatever techniques to make available to your users. Mike. +----------------- H U R R I C A N E - E L E C T R I C -----------------+ | Mike Leber Direct Internet Connections Voice 510 580 4100 | | Hurricane Electric Web Hosting Colocation Fax 510 580 4151 | | [EMAIL PROTECTED] http://www.he.net | +-----------------------------------------------------------------------+
