
shanew at shanew
Feb 8, 2010, 2:05 PM
Post #5 of 5
(644 views)
Permalink
|
|
Re: spamass-milter -r doesn't work for me
[In reply to]
|
|
On Mon, 8 Feb 2010, Andreas Haumer wrote: > Hi! > > Am 08.02.2010 21:47, schrieb Shane Williams: >> I think you're both misunderstanding what the -b option does, and >> reading the man page, I can see how it could be more explicit. >> >> In any case, the -b option is used to send rejected mail to a >> specified email address (in case you want to inspect it). Someone can > > As I understand the manual page, the "-b" option is not about > rejected mails but about tagged mails. > > Tagged mails usually are a superset of rejected mails (i.e. > if the "reject" score is larger than the "tag" score) > A rejected mail will always be a tagged mail, but a tagged > mail not necessarily is a rejected mail. My interpretation of the -b option is based on previous usage of it. I agree that what the man page says it does is completely different, and someone should change the way that's written. > So the question is (logically): should the handling of the "-b" option > include the whole set of tagged mails or the set of tagged mails minus > the set of rejected mails? > > I (and I guess Christoph, too) want the "-b" option only to handle > the set of tagged mails reduced by the set of rejected mails but it > looks like it currently applies to the whole set of tagged mails. > The "reject" thing currently is just an additional feature, independent > of the "redirect" feature. I would say there's a need for both. I found the -b option useful when I first turned it on and wanted to make sure spamass-milter was behaving as expected without the risk of losing legitimate mail. I can also see a use for the feature you and Christoph are after, but I wouldn't over-ride the existing behavior. >> correct me if I'm wrong, but I think what you're looking to do can't >> be done in spamass-milter. I would recommend a procmail recipe to do >> that instead. > > Hm, I don't really like the procmail approach. It would add > an additional component in the chain. I'd rather rely on the > sendmail & milter components. What you're wanting doesn't have to occur at transaction time, and so probably shouldn't, IMHO. Procmail (or perhaps something else like MailScanner) would be the next logical place in the mail-processing chain to handle these, which is why I suggested it. At it's simplest, I think it looks like this (not tested). :0c * ^X-Spam-Status: Yes, feedmespam [at] wherever But, to each his own :-) -- Public key #7BBC68D9 at | Shane Williams http://pgp.mit.edu/ | System Admin - UT iSchool =----------------------------------+------------------------------- All syllogisms contain three lines | shanew [at] shanew Therefore this is not a syllogism | www.ischool.utexas.edu/~shanew
|