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

[John R Levine]

> > 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.com, Primary Perpetrator of "The Internet for Dummies",
Information Superhighwayman wanna-be, http://iecc.com/johnl, Mayor
"I dropped the toothpaste", said Tom, crestfallenly.