on Mon, Sep 22, 2003 at 03:02:26PM -0600, Jason R. Mastaler ([EMAIL PROTECTED]) wrote:
> Monique Herman <[EMAIL PROTECTED]> writes:
> 
> > C-R systems, or TMDA, anyway, have the capability of incorporating
> > other spam fighting techniques quite powerfully.  I'd much rather
> > have multiple components, each doing what they do best, that can
> > interact in whichever way I find best.
> 
> Exactly.  The so called "Unix Philosophy" encourages this.

Encourages, but does not mandate.

There are systems in which the simple tool, single use, does not apply
to the system as a whole.  An example which illustrates both principles
is qmail.  As a whole, you need qmail-smtpd, qmail-inject, qmail-queue,
qmail-rspawn, qmail-lspawn, qmail-send, and qmail-clean for the system
to work.  Each component handles a single task.  The modularity supports
both security and simplicity of the software as a whole.  However the
entire system -- an email delivery and receipt system -- requires the
constiuent components.  And if you want to supply additional
functionality, you'll likely add additional components:  qlogtools,
qmail-qutoresponder, qmail-qfilter, Qmail-Scanner, qmail-vacation,
qmailanalog, djbdns, ezmlm, fastforward, getmail, etc., etc.

Why?  Email management is an inherently complex process.  You're dealing
with arbitrary, unqualified content from unknown and untrusted
individuals.  Delivery and processing rules can be complex.  Misuse or
misfunction of the email system can result in security or availability
issues for both the administrator and users of the system in question,
and any of the hundreds of millions of Net users worldwide.


There are other examples:  Debian has a set of package management tools
which consist of individual modules, but make little sense and provide
little utility offered individually.  The same could be said of RPM
management tools.  Emacs, Perl, Python, Apache, Postgres, Oracle, SAS,
and TeX/LaTeX are similarly complex tools with many components.


This goes even further:  where one set of tools is useful within
another, free software provides the capability to embed one useful tool
within another.  Python and Perl can run code in the other language.
Apache embeds Perl and Python.  LaTeX is a tool built on top of TeX.
The Debian 'alien' tool uses RPM libraries to allow conversions between
DEB, RPM, and other packaging formats.


And finally:  modern 'Nix systems provide means of specifying and
fulfilling dependencies.  If one component can be, should be, or must be
used with another, it's possible to state this relationship in DEB, RPM,
Slack, port, and other packaging formats, as well as through library
utilities provided with Perl, Python, and other systems.


Spam mitigation is not a simple processing problem, it's a systemic
issue, and requires a systemic approach.  TMDA should fit within such a
system, should specify the requirements and dependencies, and should be
configured sane by default to provide an effective, non-abusive benefit
to its users.


> Indeed, most people don't realize that TMDA can be used for many other
> things besides the challenge/response aspect.  

My current complaint is not with these aspects of TMDA.

> > I *do* choose to use C/R as a last resort, and I believe that user
> > choice is the right way to run these things.
> 
> Currently TMDA does use C/R by default

I am requesting that this be changed.

Specifically, I raised this request with the TMDA maintainer for Debian,
and was instructed by him to forward that request to the TMDA developer
and user list:

  http://lists.debian.org/debian-devel/2003/debian-devel-200308/msg03787.html   

I'd also formally request that TMDA *not* issue challenges unless it is
being used in conjunction with virus and spam detection software.



Peace.

-- 
Karsten M. Self <[EMAIL PROTECTED]>        http://kmself.home.netcom.com/
 What Part of "Gestalt" don't you understand?
    Defeat EU Software Patents!                         http://swpat.ffii.org/

Attachment: signature.asc
Description: Digital signature

_____________________________________________
tmda-users mailing list ([EMAIL PROTECTED])
http://tmda.net/lists/listinfo/tmda-users

Reply via email to