Internet Email Services Association

Mon Feb 28 21:04:59 UTC 2005

On Mon, 2005-02-28 at 11:44 -0600, Kee Hinckley wrote:
> At 4:51 PM +0000 2/25/05, Michael.Dillon at 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