From ross at biostat.ucsf.edu Fri Oct 3 13:07:49 2003 From: ross at biostat.ucsf.edu (Ross Boylan) Date: Fri Oct 3 12:08:03 2003 Subject: [SA-exim] Documentation buglet + misc Message-ID: <1065208069.1137.100.camel@iron.libaux.ucsf.edu> 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. 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. 3) It might be safer to have teergrubing off by default. 4) In sa-exim.conf you might mention that if a value is defined multiply, the last value governs. 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 6) Perhaps mention you need to have spamd going for it to work. Thanks for the package. -- Ross Boylan wk: (415) 502-4031 530 Parnassus Avenue (Library) rm 115-4 ross@biostat.ucsf.edu Dept of Epidemiology and Biostatistics fax: (415) 476-9856 University of California, San Francisco San Francisco, CA 94143-0840 hm: (415) 550-1062 From tonni at billy.demon.nl Fri Oct 3 23:16:43 2003 From: tonni at billy.demon.nl (Tony Earnshaw) Date: Fri Oct 3 13:46:03 2003 Subject: [SA-exim] Documentation buglet + misc In-Reply-To: <1065208069.1137.100.camel@iron.libaux.ucsf.edu> References: <1065208069.1137.100.camel@iron.libaux.ucsf.edu> Message-ID: <3F7DD92B.3010800@billy.demon.nl> 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. Possibly. All your suggestions are Debian-orientated though, and your complaints should be to Debian. [...] > 6) Perhaps mention you need to have spamd going for it to work. In the source code (I compile my own on Red Hat) there's an INSTALL that says this. It seems a little obvious, though. > Thanks for the package. Personally, I'd have begun with that bit. Comes over somewhat better. --Tonni -- Tony Earnshaw http://www.billy.demon.nl Mail: billy-at-billy.demon.nl From ross at biostat.ucsf.edu Fri Oct 3 20:47:08 2003 From: ross at biostat.ucsf.edu (Ross Boylan) Date: Fri Oct 3 19:47:21 2003 Subject: [SA-exim] Questions about the INSTALL document Message-ID: <1065235628.1137.147.camel@iron.libaux.ucsf.edu> 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 ross@biostat.ucsf.edu Dept of Epidemiology and Biostatistics fax: (415) 476-9856 University of California, San Francisco San Francisco, CA 94143-0840 hm: (415) 550-1062 From marc at merlins.org Tue Oct 7 21:59:58 2003 From: marc at merlins.org (Marc MERLIN) Date: Tue Oct 7 23:56:14 2003 Subject: [SA-exim] Documentation buglet + misc In-Reply-To: <1065235628.1137.147.camel@iron.libaux.ucsf.edu> <3F7DD92B.3010800@billy.demon.nl> <1065208069.1137.100.camel@iron.libaux.ucsf.edu> References: <1065235628.1137.147.camel@iron.libaux.ucsf.edu> <1065208069.1137.100.camel@iron.libaux.ucsf.edu> <3F7DD92B.3010800@billy.demon.nl> <1065208069.1137.100.camel@iron.libaux.ucsf.edu> Message-ID: <20031008035958.GB18677@merlins.org> 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@merlins.org for PGP key From marc at merlins.org Tue Oct 7 23:05:56 2003 From: marc at merlins.org (Marc MERLIN) Date: Tue Oct 7 23:56:18 2003 Subject: [SA-exim] report_safe In-Reply-To: <025001c37ced$b5c7cf10$0164a8c0@datenbert> References: <025001c37ced$b5c7cf10$0164a8c0@datenbert> Message-ID: <20031008050556.GF18677@merlins.org> On Wed, Sep 17, 2003 at 09:31:29AM +0200, Robert Kehl wrote: > Hi all! > > I once had it, I think, but now it's gone: > > What are the correct settings to have spamassassin defang *every* spam > mail, so I can view the spam contents safely as text/plain in the body > of the mail. I think the SA folsk removed it (defang_mime) and I think it's a shame. You could use exim to remove the Content-Type header if it's marked as spam 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@merlins.org for PGP key From marc at merlins.org Tue Oct 7 22:57:23 2003 From: marc at merlins.org (Marc MERLIN) Date: Tue Oct 7 23:56:21 2003 Subject: [SA-exim] SA: Message normalization... In-Reply-To: References: Message-ID: <20031008045723.GC18677@merlins.org> On Wed, Aug 27, 2003 at 06:28:20PM -0700, Chirik wrote: > Looking at writing my own utility to collect sa-exim statistics, and going > over the message. Most of the messages were rewritten to be standard, but a > few still aren't. Just some thoughts - I could try these on my own setup, You're right, I need to fix them. > Tagged as 'Action', but doesn't include (scanned in ...): > "SA: Action: spamd took more than %d secs to run, accepting message. %s", SAtimeout, mailinfo Fixed. > Format differs slightly from the rest: > "SA: Action: flagged as Spam but accepted: Score %s (scanned in %d/%d secs | Message-Id: %s). %s", spamstatus, scantime, fulltime, safemesgid, mailinfo > > Remove the word 'Score ' from the message, so it matches the rest of the > messages: > "SA: Action: flagged as Spam but accepted: %s (scanned in %d/%d secs | Message-Id: %s). %s", spamstatus, scantime, fulltime, safemesgid, mailinfo Done. > Perhaps these two should be promoted from 'Notice' to 'Action' (if that > requires significant processing that would otherwise be skipped, then > leaving them alone makes sense) > "SA: Notice: check skipped due to message size (%d bytes) and SATruncBodyCond expanded to false", fdsize-18 > "SA: Notice: Not running SA because SAEximRunCond expanded to false" > How about: > "SA: Action: check skipped due to message size (%d bytes) and SATruncBodyCond expanded to false (scanned in 0/0 secs | Message-Id: %s)", fdsize-18, safemesgid, mailinfo > "SA: Action: Not running SA because SAEximRunCond expanded to false (scanned in 0/0 secs | Message-Id: %s). %s", safemesgid, mailinfo You could debate that one, but I initially picked "Action" for anything where spamc was run. In those two cases, it isn't, so there was no real action as far as spamc is concerned. I know what you mean though, it's the action on the message itself I went ahead and did the change, but didn't put 'scanned in 0/0 secs'. It felt silly, and it won't really help with the parsing anyway because those two lines have different fields anyway. I'll submit this to CVS tonight. Thanks 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@merlins.org for PGP key From marc at bias.com Wed Oct 8 09:08:14 2003 From: marc at bias.com (Marc Wilkinson) Date: Wed Oct 8 00:08:22 2003 Subject: [SA-exim] n00bie question regarding sa-learn Message-ID: <010501c38d6a$f10da940$6501a8c0@BBQ> Hi all, I am pleased so far with how Spamassassin with EXIM works really nice, I love the loss of all those frozen messages :) Looking a little deeper, I'd like to use the sa-learn capability to tune my spam/ham filtering. So my simple questions are; is the sa-learn DB per user? or should I do run it as the user who is running sendmail? thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.merlins.org/archives/sa-exim/attachments/20031008/aa3a7c7d/attachment.html From ssmeenk at freshdot.net Wed Oct 8 14:13:47 2003 From: ssmeenk at freshdot.net (Sander Smeenk) Date: Wed Oct 8 04:14:08 2003 Subject: [SA-exim] n00bie question regarding sa-learn In-Reply-To: <010501c38d6a$f10da940$6501a8c0@BBQ> References: <010501c38d6a$f10da940$6501a8c0@BBQ> Message-ID: <20031008111347.GA10563@freshdot.net> Quoting Marc Wilkinson (marc@bias.com): > So my simple questions are; is the sa-learn DB per user? or should I > do run it as the user who is running sendmail? With the current sa-exim implementation it's impossible to do per-user settings and/or per-user bayes databases... On my system, I configured spamc/spamd to use bayes files in a different directory, by specifying that directory in /etc/spamassassin/local.cf (debian...) and I myself have write rights on those databases, so I can sa-learn spam/ham, and exim picks it up. You have to make sure the rights on the files aren't restored to 600, so both you and the MTA have write rights. As you will understand this solution will only work on really small systems with only two or three users. Marc once sent a possible solution to implement multiple user configuration files, but afaict no-one took the job to really implement it. S. -- | I had killed a man... A man who looked like me | 1024D/08CEC94D - 34B3 3314 B146 E13C 70C8 9BDB D463 7E41 08CE C94D From ross at biostat.ucsf.edu Wed Oct 8 17:04:35 2003 From: ross at biostat.ucsf.edu (Ross Boylan) Date: Wed Oct 8 16:04:48 2003 Subject: [SA-exim] Documentation tip Message-ID: <1065654275.1446.28.camel@iron.libaux.ucsf.edu> FYI SA 2.60 deprecates an option mentioned in INSTALL for sa-exim, and suggests an alternative: always_add_report { 0 | 1 } (default: 0) When the report_safe option is turned off, mail tagged as spam will include a report in a header named X-Spam-Report. If you set always_add_report to 1, the report will also be included in the X-Spam-Report header for non-spam mail. This option is deprecated in version 2.60 and later. It will be removed in a future version. Please use the flexible add_header option instead: add_header all Report _REPORT_ -- Ross Boylan wk: (415) 502-4031 530 Parnassus Avenue (Library) rm 115-4 ross@biostat.ucsf.edu Dept of Epidemiology and Biostatistics fax: (415) 476-9856 University of California, San Francisco San Francisco, CA 94143-0840 hm: (415) 550-1062 From ross at biostat.ucsf.edu Thu Oct 9 16:54:15 2003 From: ross at biostat.ucsf.edu (Ross Boylan) Date: Thu Oct 9 15:54:29 2003 Subject: [SA-exim] INSTALL.gz minor glitch Message-ID: <1065740055.1315.4.camel@iron.libaux.ucsf.edu> The file refers to http://marc.merlins.org/linux/exim/exim4-conf/exim4.conf.master, which doesn't exist as far as I can tell. Debian 3.1-2 version of sa-exim.