im2000 prototype, spam

1.  im2000 prototype
--------------------

taking up rickards proposal of modularizing im2000 by multi-layering,
i made this rough drawing:


----- upper level client (MUA)

----- im2000 dispatcher (ipsvd?)       \
                                        |
                                        |
----- lower level client(s)             > MTA
      (backend(s))                      |
                                        |
----- toolbox (minssl, netstring ...)  /
----- packetmaker (packit, vtun ...)


where in an ideal implementation the layers are connected by queues
without the need for connections between layers not beeing immediate
neighbors.  minssl <URL:http://www.skarnet.org/software/minssl/>,
ipsvd <URL:http://smarden.org/ipsvd/>, a netstrings implementation
has been proposed by stefan karrmann, vtun
<URL:http://vtun.sourceforge.net/>, packit is a freebsd(?) tool to
make arbitrary IP packets, originally developed for testing
firewalls, there may be a bunch of others.

issues:

- clean separation between layers?  does the dispatcher need access to
  the toolbox?
- do we need more layers for pluggable encryption?
- where do the parts (minssl, ipsvd, netstrings ...) really belong?
  these tools have not been developed for a multilayered approach to
  protocols, they are classic unix tools.  i keep thinking of them,
  because they are small, secure and very well specified, ideal for
  the unix "toolbox" approach.
- can the layers be connected by unix classic stdin, stdout and
  stderr filedescriptors?  if this could be made possible, a working
  im2000 prototype could be made by (soon) available programs of the
  "DJB"-style, the backends could even be filters (modulo buffering
  and non-blocking-I/O issues).
- how about the addition of stderrin (standard error input) to make
  stderr a mechanism to signal out-of-band?
- multichar charactersets like CJK:  are there any special
  considerations?  note that translation services might need
  recoding, which leads to
- where is MIME handled?  we have discussed this, and i think we are
  converging to simplified MIME, where byte-streams are transferred
  transparently and notifications (or user data?) just contain
  descriptions like the current Content-Type: headers,
- given the need for keyservers treated much like any other service
  type, are there specialities to be considered?

and finally, wouldn't it be funnier to turn this layering upside down
and make the im2000-dispatcher a lower layer connected to the toolbox
with backends beeing closest to the MUA?


2.  spam (more examples for connected node operation)
-----------------------------------------------------

i found the following on the net looking for ways to submit IPs
spamming me to RBL (blacklists):

Location: http://www.mail-abuse.org/rbl/candidacy.html

  Blackholing Due to Spam Support Services

  In addition to those domains which originate or relay spam,
  organizations providing spam support services are eligible for
  listing in the RBL^SM. "Spam support services" includes:

  I. providing any service which uses internet resources to
  support spamming activity, including, but not limited to:

        (i) hosting web pages which are promoted by spam;

       (ii) providing e-mail drop boxes or autoresponders
  which are promoted by spam;

       (iii) providing resources such as DNS services, banner
  ads, hit counters, script processing and form handling
  services to sites promoted by spam;

       (iv) news to mail gateways;

        (v) fax to e-mail services;

       (vi) voicemail to email services;

      (vii) providing credit card processing or other online
  payment collection services for goods and services promoted
  by spam;

     (viii) providing adult verification services to sites
  promoted by spam;

       (ix) e-mail to pager services.

  II. providing software or services for distributing spam;

  III. hosting web pages or otherwise providing connectivity to those
  who provide software or services for distributing spam;

  IV. providing software or services to acquire e-mail addresses by
  any means other than verified opt-in methods, e.g., e-mail
  appending, harvesting addresses from web pages, newsgroup articles,
  and online directories, or mining addresses using "dictionary
  attacks" or automated processes for the purpose of deriving e-mail
  addresses without the knowledge and consent of the owners of those
  e-mail addresses;

  V. providing access to, or distribution of lists of e-mail
  addresses obtained by any means other than verified opt-in.

  VI. continuing to provide service or access to customers providing
  spam support services after such activity has been brought to the
  access provider's attention.


... and:

<URL:http://groups.google.com/groups?oi=djq&selm=an_475341353>

  From: Michael Rathbun ([email protected])
  Subject: Re: PacBell Internet blacklisted by ORBS!
  Newsgroups: ba.internet, news.admin.net-abuse.email
  Date: 1999/05/07

  In <[email protected]> (news.admin.net-abuse.email)
  on Fri, 07 May 1999 20:41:35 GMT [email protected] (John Navas)
  wrote:

  [large-scale snippage]
  [even more snipping by cf]

  All vigilantes are by definition "self-appointed".  On the Internet,
  also by definition, there cannot exist any vigilantes, since there
  is no institution to provide law enforcement; law enforcement hence
  properly resides in the hands of individual proprietors, subject to
  any agreements they may have made with other proprietors.  We can't
  be vigilantes -- we're all cops.


these two arguments reminds me of a discussion a while back on this
list.  now my question: given im2000 with mandatory authentication
(for "real" im2000 messages) and publish/subscribe instead of store&
forward, we might actually further the cause of some spammers since
they can't do us any harm any more.  the reason for this thought are
quite a few spams, many of them of far-east origin, where people
offered eg. machine parts, cheap ink-cartridges for printers and the
like.  i also have a distant friend in china and another one in
indonesia.  their english isn't good, and the chinese has to use an
online translation service because he doesn't understand any english,
and i don't speak chinese.  it bothers me to note a grave language
barrier, which sometimes leads me to wonder:  given a small machine
shop in china who knows it can make some parts useful to western
companies, but doesn't have any connections, where would they go to
make their offer known?

they can go find customary channels:  import/export exchanges, fares
(if they can afford them) or pay professional spammers to pump their
offerings into millions of badly selected mailboxes.

i don't have perfect im2000 recipes ready for this situation,
ie. headers that they could use to match those accepted by american
or european importers, but with im2000 this isn't simply asking them
to prefix Subject: lines with "ADV:" or "ADULT:" or whatever.
remember:  in my proposal headers are not taken from a fixed subset,
they are more like service indicators, and we have operators.  we
could use `!' to exclude services, `?' to say "this service request
may fail or return unexpected results", `<' and '>' to compare values
(like prices or timelines) and not even the operators are more than a
recommendation, since im2000 services may pop up with new services
any day to extend the semantics of im2000 messaging.

rick: i don't yet have the perfect solution for your note on new
services beeing granted trust in the presence of stefans arguments for
optional authentication/encryption and the demand for a KISS system
(Keep It Simple, Stupid!).


  clemens

-----BEGIN PGP SIGNATURE-----

iD8DBQE+kD9FpdlrZyFBkK8RAvkRAJwJ3sNgr5bQZ0RferEmceyzgs3KyQCfSRi5
c8xce9LGArJDk56mLTn0RFw=
=NHcA
-----END PGP SIGNATURE-----