On Dec 7, 2006, at 11:33 AM, Damon wrote:
By doing so, the ESP says "I, ESP am the entity sending this
email on behalf of my client, List (identified in the RFC 2822
from header) and as such an identity that is associated with that
email and can be held accountable."
So if a spammer invades a third party (ESP, ISP, ASP, ISP->ASP) I
have a conundrum... how do I distrust gmail or AOL?? Sure, I could
flip the switch but realistically, who is going to do that? Which
is why I don't want my 'as a sender' email signed by the service.
Their sig isn't worth the bits used to inject it- especially not
compared to my wholesome image.
Some type of associative method MUST be available with the SMTP
client as a ssp-requirement. Otherwise, NO signature offered by a
large provider can be safely "white-listed". The IP address of the
SMTP client will continue to be the dominate basis for acceptance.
The ESP SHOULD be interested in receiving feedback based upon the
DKIM signature, but that only happens when they use _their_
signature. This therefore REQUIRES a means to associate email-
address domains in various headers with that of the signing-domain, a
ssp-requirement.
ESPs would love to avoid responsibility, but ... you can't.
But you can't really block them either can you :)
When ESPs use customer's private keys, establishing a basis for
"white-listing" becomes more difficult and makes abuse reporting more
difficult. Associating the signing domain with email-addresses in
various header MUST be an ssp-requirement to permit the signing-
domain to represent the transmitting entity.
A bulk sender SHOULD sign with _their_ domain and have their
customer's associate their email-addresses with their domain. To
protect providers from "white-listing" replay abuse of their domain,
a means to associate the SMTP client with the signing-domain becomes
an ssp-requirement. A means to associate the From header email-
address with that of a different signing-domain becomes an ssp-
requirement.
Hence the traditional "pass through" argument.
But, that "approach" allows ESPs to avoid responsibility for the
abuse coming from their network when for example the client
imports and mails to a "bad list."
But I can't 'force' the issue by distrusting the ESP's sig... when
who we REALLY want to trust is 'The' sender
Annotation of "recognized" email-addresses "associated" with the
signing-domain offers strong protection from spoofing. Associating
the signing-domain with the SMTP client provides strong protection
from "white-listing" abuse.
One really wants to be able to trust something. As it currently
stands, by allowing any bad actor an ability to replay any message
from a "white-listed" domain prevents trust from ever being
established. Trust MUST be protected as an ssp-requirement. Trust
requires an ability to associate the SMTP client, the MailFrom, and
other email-address domains within other headers with that of the
signing-domain. DKIM MUST be able to protect trust that might be
established from abuse. These associations as an ssp-requirement
provides this protection.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
