Re: SPF is harmful. Adopt it.

>James Craig Burley <[email protected]> wrote:
>> ...how does Joe User know that the email he receives (and pays for
>> receiving) is advertising a spammer's web page, unless he first "pulls" that
>> email via IM2000?
>
>The user (or, more specifically, his IM2000 MUA) already knows that the
>waiting message is from someone he does not normally correspond with (it
>refers to a message store he's never heard of before).  His MUA will retrieve
>the "summary only" infomation from the message store (basically From:, To:,
>Subject:, Message-ID:, and References: headers) and use that information to
>prompt him "Do you want to retrieve this message?"
>
>The user will think "Hmmm, I don't know
>'<[email protected]>', and the subject 'need herbal
>viagra?' looks spammy to me.  I'll click 'Never retrieve messages from this
>sender'".  If he blocks a couple of senders on the same mailstore in this
>manner, his MUA might ask him "This mail store looks spammy; you've blocked X
>senders on it, and don't have any regular correspondents there.  Would you
>like to ignore all further notifications regarding messages on this mail
>store?".

That's a much more "intimate" exchange between a user and his MUA than
I believe most people are accustomed to, since it implies interrupting
a user's typical progression through incoming email.

Certainly it seems very different than what *I* am used to, and I
can't see how it can be usefully adapted to *that*.  (See my other
message, the part where I describe how I use Emacs "rmail" mode.)

>> And if he *has* to "pull" that email first, doesn't that defeat the
>> One Big Advantage of IM2000 over SMTP?
>
>He doesn't pull the message.  That's the point, and the source of your
>confusion.

If he doesn't pull the message, he can't *know* that it's spam or
vermin.

You can bias the test all you want as in your paragraph above, but
given "From: <[email protected]>", "To: <[email protected]>",
and "Subject: Important IM2000 Decisions To Be Made", how would *you*
know it was spam or vermin, if you'd rarely or never heard from the
outgoing message store before?

And that's a fairly *easy* forgery for UBM senders to pull off.

>> Now, if he can precisely identify the source of such spam and tell his
>> system to no longer accept message notifications pertaining to that
>> source, or to mark them as "likely spam" before he's likely to "pull"
>> the corresponding messages, he'll save himself the trouble.
>
>Yes, exactly.
>
>> But if he can do *that*, under an IM2000 regime, why can't he do that
>> *today*, under the SMTP regime, via blacklisting sources of unwanted
>> SMTP email?
>
>That's the other difference.  The spammer today merely has to move his zombie
>SMTP clients around a bit, which is easy.  With IM2000, he has to keep moving
>his mailstore and associated services around, and get them advertised via DNS,
>and worry about ostracism from clients, and [...].  Really, please read
>Jonathon's use cases, as they do a better job of explaining this than I care
>to write up here.

Yes, that all makes sense.  It also suggests that *sending* IM2000
email will become more expensive for *everybody*, because the outgoing
mail store represents a new, and substantial, point of failure: it has
to be online and available all the time from "everywhere", it has to
be kept "pure" enough, so spam and vermin don't infest it to the point
where it starts getting rejected, and so on.

Again, IM2000 is better in some respects, but just not better enough
of a protocol to justify deploying given that we already *have* SMTP
and similar means (ostracism of SMTP client IP addresses, for example)
to combat UBM.

(All IMO, of course.)

-- 
James Craig Burley
Software Craftsperson
<http://www.jcb-sc.com>