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,
feedmes...@wherever.net
But, to each his own :-)
--
Public key #7BBC68D9 at | Shane Williams
http://pgp.mit.edu/ | System Admin - UT iSchool
=----------------------------------+-------------------------------
All syllogisms contain three lines | sha...@shanew.net
Therefore this is not a syllogism | www.ischool.utexas.edu/~shanew
