Subject: [Asrg] 1. Inventory of Problems - Input Needed

From: Yakov Shafranovich <[email-masked]>
Date: Wed, 05 Nov 2003 17:57:11 -0500

The inventory of problems document outlines the various problems that
cause spam and are caused by spam. The last known draft is available at:

http://www.irtf.org/asrg/draft-asrg-inventory-of-problems.txt

Additionally, the technical considerations document discusses different
points of control in the email infrastructure and the consent framework
looks at some of the consent issues in the email infrastructure. These
documents can be found at:

http://www.ietf.org/internet-drafts/draft-crocker-spam-techconsider-02.txt
http://www.solidmatrix.com/research/asrg/asrg-consent-framework.html

We are seeking additional input on this document and more volunteers to
help out with it. Please post comments to the list directly or contact
us off-list.

Yakov

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

---

From: "Alan DeKok" <[email-masked]>
Date: Wed, 05 Nov 2003 23:35:43 -0500

> help out with it. Please post comments to the list directly or contact

  I believe that both the inventory of problems, and the technical
considerations documents, are strongly related.  Both need more focus,
and the diagrams in:

    http://www.elan.net/~william/asrg-emailpathverification-presentation.pdf

  are a good start.

  That document needs to be expanded to talk about specific network
configurations used to deliver mail, which protocols are involved
where, and which fields of those protocols are open to what kind of
abuse.  Once we have such a document, we can then proceed with
"solving the problem in diagram X, protocol Y, abuse of field Z".

  Having a narrow statement of the problem scope means that any
contentious issues are minimized, as the discussion is about specific
real-world details, and not personal opinion.  It also means that the
inventory of problems is relatively simple: point to the diagrams, and
the points of abuse that they contain.  Many technical considerations
are likewise straightforward: changes this point of network
communication propogate throughout the rest of the diagram.

  I think this post means that I'm volunteering to write that
document.  I'm not sure I'm happy with taking on more work, and I'm
certainly not an SMTP or DNS expert.  But having something on paper
will be useful.

  Alan DeKok.