On Thu, 2005-02-10 at 19:17 -0500, Sam Hartman wrote:
"Michael" == Michael Thomas <mike(_at_)mtcc(_dot_)com> writes:
Michael> On Thu, 2005-02-10 at 16:53 -0500, Sam Hartman wrote:
>> >>>>> "John" == John R Levine <johnl(_at_)iecc(_dot_)com> writes:
John> This is the Project Lumos fallacy. I have no interest
John> whatsoever in distinguishing between a domain's nice users
John> and its nasty users. I believe that each domain is
John> responsible for keeping its users in line, and the reason
John> that signatures are useful is to help me alert domains about
John> undesirable mail they've sent. If they send a lot of
John> undesirable mail, I'm going to reject the whole domain, not
John> do their filtering for them.
>> As discussed in section 4.1 of Russ's draft, a domain cannot
>> know how widely a message will be distributed. Once I have a
>> signed copy of that message I can choose to distribute it much
>> more widely than the sending domain might like me to do.
Michael> That's true _regardless_ of whether there's a signature
Michael> there or not. That's why characterizing this as a replay
Michael> attack fundamentally misses the point about mail
Michael> distribution: with SMTP, that's a feature not a bug.
It's an attack that prevents you from building up useful reputation
data about a significant class of domain.
Actually, I'd call it an _insignificant_ class of domain because
the reputation that you can derive from, oh say, hotmail or aol
or y! is so, so very problematic: even if they are behaving badly,
who would dare blacklist them? (ok, there will be some ninnies, but
they're outliers). *Far* more interesting and significant are the
domains that are *not* very well known. This gives a big incentive
to do very good policing lest your reputation suffer...
If you don't want to call it a replay attack, that's fine with me. At
the crypto protocol level it is a replay; thinking of it that way may
or may not help you to understand it.
Do PGP or S/MIME have "replay attacks"?
I really think that "replay" is extremely unhelpful since it implies
that at a fundamental level that SMTP has such a concept: it does
not. Which isn't to say that there isn't an issue, just that
calling it a replay only serves mask the underlying issues.