On Oct 26, 2005, at 8:30 PM, Hector Santos wrote:
So as a SMTP vendor, I really don't care what your mail is about,
who is
from, etc, as long as you are who you say you are and if need be,
you can be
contacted and/or mail can be returned (bounce). In other words,
"play by
the rules" of the transport and email system.
Fortunately, the policies established by the recipient can be much
stronger than those established by the government or SMTP vendors.
Playing by the rules should include not sending unsolicited bulk email.
So to me, DKIM with a strong SSP checking concept, provides another
level of
transaction consistency checking that may be used by the SMTP-DATA or
POST-SMTP process to perform a final PAYLOAD check. I don't
believe this
checking should include a "REPUTATION" concept at this level. I
think "DKIM
signing consistency" is the key goal.
I am not against the repudiation aspect of non-signed messages. The
objection results from not considering which domain introduced the
message. The current SSP is not compatible with current email
practices and aimed specifically at establishing unfair reputation
assessments on email-address domains, rather than signing-domains.
Ask yourself why SSP precludes a signature that is is not bound to
some email-address. There could still be assertions that all servers
within a domain signs all messages. See I-D.crocker-csv-csa-00 for
an example.
In all cases, it is about verification of the transport process
entities and
since we lack this with the current SMTP protocol, augmenting it
with DKIM
should at the very least be strongly offer a consistency model, not
a weak
one.
DKIM should identify the domain associated with the email message
transport. It is over-reaching, to say the least, when attempting to
use this mechanism to verify the author of the message. Leave that
effort to OpenPGP and S/MIME. By establishing the accountable
domain, abuse can be handled in a more efficient manner than it is
today. This would also afford opportunistic identifications akin to
that used with SSH. I don't think this aspect has been given any
consideration.
-Doug
_______________________________________________
ietf-dkim mailing list
http://dkim.org