nanog mailing list archives
Re: Email peering
From: Mike Leber <mleber () he net>
Date: Fri, 17 Jun 2005 16:08:37 -0700 (PDT)
On Fri, 17 Jun 2005 Michael.Dillon () btradianz com wrote:
Similar concept, same scaling problems; it just hides the explicitroutingfrom the user (as would any modern "peering" system, presumably).Then you are presuming wrongly. Nowhere in what I wrote have I suggested any changes in the existing email technology. I am not suggesting that we drop SMTP in favour of your favourite old dusty protocol. I am suggesting that we need a system of accountability for people who run Internet email servers based on contracts and SLAs, i.e. peering agreements.
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+). Here is a downloadable reference implementation for use with procmail: http://mxplus.org/ The example program mxplus is code that was carved out of the mail server software we use and made standalone. It's an antispam option that works well for many users. The example includes sender email address validation, which is another test like MX+ that works well for most users and breaks under usually acceptable circumstances when senders do bad things like send email with an invalid From address. YMMV. 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 | +-----------------------------------------------------------------------+
Current thread:
- Re: Email peering (Was: Economics of SPAM [Was: Micorsoft's Sender IDAuthentication......?], (continued)
- Re: Email peering (Was: Economics of SPAM [Was: Micorsoft's Sender IDAuthentication......?] Todd Vierling (Jun 16)
- Re: Email peering (Was: Economics of SPAM [Was: Micorsoft's Sender IDAuthentication......?] Joe Maimon (Jun 16)
- Re: Email peering (Was: Economics of SPAM [Was: Micorsoft's Sender IDAuthentication......?] Steven M. Bellovin (Jun 16)
- Re: Email peering (Was: Economics of SPAM [Was: Micorsoft's Sender IDAuthentication......?] Todd Vierling (Jun 16)
- Re: Email peering (Was: Economics of SPAM [Was: Micorsoft's Sender IDAuthentication......?] william(at)elan.net (Jun 16)
- Re: Email peering Michael . Dillon (Jun 17)
- Re: Email peering Joe Maimon (Jun 17)
- Re: Email peering Suresh Ramasubramanian (Jun 17)
- Re: Email peering Dave Crocker (Jun 18)
- Re: Email peering Steven M. Bellovin (Jun 17)
- Re: Email peering Mike Leber (Jun 17)
- Re: Email peering John Levine (Jun 18)
- Re: Email peering Mike Leber (Jun 18)
- Re: Email peering John Levine (Jun 18)
- Re: Email peering Alexei Roudnev (Jun 19)
- Re: Email peering Suresh Ramasubramanian (Jun 20)
- Re: Email peering (Was: Economics of SPAM [Was: Micorsoft's Sender IDAuthentication......?] Michael . Dillon (Jun 17)
- Message not available
- Re: Email peering (Was: Economics of SPAM [Was: Micorsoft's SenderIDAuthentication......?] Ben Hubbard (Jun 17)
- Re: Email peering Michael . Dillon (Jun 17)
- Message not available
- Re: Email peering Ben Hubbard (Jun 17)
- Re: Email peering Rich Kulawiec (Jun 21)