On 28/Sep/10 19:39, Kai Engert wrote:
On 28.09.2010 10:55, Jose-Marcio Martins da Cruz wrote:
As there are other quite good signing schemas around us, a
discussion could be around comparing schemas. E.g., how do you place
SpamSalt WRT DKIM ? What's the differences ? Why SpamSalt could be
better or worse than DKIM ?
At the time I came up with the SpamSalt proposal, I wasn't aware of DKIM.
They're strikingly similar, including patent encumbrance.
Some differences between DKIM and SpamSalt:
(a) SpamSalt is not limited to the period of time that a message is in
transit.
Irrelevant, nobody cares much about yesterday's spam. The outcome of
checking on arrival (Authentication-Results) is supposed to be
recorded in its own header field.
(b) DKIM adds a domain-level signature, SpamSalt proposes signatures
that are associated to individual mailboxes.
DKIM's approach is better, after establishing that users are too lazy
to use PGP or S/MIME.
(c) DKIM doesn't seem to provide a revocation mechanism for emails
that have been produced while an individual user's credentials were
compromised (e.g. because of a computer virus). With SpamSalt the
verification can be delayed or repeated until a recipient first looks
at an email. By that time, after the transit but before reading, it
may have become known that the message originates from a spam account
or a compromised account and can be automatically treated as such.
Good point. However, what do you mean by "looking at an email"? Most
users are quick enough with the "del" button even without assistance...
DKIM allows senders to quickly change keys, for limiting replays.
Since SpamSalt only signs a few fields, it seems it would be more
vulnerable to replay attacks.
(d) SpamSalt doesn't require that existing transport agent software
gets changed or upgraded, thus allowing for less intrusive migration.
It's sufficient to install complementary server applications and
upgrade client applications.
Neither does DKIM.
(e) SpamSalt doesn't help against sender domains that exist for the
sole purpose of sending spam.
Neither does DKIM.
(f) SpamSalt and DKIM don't seem to be in conflict, but rather be able
to complement one another.
If DKIM worked reliably, SpamSalt would not be needed, though.
My comments above are skewed in favor of DKIM, because I've already
installed the required complementary software :-) Given that you
nearly reinvented it, you should be very much interested in DKIM;
consider that it has already gathered some years of field testing.
_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
http://www.irtf.org/mailman/listinfo/asrg