Wietse Venema wrote:
With DKIM, The Signer Domain says "I signed this mail". It does
not approve content, or state that content is benign. The receiver
decides whether to give this signature preferred treatment. There
is little or no controversy about this aspect of DKIM.
Agree, as in my message to Steve shows and was written in the draft I-D
DSAP and as it was stated at least numerous times in the last two years,
by myself and others.
With SSP, The Sender Domain says "I send such and such mail": if
any is signed, or not signed. This is primarily relevant for mail
without valid signature by The Sender Domain. There is little or
no controversy about this aspect of SSP.
If I understand you, sure. But I think you have a decoupling mentality
about SSP mentality where I don't and I only say that because I am very
interested in eliminate abusive and exploited DKIM usage.
There is controversy about attempts by The Sender Domain to make
statements about mail handling practice by other parties such as
forwarders or receivers.
Well understood.
I see these as well-meaning attempts to provide a magic wand against
email forgery, just like the one that SPF attempted to provide;
attempts that are rooted in the assumption that The Sender Domain
can somehow constrain forwarder or receiver behavior.
Ok, I am not particularly interested in name calling or anything like
that, but sure there was a TECHNICAL DESIGN issue with SPF when it came
to indirect mail transactions where there is more than on hop.
DKIM attempts to address the practical issue and it is marketed as so in
its technology comparisons.
DKIM-BASE does solve this problem, however, its premise is based:
- no middle ware mail integrity issues,
- No regard as too is the signer, which includes that if the
original integrity is broken, the middle ware will correct
it.
So yes, DKIM-BASE does solve the forwarding problem but it that not to
say it addresses the fraudulent usage problem or mail integrity issues
that are possible when more than one hop or there is some mail
resubmission concept (Mailing List) used.
In my opinion, credibility is determined by the combination of
Sender Domain and Signer Domain; different combinations having
different credibility, many combinations having none at all. If
SSP attempts to infringe on or otherwise constrain forwarder or
receiver practice, then it may very well become as relevant as SPF.
Again, I agree over all, but I really don't care and I don't think it
will be productive to compare it to SPF or question its relevance.
If there is one legitimate comparison, then we should look at the
relevance of DomainKeys (DKEYS).
DKEYS is a prime example of where we have problems which DKIM attempts
to address.
For the most part, DKEYS == DKIM when there is no SSP, and my opinion,
DKIM risk falling into the same waste land if we don't resolve the SSP
issue.
SSP is not about reputation or accreditation.
And no one has ever said that a A/R system should not be part of some
total picture or solution for a product offering. Thats a given, but I
am not looking to lock in DKIM implementation with some very limited
"batteries required" Trust Service concept.
--
Sincerely
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html