nanog mailing list archives
Re: Internet Email Services Association
From: Douglas Otis <dotis () mail-abuse org>
Date: Mon, 28 Feb 2005 13:04:59 -0800
On Mon, 2005-02-28 at 11:44 -0600, Kee Hinckley wrote:
At 4:51 PM +0000 2/25/05, Michael.Dillon () radianz com wrote:Because that would require providers to act like professionals, join an Internet Mail Services Association, agree on policies for mail exchange, and require mail peering agreements in order to enable port 25 access to anyone.Nice in theory, but I don't think it would scale. In essence you are asking for a return to the UUCP model, where if you wanted to send mail on the network you had to have a deal with someone. The problem isn't agreements, the problem is that there are borders at which people will not be willing to block, even if there is bad behavior.
Access providers ensuring machines from dynamic addresses are excluded from sinking or sourcing port 25 traffic would prevent residential customer's machines from acting as an anonymous SMTP client, with an exception often made between their own servers. Blocking port 25 traffic in both directions prevents address spoofing (done by tunneling reply traffic to an unblocked node elsewhere). This leaves the provider in control of their address space, as this space should not become blocked due to a history of abuse, largely due to customer's compromised systems. As an additional benefit, their networks should be less burdened on the up-link, and their customers less exposed to viruses, should blocking be done at the access interface, rather than upstream at more expensive routers.
After all, there's nothing stopping ISPs from blocking port 25 passing through their networks now.
Until alternative authenticated SMTP ports become prevalently used, there is potential for support issues, once a portion of their customers are unable to use their laptops at different locations. A solution is provided with alternative authenticated access ports, in conjunction with port 25 blocking, but this still involves a configuration change. The trade-off is less abuse reports, assuming this is monitored.
But, every time someone tries a blanket block of (for instance) China, or even appears to do so, there's a huge outcry.
Mapping dynamic addresses can be problematic from regions that do not cooperate, even when it is in their best interests to do so. A great deal of abuse is prevented using the black-hole listing methods, where, without this mechanism, email would not be practical. Capricious listings would be an expensive alternative for any listing service, however.
If you create an organization to do that, you'll not only have an outcry, you'll have a target for legal action (restraint of trade?). That kind of thing needs government level action. It's highly unlikely to happen, and it's far from clear that we would want it to.
There should be similar concerns regarding demands for DNS entries to register paths of a mailbox-domain before email is accepted. This approach attempts to burden the mailbox-domain owner, rather than the email service provider, with responding to abuse. Users of email services, however, often have no means to monitor abuse of these address based authorizations, which may result in their mailbox-domain becoming unusable. Attempting to track the source of a problem may become impossible should listing services refuse to provide sources, or providers refuse to share logs due to privacy issues. There is no standardization for path registration schemes, such as Sender-ID/SPF/SPF-Classic(new version of SPF). Although these three different schemes claim to use the same DNS record, they apply far different rules for various mailbox-domains. Asking for logs as to why mail has gone missing may require learning about everyone's use of RFC2822 FROM, or SENDER, or RESENT-FROM, or RESENT-SENDER, or RFC2821 MAILFROM depending upon which email filtering algorithm was applied. There is no means to discern which mailbox-domain within messages were subjected to filtering or reputation assessments. This says nothing of risks imposed by active content in DNS, the ignoring of exponential UDP back-off, and requiring compliant receivers to parse more than 100 DNS records, etc. -Doug
Current thread:
- Re: Internet Email Services Association ( wasRE: Why do so few mail providers support Port 587?) Kee Hinckley (Feb 28)
- Re: Internet Email Services Association Douglas Otis (Feb 28)
- Re: Internet Email Services Association ( wasRE: Why do so few mail providers support Port 587?) Michael . Dillon (Mar 01)
- Re: Internet Email Services Association ( wasRE: Why do so few mail providers support Port 587?) Valdis . Kletnieks (Mar 01)
- Re: Internet Email Services Association ( wasRE: Why do so few mail providers su Stephane Bortzmeyer (Mar 01)
- Re: Internet Email Services Association ( wasRE: Why do so few mail providers su Suresh Ramasubramanian (Mar 01)
- Re: Internet Email Services Association ( wasRE: Why do so few mail providers support Port 587?) Michael . Dillon (Mar 01)
- Re: Internet Email Services Association Chris Edwards (Mar 01)
- Re: Internet Email Services Association Michael . Dillon (Mar 01)
- Re: Internet Email Services Association ( wasRE: Why do so few mail providers support Port 587?) Valdis . Kletnieks (Mar 01)
- Re: Internet Email Services Association ( wasRE: Why do so few mail providers support Port 587?) Todd Vierling (Mar 01)
- Re: Internet Email Services Association Niels Bakker (Mar 02)