README file for Ecartis
-----------------------------------------------------------------------
For now, this file assumes you have a modicum of unix experience, it will
get better over time.  If you have questions about getting this code set
up and installed on your machine, please feel free to subscribe to the
ecartis-support@ecartis.org (send an email to
ecartis-support-request@ecartis.org with the word 'subscribe' (no quotes) in
the subject).

Edit the top level makefile to set up configuration settings for your
machine.  I'm assuming some type of advanced makefile (ala GNU)

After editing, perform a make in the top level.  This will create the
modules and the ecartis executable.

You probably want to create a ecartis user/group so that the program runs
as an unpriveledged user.  Chmod the ecartis executable to this user and
make sure this user is a trusted user of your sendmail program.  Also make
sure all the list directories have the correct permissions and can be
read/written by the ecartis user/group.

You'll want to rename the ecartis.cfg.dist to ecartis.cfg, if this is a
first time install.  The reason for the .dist extension is to prevent a
user from accidentally unpacking over an existing installation and
destroying their previous configurations.

If you want to use the bounce-management on a nightly basis, just add
'ecartis -procbounce' to your crontab.  Similarly, if you want to ensure
the digest processing is handled at a certain time, add the command
'ecartis -procdigest' to your crontab.  Both CAN be omitted; Ecartis will
then handle it automatically when something is posted to the list after
too long has passed.  If you have virtual hosts set up, and choose to use
the -procbounce feature, you will need to set a crontab line for each
virtual host, with the appropriate -c parameter.

To make new mailing lists, you will want to run Ecartis with the -newlist
parameter.  Be sure to run Ecartis with the full path *as used by your mail
aliases*, for example:

/home/ecartis/ecartis -newlist mylist
/etc/smrsh/ecartis -newlist mylist

You can follow the instructions Ecartis will give you, and the list will be
generated for you.  Ecartis will spit back the aliases on stdout, for
sendmail-style aliases. Thus, you can do:

/home/ecartis/ecartis -newlist mylist >> ecartis.aliases

And the aliases will be in that textfile.  Once you have the aliases in a
valid alias file for your mailserver, run newaliases (or your equivalent)
and it should be ready.

If you have qmail, and use dot-qmail aliases files as opposed to
FastFoward, you can do:

/home/ecartis/ecartis -qmail -newlist mylist

Then, Ecartis will make a 'qmail-aliases' directory under the new list
directory, containing the dot-qmail files (for example .qmail-mylist,
.qmail-mylist-request, and so on).  You can copy those to the qmail
aliases directory.

If you have virtual hosts set up, you can pass in the host config file
when doing newlist:

/home/ecartis/ecartis -c virthost.cfg -newlist mylist

*IMPORTANT*
If your mail server runs smrsh (sendmail restricted shell), then you will get
errors like the following when you try to send mail to a ecartis list.

    "|/home/ecartis/ecartis -s alist"
          (expanded from: alist@some.machine.dom)

        ----- Transcript of session follows -----
    sh: ecartis not available for sendmail programs
    554 "|/home/ecartis/ecartis -s alist"... Service unavailable

If this is the case, then you need to do some additional setup.
First, find out where your mail server's smrsh directory is.   For RH 6.0,
this is /etc/smrsh.   For other OS's and MTA's this may be different.  Ask
your sysadmin (or if you are the sysadmin, ask the support people for your
OS or MTA where it is).

In that directory, create a shell script containing the following
---->8---- cut here ---->8----
#!/bin/sh
/home/ecartis/ecartis $@
----8<---- cut here ----8<----

Of course you should use /your/path/to/ecartis instead of /home/ecartis.
Then, all your Ecartis aliases should be set up as /etc/smrsh/ecartis (or
whatever the path to the wrapper is) instead of the actual Ecartis path.

This should be sufficient to make ecartis work with your MTA.

You *should* now have an operational ecartis mailing list server.

