Re: [ietf-dkim] on DKIM as an anti-spam measure

John R Levine wrote:
> > assertions:
> >
> > "this message is interpersonal business correspondence that is
> > manually sent by a human to at most N recipients"  (for some constant
> > N, say 20)
> > "this message is advertising for products in categories A, B, C"
> > "this message is related to a particular business transaction"
> > "this message is related to an ongoing business relationship"
> > "I will pay you $x for reading this message"
> > "this message contains sexually-explicit content"
>
> Yeah, this is the same sort of stuff that Lumos was pushing.  Like I said,
> recipients don't care.  If the sender has a good reputation, they'll take
> all the mail, if the sender has a bad reputation, they'll dump all of it.
And like I said, you're lumping all recipients into one bucket.  And 
ISPs typically aren't directly serving the market that is most likely to 
care.  I agree that the consumer market largely doesn't care and will, 
for the immediate future at least, mostly behave as you describe.  I 
want email to work well for more than just the consumer market.
> Lumos was backed by just about every company in the bulk mail sending
> industry, and it got no traction with ISPs or other recipients.  Zero.
> Zip.  Nada.  This approach is a proven failure.  Why haven't you done a
> little research into prior efforts to find out what's already been tried
> and failed? 
You and I appear to have different models for what it means for this to 
be successful.  Note also that First Virtual failed, where Paypal 
succeeded, even though they were fairly similar at what they intended to 
do and how they intended to do it.  What was the difference?  Mostly, 
changes in conditions and attitudes.  Should Paypal have given up 
because First Virtual failed?
> > I see plenty of incentives.  Lots of people hate some company, some
> > organization, or some body.  Maybe Al Queda wants to discredit the
> > Republican party by resending lots of campaign messages to unwilling
> > recipients.   Maybe some bent-out-of-shape open source advocate wants
> > to discredit Microsoft by a similar method.  Maybe some bent-out-of-
> > shape operating system purveyor wants to discredit open source
> > advocates.  Maybe some right wing nutcases want to discredit liberals.
>
> How much mail in those categories have you gotten in the past year? 
It's mostly an irrelevant question, for two reasons.  One is that 
neither you nor I is likely to know which of the spams we receive was 
directly sent by the purported author and which of them was resent by a 
third party unrelated to the author.  The other is that just because a 
threat hasn't been exploited doesn't mean that it won't be exploited. 
When someone discovers a hole in Windows, it doesn't mean that it 
necessarily will be exploited, but it means there's an opportunity for 
an exploit.  We know from experience that people do try to exploit holes 
in Windows, so it makes sense to try to patch those holes.  Same here. 
We also know from experience that people do sometimes try to discredit 
companies, organizations, or individuals by making them appear to be 
abusive.
> Me neither.  What is the point of concocting implausible scenarios unlike
> what people actually do with e-mail?
What's the basis for assuming that people's behavior (either attackers 
or email users) will remain constant, given plenty of evidence that it's 
constantly changing?
> > > If a sender has a good reputation, recipients will take all of their
> > > mail.  If it has a bad reputation, they'll reject it.
> > I don't think so.  I think lots of recipients will want to
> > distinguish transaction correspondence from other correspondence from
> > a particular business.
>
> How many people do you know who do that today? 
Several.  Lots of companies allow separate opt-out or opt-in for 
different kinds of email.  And at least some people that I know use such 
facilities.
> I know companies doing mail sender certification that were prepared to offer
> separate data for transaction mail and list mail, and no recipients wanted
> to use them differently so there wasn't any point.  
Market research can be deceiving here.  The introduction of email 
authentication will change the nature of spam that people receive. 
Surveys based on people's current expectations of spam won't produce 
meaningful results.  Also, I doubt that it was "no" recipients - I 
suspect it was "too small a number of recipients to make a profitable 
business" and perhaps "..within the timeframe required by our funding 
sources".  But from my point of view, I'm not trying to make a profit on 
this.  I'm trying to make email work well over the long term, and this 
requires accommodating diverse user interests.  It should not be 
automatically assumed that the legitimate needs of a relatively small 
group of people are irrelevant, nor that current needs are the same as 
future needs. The important thing is not just that DKIM meet current 
needs, it's that DKIM be flexible enough to adapt to future needs.
Relative to DKIM's authentication model I'm asking for two things: one 
is the ability to separately authenticate successive submissions of the 
same message without destroying information about earlier submission. 
The other is the ability to authenticate envelope information in 
addition to header and body information.  I'm asking for these because I 
know through long experience that sometimes it's important to know who 
originally sent a message, sometimes it's important to know who last 
sent a message, and sometimes it's important to know to whom the message 
was sent.
Neither of these are significant changes to DKIM, especially at this 
stage of investment.  And together they make DKIM much more flexible. 
People argue that DKIM shouldn't be this flexible, but they're missing 
the point that email is already this flexible, and this flexibility is 
used by a significant and growing group of users.  DKIM needs to support 
what people need to do with email rather than cripple it.
Keith

_______________________________________________
ietf-dkim mailing list
http://dkim.org