Questions about the INSTALL document

There are a few points in the install document that weren't entirely
clear to me.  Here they are, in hopes of getting of some answers and
perhaps suggesting areas for clarification.  I imagine the answers seem
quite obvious to those with more experience--in fact, I can guess many
of them.  But I'd like to double-check.

All of them  but the last concern the section CONFIGURING SPAMASSASSIN.

It opens with "For all this to work correctly, your global spamassassin
config should have:" which makes it sound as if all the changes in this
section are mandatory.  I think that's not the case.  In particular, the
comments show that use_terse_report and always_add_report are optional.


Then this puzzled me:
-------------------------------------------
# Do not rewrite the subject line with "****SPAM****" by default
rewrite_subject			0
# If you prefer, you could also use this
#rewrite_subject		1
#subject_tag			SPAM: _HITS_:
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
(I'll use --- for the start of a quote and ^^^ for the end throughout.)
Will the default rewrite break exim-sa in some way?

------------------------------------------
If you are using SA 2.50 or better, by default, you should set
report_safe			0
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Oops, I forgot to do that.  I think I understand: sa-exim without
RewriteBody just changes and the headers, which I guess it reads back
from spamc.  So I'm having SA do extra work for nothing by not having
report_safe 0, but it still works.  Right?

--------------------------------------------------
Now, if you are willing to take a small speed and I/O hit, you can now
have
sa-exim read the body back from SA, and replace the original mail with
the new
body.
You would use this if you want to set SA's report_safe to 1 or 2 (in
which case you also have to set SARewriteBody: 1 in SA-Exim's config)
Note that if you do so, unfortunately archived messages will have the
body
modified by SA. This is not very trivial to fix, so if you archive
anything,
you may not want to use SARewriteBody
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
I think I get this after a couple of readings, except for the remark
about archived messages.  Is that referring specifically to stuff saved
by SAxxxxSavCond=1?  And the rewrite is problematic because it makes it
harder to see and extract the original message?

Archiving had me thinking of my message store, which is a Cyrus IMAP
database.  I was also wondering if there was a way to deliver the
SxxxSavCond stuff to it, rather than flat files.  I'm not advocating
making that a high priority, but it's just a thought.

-----------------------------------------------------------
Important:
You want to run spamd as such: /usr/sbin/spamd -d -u nobody.
It won't work if you run spamd with -c (debian default). 
You can edit this in /etc/default/spamassassin (debian) and probably
/etc/sysconfig/spamassassin (redhat)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Hmm, I'm running with the Debian default, and things seem to be
working.  Part of this is that -d is automatically added according to
the file /etc/default/spamassassin:
------------------------------------
# See man spamd for possible options. The -d option is automatically
added.
OPTIONS="-c -m 10"
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
(it gets added in /etc/init.d/spamassassin).  It looks as if it's
running as root (!), though it hasn't created an preferences file there.

There was one area in sa-exim.conf that surprised me a bit: 
SATruncBodyCond: 0
I take it this means large messages will not be scanned at all, and
hence considered non-spam (most of my large messages are spam/viral
these days, though they are smaller than the the 250kb limit in the
default file).  Finally, the comment preceding this says "Note that SA
will sometimes score the message negatively if it can't parse....".  I
think this means that SA will give the message a *positive* score, which
has a negative interpretation.  Perhaps the phrase "sometimes raise a
message's spam score" would be clearer.

Running sa-exim 3.1-2 on Debian.

P.S. To the comment on my previous message that some of it was
Debian-specific: yes, that's true.  As far as I know, this is the place
to report such matters, as there is no sa-exim-debian list.
-- 
Ross Boylan                                      wk:  (415) 502-4031
530 Parnassus Avenue (Library) rm 115-4          [email protected]
Dept of Epidemiology and Biostatistics           fax: (415) 476-9856
University of California, San Francisco
San Francisco, CA 94143-0840                     hm:  (415) 550-1062