Re: State of art

Brian Candler wrote:
> OK, a bit more googling around and I found www.im2000.org (it wasn't linked
> from DJB's original paper) and from there
> http://homepages.tesco.net./~J.deBoynePollard/Proposals/IM2000/


> Does this mean that there are essentially two different types of message
> store account, those intended for personal use and those intended for lists
> (perhaps set by some sort of flag?)

Even so. And yes, these do look a lot like USENET groups, but I
will observe one major difference: there is no central list of im2k
groups, as there is in USENET. A porn spammer can't get a list of
groups matching '*sex*' and start spamming to alt.lawns.grassexperts;
he has to discover the group. This is (a bit) harder than discovering
mail addresses. Also, there is no store-and-forward; a spammer is not
despoiling a commons; he is attacking a private resource, so different
responses become available.

I see three broad classes of im2k groups:

  Perfectly open. Anyone can post or read. Yep, those will get
  filled with spam, no way out of it. A list owner can implement
  cancelling anyway they please; that's outside the scope of the
  protocol. This is a public USENET group. (public cancels were
  never part of the NNTP protocol)

  Perfectly private. Login required to post, login required to read.
  This is a closed mailing list; the difference being that one polls
  it when one is interested, rather than having messaged delivered
  to you.

  Publically readable. Anyone can read, login required to post.
  This looks like an announce list; or a blog; or a moderated list
  (where messages for moderation enter out of band); or an audience
  watching a round-table discussion.

  (the fourth sort, anyone can post, login required to read, is a
  plain old mailbox)

> Is there never any case where a user can post a message via their own local
> message store? (e.g. by sending a mail via their own message store to
> "[email protected]"; the mailing list server receives a
> notification, collects the message, and puts it in its own message store for
> public consumption)

Of course there is; but that happens outside of this protocol.

> - you must get an account (username/password) on the mailing list message
>   store before you're allowed to post, which forces you to go through some
>   sort of registration procedure, and store the username/password on your
>   client. That just makes life harder for people who want to join lists,
>   although an easy hurdle for mailing list spammers to overcome.

That's called subscription; you have to do that for mailing lists
now. And I don't see why telling your mail client
'username:password:[email protected]' is harder than telling it '[email protected]'


> So: how, exactly, is life made harder for spammers, and easier for
> legitimate users?

Essentially, in that a spammer has to have a message store and bandwidth.

   If he keeps it himself, he will quickly find it balcklisted
   If he gets it through a responsible ISP, they will can his account when 
     they discover him to be a spammer
   If he gets it through an irresponsible ISP, the ISP will find itself
     blacklisted, and feel pressure to can his account.

Is this a hardship? It's based on the assumption that the cost of
people retrieving spam is significant. If I send out ten million
notifications, do I get ten million hits? That would make spam less
cost-efficient. Will I get a million hits? A thousand? Ten? This
statistic is what would make the difference.

> (c) OK, so my own message store is blacklisted, and I can't use my ISP's
> mailstore because my user ID is blacklisted. So, now I go to my network of
> 0wned zombie machines. I install message stores on all of those, and I send
> notifications from them.

OK, you can send notifications from your zombies to your heart's
content. But your message only gets to people if that particular
zombie is up and able to serve it if, as, and when they request it.
(again, I need some statistics here)

The real mechanism here is that notifications distinguish between
mail stores identified with IP addresses, and stores distinguished
with domain names. My software has an easy policy:

  whitelist for IP addresses. Only go to mail stores identified by
  IP addresses if I have a previous arrangement with them (id est,
  they're a mailing list or something I care about)

  blacklist for domain names. Only someone who can publish a SRV
  record for a domain can set up a message store for that domain;
  now I can distinguish good domain from bad domains, as we've
  discussed.


> So to me, the 'brave new world' of IM2000 doesn't look all that much rosier
> than we have today. Have I missed something?

Aside from those things based on statistical notions:

Forging mail become harder. I know where the notification comes
from, and I know where the mail store holding the mail is.

The spammer bears more of the cost of sending mail. An ISP cna
charge a spammer for bandwidth to their message store. This, it is
hoped moves us towards a postal-mail model, where senders of junk
mail actually pay their costs and help support the email systems,
rather than just leeching off it.

All this is the theory; I haven't yet decided whether I believe in it.

> http://homepages.tesco.net./~J.deBoynePollard/contacting-the-author.html#IM2000
> I'd like to send a mail to the author using IM2000, but in order to do so I
> need to have a copy of the technical specs. Do any exist yet?

They're there, but there are gaps:

 <http://homepages.tesco.net./~J.deBoynePollard/Proposals/IM2000/Architecture/>

Short form: use BER to deliver objects, defined in asp1 in those
articles.  No one is answering questions about them, so either the
issue is dead, or this list is a red herring,
	
	Erich