Re: Email peering

[Mike Leber <mleber () he net>]

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 |
| mleber () he net                                       http://www.he.net |
+-----------------------------------------------------------------------+