Doug,
Never mind the first or third party - we don't even have the support for
"Always Expect Valid Signature"
So where is the payoff? As long as verifiers don't support or enable
policy in their software and are encouraged not to do so by the
authors of the current policy draft standard, all these extra
considerations especially the more complex suggestions, is all for
nothing. I'm willing to explore TPA and my own DSAP, or the exacted
ASL "lit version" idea for ADSP extension (which my current
implementation supports), but it means nothing if we can't get the
other authors and implementations to explore as well.
Only prior arrangement, special signer and receiver arrangements (a
policy) seems to be of any value.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
Douglas Otis wrote:
On 9/17/10 3:12 PM, J.D. Falk wrote:
On Sep 17, 2010, at 2:50 PM, Murray S. Kucherawy wrote:
If this is primarily a workaround for perceived limitations of
reputation systems, then I humbly suggest that the premise is
invalid. Today's reputation systems aren't static; the operators
are constantly changing them in reaction to what the spammers
do.
I realize that the answer to this will be largely speculation,
but: Will that continue to be true in the IPv6-based and
domain-based future of reputation systems?
Having to make ongoing adjustments might be a hindrance to such
systems.
It's always a hindrance, sure, but there's nothing inherent to IPv4
which makes the adjustments necessary.
The purpose of reputation is to curtail abusive source acceptance. When
reputation is based upon a DKIM domain, replay abuse must be ignored in
reputation assessments when recipients are not contained within the
signed content. Such abuse must be controlled through other means.
Please articulate what you see as an adjustment solving the fundamental
replay issue haunting cryptographic techniques not bound to a specific
source or destination? Within an IPv6 environment, the concept of using
the Return-Path or the PRA as ancillary requirements makes email more
fragile, where expressing all IP address sources for a single domain is
both not practical, and at times, not possible.
As a separate issue, the joint-sigs draft assumes the third-party
service causing practice compliance problems are signing their messages
using DKIM. It also shares the difficulty related to the TPA-Label
scheme in that the sender must anticipate signing domains used by a
service expected to forward their message. Unlike the TPA-Label scheme,
joint-sigs lacks a means to delegate this effort to a different
entity. It seems doubtful safety is improved by suggesting Author
Domains are thereby less accountable allowing a reduction of message
elements being signed that are normally needed to prevent spoofing.
Adjustments to reputation systems are necessary because spammers
keep changing tactics, attempting to get around the reputation
systems. And, patterns in legitimate mail change over time as well;
it wasn't so long ago that Facebook notifications were getting caught
by spam filters looking for similarity, which makes sense because
they're all extremely similar -- and there's a lot of volume.
When DKIM is used to white-list domains, this then runs the risk of
white-listed messages being replayed and directed to recipients not
intended by the signing domain.
Any reputation system, or filter, or other anti-spam method which
isn't reacting to changes will quickly become either ineffective at
catching spam or ineffective at not catching non-spam, and people
will stop using it, and pretty soon it'll be forgotten.
Reputation based upon what? DKIM lacks a means to deal with replay
abuse, nor is DKIM related to servers introducing email into public
email streams. What are you suggesting will happen with DKIM reputation?
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html