Re: SPF is harmful. Adopt it.

It's probably best to have this discussion in the forum dedicated to it, 
partly because others can contribute but also not least because you may well 
have a better chance of reaching me here than via SMTP-based Internet mail.  
Therefore:

%%> Even ideas of moving the costs to the sender are defeated in
%%> the new era when the majority of the spam is sent through
%%> "cracked" Windows machines. What does the spammer care if
%%> the Windows box bears the cost?

JdeBP> I've seen this argument once before.  It's wrong.  It is 
JdeBP> based upon a fundamental misconception of what is being done.
JdeBP> The point is not to move the costs to the sender in order to
JdeBP> penalise the sender.  Sending is cheap, after all.  We want 
JdeBP> it to remain cheap.  The point is to move costs _off the
JdeBP> recipient_, because incurring disproportionate costs for the
JdeBP> recipient is the whole nub of the UBM problem.  Having an army
JdeBP> of unwitting or complicit third parties for sending UBM does
JdeBP> _not_ defeat a "sender stores" architecture.  The recipients
JdeBP> still don't end up paying for the mail.

%%> But how does this framework address the biggest cost of all 
%%> which is person time sorting through the emails?   The main 
%%> option mentioned seems to be blacklisting message stores.

I'm not sure that the fact that people have to read messages is something 
that we can, let alone should, be trying to eliminate.  What an IM2000 
system does is provide weapons to recipients in order to punish, by 
ostracism, those who have sent undesirable mail, and to deter, by threat of 
ostracism, senders and their agents (i.e. message store owners) from sending 
such mail.  These are surprisingly versatile weapons, that can be used in a 
wide variety of ways.  (I've come up with several widely different ideas for 
their use, which I might set out at some point.)  They are also more 
flexible than you imply.  One can choose to ostracise entire message stores.  
But that's not the only setting.  One can also choose to ostracise 
individual originators or to ostracise the RNASP clients who send the 
notifications.  (Ironically, IM2000 Internet mail is a system where a 
mechanism _like_ SPF makes a lot more sense than it does for SMTP-based 
Internet mail.  Why would one accept a message notification claiming that 
there's a message at AOL's message store from anything other than AOL's 
designated RNASP client IP address(es)?  As I said, these are versatile 
weapons.)

%%> If anything it appears to reduce the spammers costs per message as 
%%> they need only say "we sent mail to you". Rather than sending a million
%%> copies of which only a few dozen are read, they can notify a billion
%%> people instead, and only ship 120 copies in the same bandwidth.
%%> 
%%> What am I missing?

You are missing the facts that 
    (a) recipients don't have to honour notifications at all;
    (b) sending a notification doesn't (by design) convey any of the actual 
        message content that the sender wants the recipient to read;
    (c) you have to count the bandwidth used to transmit the message to
        those recipients that _do_ choose to read it, as well;
    and
    (d) this isn't about penalising senders, since we want to _take
        advantage of_ the fact that sending is cheap not eliminate it, 
        but about reducing costs to recipients.

%%> Whatever the hurdle is - it must be one that authenticates
%%> the user - so that only one person jumps the hurdle at a
%%> time, and the hurdle must be jumped each time the
%%> authentication details are modified (unless trust
%%> is conveyed by some other means - digital signature).

JdeBP> Imposing artifical costs on senders that the system inherently 
JdeBP> doesn't actually require - be they responding to challenges, 
JdeBP> electronic postage stamps, or authentication - isn't the answer.
JdeBP> Sending is cheap.  But the answer is not to make it artifically
JdeBP> expensive.  The answer is to create a system that _takes advantage_ 
JdeBP> of the economics of Internet communication, to replace the one that 
JdeBP> is confounded by them.

%%> But C/R doesn't make it artifically expensive - the hurdle isn't 
%%> expense in sending the message, it is "use a valid reply address".

The artificial expense with challenge-response is "send two messages to have 
only one arrive".  However: The challenges that I was talking about there, 
though, are the sort of challenges that "hashcash" ideas involve.

JdeBP> <URL:http://homepages.tesco.net./~J.deBoynePollard/FGA/smtp-anti-ubm-dont-work.html#ChallengeResponse>
 
%%> ->Sent by a sender who fails to respond to a challenge" is not the same
%%> ->as "unsolicited bulk". Blocking mail with the former quality won't
%%> ->block mail with the latter.
%%>
%%> No but it mandates a genuine address is used, so you can block that
%%> address in future, which sound like the same level of eyeball 
%%> protection that IM2000 gives me.

1.  It doesn't mandate that at all.  It mandates that an address that 
will respond to challenges be used.  That's _not_ the same thing.

2.  You missed the _very next paragraph_ on that page.

3.  The two are different.  IM2000 scales well.  Challenge-response 
causes serious problems if adopted by more than a very small percentage 
of SMTP-based Internet mail users.

4.  IM2000 isn't solely about protecting eyeballs.  It's about protecting
discs and networks, too.

%%> Sure some people may not respond to challenges but then some 
%%> people may not switch to IM2000, apathy trumps everything.

But here we have two other, further, differences between IM2000 and 
SMTP-plus-widespread-challenge-response:

1. With SMTP-plus-widespread-challenge-response the relevant apathy is
on the parts of the senders, whereas with IM2000 it would be on the parts
of the recipients.  

2. With IM2000 it's possible to employ halfway-house mechanisms to help
make change more gradual, if required.

And, on the gripping hand, you are presuming that there would be a large
level of apathy.  As I said in a submission that hasn't (yet) made it to
the RISKS digest, people are not as conservative on this issue as some 
think.  The evidence of history is that people _do_ change mail systems.
They've changed several times over the past few decades.

And given the fact that people see and are happy to countenance the massive 
architectural changes that SPF would engender - which are, ironically, 
larger than those of IM2000 - I suspect that there's quite a lot of
eagerness to accept architecural changes now.

%%> Whilst I sympathise with those whose email addresses are spoofed 
%%> in spam, it has to be said I'd rather know and be deluged, than have 
%%> a deluge of spam go out in my name. 

What has that to do with anything that we've discussed ?

%%> If you get 10,000 C/R requests one morning (and you don't run a C/R 
%%> system that deletes those which aren't genuine), you hit "shift-delete" 
%%> and carry on.

Come now!  That's just the daft "just hit delete" argument in a subtle
guise.  Moreover: When you are reading the discussions about SPF on the 
"qmail" mailing list that I pointed you towards before, read the discussion 
therein of the attack bandwidth amplification mechanism that 
challenge-response creates.