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