[SA-exim] Documentation buglet + misc

[Marc MERLIN]

On Fri, Oct 03, 2003 at 12:07:49PM -0700, Ross Boylan wrote:
> sa-exim              3.1-2 on Debian.
> 
> 1) file:/usr/share/doc/sa-exim/sa.html refers to the readme with the URL
> file:/usr/share/doc/sa-exim/files/sa-exim-cvs/README
> 
> That doesn't work.  There may be other, similar problems.
 
Yep. The links are only meant to work on my web site. Sorry :-)
 
> 2) While I'm here, it might be nice to mention in the docs when changes
> to sa-exim.conf take effect.  It seems to be immediate.

It appears in changelog, and the top of sa-exim.conf has a version
number to reflect option changes.

> 3) It might be safer to have teergrubing off by default.

Mmmh, yeah I should comment this out in sa-exim.conf
SAteergrube: 25.0

I'll push that to CVS

> 4) In sa-exim.conf you might mention that if a value is defined
> multiply, the last value governs.

I don't understand what you mean.

> 5) You might be a bit more explicit in the same file, like this:
> # Remove or comment out the following line to enable sa-exim
> SAEximRunCond: 0

Sure, can't hurt to add.

> 6) Perhaps mention you need to have spamd going for it to work.

INSTALL:You want to run spamd as such: /usr/sbin/spamd -d -u nobody.

> Thanks for the package.

Sure thing.

On Fri, Oct 03, 2003 at 07:47:08PM -0700, Ross Boylan wrote:
> 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?
 
No. This is just a sample, given in comments.
 
> ------------------------------------------
> 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?

Yes, but the spam body won't be disabled if it's important to you
(some users don't want tagged mail that's not rejected to be passed on
with web bugs or whatever)

> --------------------------------------------------
> 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?
 
Correct.
I've slightly modified that paragraph to make this more clear.

> 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.

The mailstore you end up with is maildir compatible. I don't want to
have to support something else, but you can easily use a script to read
maildir format and spit it out any other format you want.
(you could setup courier imap to read from that directory if you wanted)

> -----------------------------------------------------------
> 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.

I guess it can work (the defaults have changed since I wrote this), but
it will probably create a preferences file whereever the homedir of your
mail user is.
I modified the paragraph to take your comment into account.

> 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

Right.

> 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.

I updated the comment to say:

# Do you want to feed SAmaxbody's worth of the message body if it is too big?
# Either, you skip messages that are too big and not scan them, or you can
# truncate the body and feed that to SA.
# Note that SA will sometimes raise the spam score if it can't parse
# the message correctly (since the end is missing, decoding will fail)
# Default is 0: do not scan messages that are too big
# (note that this is parsed as a condition)
SATruncBodyCond: 0


> 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.

Reports here are fine, that's not a problem.

Thanks for your feedback.

Marc
-- 
"A mouse is a device used to point at the xterm you want to type in" - A.S.R.
Microsoft is to operating systems & security ....
                                      .... what McDonalds is to gourmet cooking
Home page: http://marc.merlins.org/   |   Finger marc_f at merlins.org for PGP key