Re: Feedback on Hypertext Mail Protocol (a.k.a. Stub Email)

>Greg Hewgill <[email protected]> writes:
>
>> Spammers will find a way around this. For example, they could install
>> an arbitrary number of IM2000 message stores on zombie Windows
>> machines, and point junk domain names at them. Or, they could set up an
>> IM2000 server that stores a single copy of their message for all 50
>> million recipients. IM2000 shifts the burden of message storage to the
>> sender, but the sender can quite easily delegate this further to other
>> unsuspecting victims.
>
>But it means that I as the 'internet geek' can kill off a thousand zombie
>servers before 'gullible grandma spam-target' can retrieve the spam messages
>for which she's been sent a zillion notifications.  
>(Plus many ISPs block incoming and outgoing port 25 for anti-zombie purposes.)

So what happens when she clicks on a blocked message?  How long before
she realizes the message sender has been designated a spammer?  *How*
is she told this?

>Right now, the system itself bears the cost of sending.

You mean the *recipient* system, right?  (That is, some agent, like an
SMTP server running on the recipient's ISP's system.)

>Any unsecured inlet means an ISP stores spam on their server, even when the
>zombies are shutdown.

Under traditional SMTP, yes.

>If the zombies had to be online to send spam, then forcing them to change
>address or whatever would have the same effect in the end.
>Gullible Grandma wouldn't receive the spam message, and would not send money to
>the spammer.

Yes.  The best defense against that is for the recipient to never see
the spammer's message at all.

But it's not clear that can be assured by the recipient's agent *not*
looking at message content, relying *solely* on whether some entity or
entities have designated a particular message store as a source of
spam.

>Q. So what if the spam is in the subject field only?
>A. Clients should not display unretrievable messages unless asked.
>   It'll probably be a spam anyway.

Ummm...what?  How could a client display an unretreivable message
anyway?

Or, do you mean that a client shouldn't display a *notification*
without making sure the message *content* was retrievable?

Interesting idea...but wouldn't that make merely opening up your inbox
excruciatingly slow, as your client first tried contacting the message
store for each and every pending notification before showing you your
in-box full of notifications?

>The point is that IM2000 and other pull systems provide accountability.

What do you mean by "accountability"?  Certainly they give *senders*
more *control* over outgoing message content (they can change the
content in between content fetches, for example), and they give
senders more long-term responsibility for delivery.  But
accountability?

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