On Mar 10, 2006, at 3:15 PM, Dave Crocker wrote:
Daniel Dreymann wrote:
Not to add too much confusion, let us not forget that CAN SPAM
uses the term "sender" solely for what is referred below as "author".
There are several problems with this:
1. Can-Spam is but one country's law and choice of terminology.
2. Their particular vocabulary has not seemed to have much effect
on anyone else's choices.
3. The problem with that particular word's ambiguity in general,
anti-spam discussions, is not small. We really do need a tiny
number of easily remembered and used terms that make important
distinctions.
#3 is the main issue, as I see it.
Using Nicks list
--- the-entity-responsible-for-creating-the-content-of-a-message
User identification is out of scope for DKIM as it falls into the
realm of S/MIME and OpenPGP. Although there might be coincident
domains in the signature and email-address found in a header field
commonly related to a domain of origin, there is little to confirm
the user has been properly identified by the signing-domain and the
recipient has properly recognized the user. Accountability for user
verification remains with the signing-domain. As such, the signing-
domain, and not the user must be held accountable. Problems are
resolved at the domain and not at the user, so there is little value
describing the roles of individuals. Consider this a problem of what
email delivery function can be associated with what domain. There is
greater value discarding the concepts of author/provender, sender/
provider, or book/publisher. There is also already some IPR related
to this distinction called the PRA. There seems to be little value
reinventing this wheel.
--- the-entity-responsible-for-emanating-a-message
This operation might be done by the MSA or a Mediator (such as a
list server) where either role should be identifiable.
--- the-entity-responsible-for-getting-a-message-to-a-recipient.
This operation is done by the MDA.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html