Subject: [Asrg] NAI/ESPC Project Lumos whitepaper & request for comment

From: Liudvikas Bukys <[email-masked]>
Date: Mon, 29 Sep 2003 09:32:23 -0400

Excerpted from the press release
http://www.networkadvertising.org/espc/092903lumos.asp

	Details of Project Lumos technical architecture were unveiled today in
	a white paper entitled "Project Lumos: A Solutions Blueprint for
	Solving the Spam Problem by Establishing Volume Email Sender
	Accountability." The white paper illustrates how the registry can
	easily be implemented in conjunction with current spam fighting
	technology. The white paper also provides a blueprint for easy
	implementation of Project Lumos by ISPs. Project Lumos will allow ISPs,
	without significant infrastructure changes, to quickly and
	inexpensively reject mail connections from spammers without needing to
	accept, store and analyze the fraudulent mail. This should dramatically
	reduce the amount of resources required to handle spam.

	ESPC is encouraging reviews, recommendations, and comments from the
	industry. For information and to download the white paper, visit
	www.networkadvertising.org/espc/project_lumos.asp.

	About NAI's Email Service Provider Coalition:  The Email Service
	Provider Coalition (ESPC) was formed in November 2002 by the Network
	Advertising Initiative (NAI) to fight spam while protecting the
	delivery of legitimate email. The ESPC is comprised of 37 members
	including aQuantive, Blue Dolphin, Digital Impact, DoubleClick,
	Experian, IMN, and Roving Software. The ESPC members have recognized
	the need for strong spam solutions that ensure the delivery of
	legitimate email. To this end, the ESPC has created several crucial
	sub-committees, including legislative and technical committees, which
	have been very active in the war against spam. Our flagship initiative,
	Project Lumos, is an industry proposal for a registry-based solution to
	the spam problem.

_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: Yakov Shafranovich <[email-masked]>
Date: Mon, 29 Sep 2003 15:04:04 -0400

I took a look at their white paper and there are a few points I would 
like to make. One of the authors of the white paper is on the mailing list.

FIRST of all, the whitepaper makes a wide use of "X-" headers which are 
not meant to be used in standards. Since "Project Lumos" is not a 
standard its a not a problem, but I am still not comfortable with it.

SECOND, the entire notion of reputation systems of which this proposal 
is part of, fits within the consent framework within the notion of 
"source tracking components". Reputation and certification systems such 
as this one are used to track and certify the source of the message. 
This proposal can fit very well within the framework but not to the 
exclusion of all other proposals.

THIRD, this proposal assumes the use of this service ONLY and a 
deployment of 18-24 months. After deployment:

"By the end of Phase 4, email sent from unknown, unregistered Senders 
and/or ESPs will be unlikely to get through to recipients' inboxes or 
will be rate limited disallowing any high-volume delivery without secure 
identity."

The technical considerations document 
(http://www.ietf.org/internet-drafts/draft-crocker-spam-techconsider-02.txt) 
states:

"    Remember that the Internet comprises a massive number
      of independent administrations, each with their own
      politics and funding. What is important and feasible to
      one might be neither to another. If the latter
      administration is in the handling path for a message,
      then it will not have implemented the necessary control
      mechanism. Worse, it well might not be possible to
      change this.  For example a proposal that requires a
      brand new mail service is not likely to gain much
      traction.
"

Unfortunatly I do not see how this proposal can hope to achieve 
deployment within 18-24 months. What is more realistic is reformulating 
this proposal within the consent framework as one of the many sources of 
information available to email administrators. Addressing both the 
requirements and technical considerations documents would prove useful 
as well.

Yakov