ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] Replay isn't the problem, spam is the problem

2005-08-09 08:11:28
Oh, look, now we're back full circle.  Please explain how your reply
protector can tell the difference between an evil replay and a normal
standard garden variety mailing list

When we receive a message from forwarder/mailing list, it will normally
be without replay protection, just like with current DKIM.

Hmmn.  Now I have to say that I have no idea whatsoever how your replay
protector is expected to work.  Could you give us an example in as much
detail as possible?  Say A sends a signed message and B receives it.  What
does A do?  What does B do?  What extra infrastructure do you expect to be
in place?

No I don't. DKIM may _motivate_ spammers to send the same messages,
signed by some victim sending domain, to many recipients.

This is what makes no sense.  Why would spammers do something that's
guaranteed to get more of their mail filtered out?  The more identical
copies you send of something, the faster it's caught by Brightmail and
Razor.  Or are you expecting people to abandon their current spam filters
when DKIM arrives, and reinvent them all de novo?

I can certainly see that a Razor like system that distributed signatures
of mail that lands in spamtraps would be useful.  But I can't see that has
anything to do with replay detection, since you list something because
it's spam, not because it's been replayed.

Regards,
John Levine, johnl(_at_)iecc(_dot_)com, Primary Perpetrator of "The Internet 
for Dummies",
Information Superhighwayman wanna-be, http://iecc.com/johnl, Mayor
"I dropped the toothpaste", said Tom, crestfallenly.
_______________________________________________
ietf-dkim mailing list
ietf-dkim(_at_)mipassoc(_dot_)org
http://mipassoc.org/mailman/listinfo/ietf-dkim