Re: SPF is harmful. Adopt it.

James Craig Burley <[email protected]> wrote:
> Ah, a nice meaty example indeed!  I'll contrast it with the potentials
> for existing SMTP protocol

Okay.

> >I am <[email protected]>.  I receive a notification that says, in
> >essence, "you have message ID X waiting to be picked up from server
> >foobar.example.com".
> 
> My SMTP server receives a delivery attempt.  It either temporarily rejects
> it before, or after, the DATA phase;

In either case, it has used a lot more of your resources than an IM2000
notification would have (which involves a lot less data transfer).  If you do
it after DATA it's far worse.

> >The first time this happens, I'll likely do the
> >following:
> >
> >1) Connect to the message store.
> 
> That'd be the local SMTP message store -- an important difference,
> since it means that if the remote message store was temporarily
> inaccessible, I'd be stuck (in IM2000-land, but not in SMTP-land).

It is an important difference -- but don't worry about "if the remote message
store was temporarily inaccessible".  You don't worry about it for other
protocols; IM2000 is no different.

> On the other hand, my *local* message store would have to keep track
> of delivery attempts in SMTP-land.  With IM2000, I gather, there'd be
> no such need; it's really my local MUA that would keep track of these
> (which it'd have to do to some extent anyway with SMTP improved along
> these lines).

Your IM2000 does not track this directly.  It merely asks your outgoing
message store which recipients of the message have not yet retrieved the
message.  The outgoing message store takes care of the details.

> >2) Tell it to not send me any more notifications about message X.
> 
> Part and parcel of talking to the local SMTP message store above, I
> would think.
> 
> Strictly speaking, this *request* might be *ignored* by an
> uncooperative remote message store in IM2000-land,

Yes, it might.  That means you've got a message store which is trying to abuse
you.  You then (as I said before) tell your notification agent to silently
drop all notifications regarding that message store -- and you'll never be
bothered by them again, and you don't even have to tell anyone.

This gives message store operators a /very/ strong incentive not to try to
abuse recipients.  Who wants to have everyone in the world refuse to read your
messages?

> But I'm not sure this is an important distinguishing characteristic of
> IM2000 versus SMTP's potential, so I'll just move along.

Actually, it is.  It moves control from the operator to the user.

> (And, again, this can't be done at all in IM2000-land if the remote
> message store is unavailable.  I know a message is waiting for me; I
> just can't see it.  I think that'd be very frustrating.)

Not really.  As I said, don't worry about it.  Occasionally a POP server is
unavailable; I just get messages ten minutes later.

> > If this happens more than once, I'll likely instruct my notification agent
> > to ignore notifications about messages on foobar.example.com, /regardless
> > of where the notification comes from/.
> 
> Similarly, I'd likely instruct my SMTP server to permanently reject incoming
> messages from foobar.example.com, regardless of relays through which such
> messages passed.  (Parsing "Received:" headers is a PITA, but it can be, and
> is, done.)

Totally different beast.  In SMTP, all a sender has to do is forge a different
sender address and relay through a different zombie spam relay, and you'll get
his messages again.  With IM2000, he has to set up a new outgoing mail store
(for which he pays), quite probably on a different server (because everyone
knows "message store on spammer.example.net are just spam, ignore
notifications about them).  It's not cost effective for the spammer.

> Further, the mechanisms an SMTP-based system needs to imitiate the
> above are more burdensome, from a resource-utilization point of view,
> in most cases.  (An exception: senders need not serve up message
> content in SMTP-land; they *must* do so in IM2000-land.  I'm nervous
> about requiring more widespread server deployment -- given how poor
> server deployment already is for SMTP, DNS, HTTP, and the like -- just
> to *send* messages.

I think you misunderstand; there's nothing about IM2000 that says you need to
run any kind of a server to use it.  You don't.  Joe User just buys/rents an
outgoing mail store and an incoming notification agent, possibly from
different companies, possibly the same one.  If it's Grandma Parker, it'll
just be included in her ISP's monthly fees and will be operated by her ISP,
just like her POP3 mailbox and SMTP relay server are today.

> And note that this scenario, designed to favor IM2000, assumes that
> readers of email will be willing and/or able to take some extra steps
> when it comes to reading email, such as clicking an "obtain just the
> headers" button, waiting for remote retrieval, reading what comes
> back, then clicking "obtain the whole message" button, waiting for
> remote retrieval, reading what comes back, then clicking "this is
> spam, I really didn't want to see it".

Only in a simplistic view.  Real IM2000 MUAs will take care of most of this
automatically.  Notifications about messages from known senders (my friends,
colleagues, companies I voluntarily do business with, mailing lists I'm on,
etc) will be automatically handled -- my MUA will just download the whole
message.  Notifications about messages from new senders the MUA will likely
download the summary headers automatically, the first time, and give me a
simple "Retrieve this message?" dialog.  After reading it, it'll ask me
"Always retrieve messages from this sender?" or similar.

> I'm not sure I can see how IM2000 will avoid becoming just another
> technology that is rejected by the masses for just this reason.

If the masses knew about IM2000 and understood it, they'd be screaming for it
/today/.  As it is, they're just screaming.  IM2000's time has come.

> Now, my concerns about IM2000 as an anti-UBM measure revolve primarily
> around my having been "educated" (clue-by-foured, some might say ;-)
> on the qmail list and elsewhere about the willingness and ability of
> UBM senders to work around almost anything that stands in their way.

They're "willing" because it costs them almost nothing; the costs are borne by
the recipients of their message.  Nothing you can do to SMTP changes that.
IM2000 reverses it; they bear the brunt of the costs of their messages instead
of the recipients.  That is the critical point.

Charles
-- 
-----------------------------------------------------------------------
Charles Cazabon                           <[email protected]>
GPL'ed software available at:     http://www.qcc.ca/~charlesc/software/
-----------------------------------------------------------------------