Please report any bugs to bugs@ecartis.org so that they can be fixed as
soon as possible.  Posts to this address will automatically go into the
Ecartis bug tracking system (http://bugs.ecartis.org/ecartis/).

Please also feel free to submit changes, enhancements, and ideas for
ecartis as well.  Feature requests can be mailed to bugs@ecartis.org for
addition to the 'Wishlist' section of the Ecartis database.  Please note
that it is a feature request in the message, though.  (Ideally, put
SUGGESTION: or REQUEST: at the beginning of the subject line.)

In addition to ecartis-support@ecartis.org (open subscription via
ecartis-support-request@ecartis.org), there is also be an open mailing list
for developers called ecartis-dev@ecartis.org (subscribe via
ecartis-dev-request@ecartis.org) which can be used to discuss changes and
implementations of various modules, extensions to existing modules, bug
fixes and the like.

Thank you.
Rachel Blackman  (Sparks)
Joseph Traub     (JT)

-----------------------------------------------------------------------
As the authors, we'd really like to know about any improvements, fixes,
changes and such that are made to this software so that we can incorporate
them into future versions as well as improve the software over time.

The Antispam module uses a file called 'spam-regexp' in each list's home
directory.  If you wish to maintain a 'global' spamfile (as I do on
ecartis.org), simply put spam-regexp in the ecartis root, and make
'spam-regexp' in each list directory a symlink to it.

The spam-regexp file is fairly straightforward, it's a one-per-line list
of regexp patterns.  If one is matched, it's logged to 'spammers.log' in
that list directory, and the message is discarded.  I've included my
ecartis.org spamfile as an example, spam-regexp.sample

CVS ROOT for CVS checkout is:

:pserver:anonymous@cvs.ecartis.org:/usr/cvsroot


Enjoy!

--SPL

This is a sort of rambling file, but it should get the point across.

First, you want to add the following to your ecartis.cfg:

digest-header-file = text/digest-header.txt
digest-footer-file = text/digest-footer.txt
digest-administrivia-file = digest/administrivia

These are associated with several files in the 'files' list:

>> files

[...]
digest-administrivia
          File to put in RFC1153 'Administrivia' section of digest.

digest-footer
          File to append to digest when sending it out.

digest-header
          File to prepend to digest when sending it out.

[...]

You can do 'getconf digest-footer' from within an admin wrapper to
retrieve the digest-footer file for editing, for example.

The 'NODACK' flag that was present in previous versions is no longer
present, as empty digest acking is no longer present.  Both DIGEST and
DIGEST2 still work as they did before, though.

The digest module now creates digests in a format compliant with RFC1153
specification, which means that you can create an 'adminstrivia' entry
which will be placed into the digest.  Technically, this should be used
over the digest-header and digest-footer commands, as the header and
footer are not technically allowed in RFC1153 spec.

The following new configuration variables are available for lists:

digest-transient = [yes|no]

   This means that no 'back digests' will be kept around.  Defaults to no.
   If digests are being kept around, they'll be in
   lists/<list>/digest/V<volume>/<issue>, for example:
   lists/ecartis-dev/digest/V01/0001

digest-file-size = [number]

   If this is zero, digests are handled nightly.  Otherwise, when a digest
   gets larger than this size, it's sent and a new one is started...

digest-transient-administrivia = [yes|no]

   Should the 'administrivia' file for the RFC1153 administrivia section
   be deleted after a single use?  If so, you can just use the
   administrivia file for daily announcements to your digest users.
   Otherwise, it remains there indefinitely and is reused.

digest-strip-tags = [yes|no]

   Should subject tags (if present) be stripped from the subject line of
   the digest?

digest-no-unmime = [yes|no]

   If humanize-mime is false for a given list, should the digest also
   prevent unmiming of files?  By default, if humanize-mime is off, digest
   will still unmime files.

digest-send-mode = [time|size|procdigest]

   What logic should be used when Ecartis is invoked with the -procdigest
   cmdarg?  If it is 'time', then the digest will not be sent unless
   digest-max-time has been exceeded.  If it is 'size', digests will not
   be sent unless the size has been exceeded.  If it is 'procdigest', then
   as long as there is digest data to be sent, it'll be sent.

It's worth noting that Ecartis will create a 'digest' directory under the
lists automatically, where it works with the current digest versions.
(And keeps back issues, if needed.)

Don't delete 'preamble.<x>.work' or 'digest.<x>.work', those are the work
files for the current issue. :)

You can, however, delete 'digestinfo' and 'digestinfo2' - which were from
Digest 1.0 and Digest 2.0 respectively - from the list's main directory.

Questions?  Feel free to ask! :)

There are two support mailing lists for Ecartis.  'ecartis-support' for
general support questions and answers, and 'ecartis-dev', for those who
are interested in the development aspects, and in having input in the
development process.

To subscribe to either list, send e-mail to 'ecartis@ecartis.org' with:

'subscribe <listname>' (where <listname> is ecartis-support or
ecartis-dev) as the message subject.

Both lists will give you instructions on how to use them once you join. :)

--Sparks