From: "Mark Williams" <[EMAIL PROTECTED]>
On 7/21/05, Kai Schaetzl <[EMAIL PROTECTED]> wrote:
>
> Mark Williams wrote on Thu, 21 Jul 2005 17:49:04 +0100:
>
> > The issue is how I get
> > procmail to put SPAM mail in $HOME/mail/spam for each of the users.
>
> That should be explained in the spamassassin install readme, I'm sure.
> Apart from that:
>
>
http://wiki.apache.org/spamassassin/FindPage?action=fullsearch&titlesearch=1&value=procmail
Tried this but it does not work. although spamassassin recognises the spam
when I send spam in using GTUBE it doesn;t put in the desired folder - says
the folder does not exist; that;s because it's not a folder - it's a file it
needs to go to. Any ideas?
<< First a basic assumption here - you say "folder". That is Windows-speak.
<< I am making the natural assumption....
<< Does a "$HOME/mail" directory exist? Are you sure it needs to be a
<< file that it needs to go to? If some of the system is in mbox format
<< (file) and some in mailbox format (direcotry) then you will tend to
<< get all tangled up. If your system is not usin mbox format you
<< may want to create the spam "folder".
<< Of course, with proper spam markup tools like Outlook Express and even
<< Outlook can sort into folders. I use a rule which gives markups like:
<< "Subject: *****SPAM***** 062.0 ** Your account #388Z7342"
<< The three digit number markup allows me to sort into a spam folder on
<< the "*****SPAM*****" part. Then once in that folder in Outlook Express
<< I can sort by subject. I look at the lower scoring spams and pretty
<< much ignore the higher scoring ones. This avoids having to have
<< procmail toss them into a folder and the mail program access via two
<< accounts. (POP3 does not understand folders at all.) You should not
<< have to log into Linux and use pine when you can sort in your usual
<< email program quite nicely and find any mismarked ham before discarding
<< the lot.
<< If their contention is that they want to look at all spam with a text
<< only browser then they are starting off on the wrong foot. There is
<< the presumption that all potentially damaging email will be caught
<< and filtered. This is provably a state you cannot ever achieve. Some
<< spam will always escape the filters unless you mark everything as
<< spam. It's a matter of statistical distributions.
<< Like I say, ask them what they really want to accomplish and why
<< they are placing constraings on proper design processes. "I am having
<< problems putting it all together securely, safely, and effectively. I
<< need to discuss it with you in a little more detail. I am sure you
<< have reasons for design constraints you have placed. I would like to
<< understand and discuss them and their ramifications with you," should
<< be a reasonable approach. Of course, be sure to be ready to discuss
<< some of the problems and false sense of security issues their
<< constraints might leave them with. And above all be polite and do not
<< confront. Ask advice and explain the problems you have with that
<< advice. Then map out some solutions, be prepared to discuss the problems
<< such as convenience and false sense of security for each of these
<< solutions. It will lead to a solution that will please both them and
<< you as being the best possible under the circumstances.
<< But first let's discover whether your system is really mbox or
<< mailbox format oriented. Procmail senses this and uses the appropriate
<< format. That's why I suspect you have a problem right at the batter's
<< box before you take your first swing.
{^_^}
