Subject: RE: rough consensus and working code

From: Douglas Otis <[email-masked]>
Date: Wed, 16 Jun 2004 16:42:30 -0700

On Jun 15, 2004, at 13:26:41 -0400 Andrew Newton <[email-masked]> writes:
> On Jun 15, 2004, at 13:02:04 -0500, wayne wrote:
>
> > I have to agree with this assessment.  There doesn't appear to be a
> > rough consensus.  However, the long standing IETF mantra has, to the
> > best of my knowledge, been "rough consensus *AND* working code".  What
> > we lack with most proposals is working code.
>
> I think implementations are a good thing, a very good thing.
>
> However, RFC 2026 mentions that to get a Proposed Standard RFC
> implementations are not required (though they are encouraged).  To get
> a standard from Proposed Standard to Draft Standard, two separate
> interoperating implementations are required.
>
> Our milestones explicitly says "PS" - for Proposed Standard.
>
> -andy

There is a black-listing model currently excluding much of the abusive
mail today. This "working code" has demonstrated an ability to scale.
Transitioning this mechanism from using IP addresses to authorized and 
authenticated names would both exclude abusers, but would also identify
organizations able resolve issues that lead to the introduction of
abusive mail.

Current IP-based blacklists _assign_ responsibility to whoever holds
that IP address and typically there is no method to determine when
this address transfers to a different entity or if the policy issues
have been resolved. Problem hosts often share addresses or use dynamic
address assignment, where then the blacklisted IP address won't curtail
the problem until a large block of IP address space becomes blacklisted.
Consequently, a lot of IP space is blacklisted long after the
irresponsible entity has ceased holding it.

Efforts to enhance and upgrade this system to utilize authorized and
authenticated names would be carried forward by those providing named
based (RHSBL) services with otherwise negligible changes to the current
operation of mail. This authorization and authentication would also
greatly improve the usability of private lists of known good domains
such as bonded providers. It may well evolve, out of necessity of scale,
policy becomes based on known good together with those recently considered
and those pending consideration with each receiving differing treatment.

Much of this abuse is not a result of most users.  There are a few
however that send large amounts using fraudulent means.  The challenge
is to stop these fraudulent means of access while leaving unharmed 
users that have not abused the system.  This mechanism at the MTA
channel has demonstrated an ability to scale and, importantly, this
will limit access to the mail system from those not willing to identify
their systems for evaluation and follow-up whether an accreditation
service is consulted or not.

As opposed to the investment needed for signed digital certificates and
certificate authorities, a simple DNS record will substantially enable an
economic means of authorization/authentication of the MTA using existing
infrastructure and "working code" all perhaps with a single DNS query.

Just verifying the MTA alone will satisfy most requirements for policy
enforcement.  If there is a problem with an individual, then through
MTA authentication, officials will know what domain must be queried to
follow-up on criminal actions. If an individual takes action to
intentionally bypass the safeguards inherent in this system, that by
itself gives authorities a basis for criminal investigation. If the
same individual refuses to cooperate with the investigation, that's
likely to be grounds for prosecution. Without such a basis, legal
remedies aren't likely to be effective at controlling abusive mail.

The Security Consideration section of RFC2821 makes it clear where
efforts should be placed to improve mail.  Name authorization and 
Authentication for the MTA as advocated in CSV-HNA-CSA used in 
conjunction with an accreditation service DNA should dramatically
and safely reduce mail abuse.

-Doug