At 10:40 2006-11-30 +0000, CosmicPerl.com Support wrote:
Hi,
Procmail is what I've posted. Nothing special is setup in Sendmail. Would
you like to see my M4 file?
No.
When the lines:-
:0:
* ^X-Spam-Level: \*\*\*\*\*\*\*\*\*\*\*\*\*\*\*
/dev/null
#almost-certainly-spam
Were like:-
:0:
* ^X-Spam-Level: \*\*\*\*\*\*\*\*\*\*\*\*\*\*\*
almost-certainly-spam
Those emails were still ending up in the users inbox as well as
almost-certainly-spam.
Some questions to ask yourself (you don't need to answer them for me,
because I'm a technopsychic and already know the answers):
Q: have you used LOGGING to see what is happening? If so, what does the
log say? If not, well, what the hell are you thinking?
Q2: might there have been permissions issues with almost-certainly-spam,
causing procmail to be unable to write to the file, and thus treat the
message as undelivered by that recipe?
Here's the lowdown:
In your original post on this thread, you posted an rcfile. Didn't happen
to mention that it was /etc/procmailrc (i.e. GLOBAL procmailrc), just that
it was the content of your procmailrc (which if your user procmailrc,
would have properly been .procmailrc). Let's look at that GLOBAL
procmailrc shall we?
DROPPRIVS=yes
drop elevated privs and become the user this message is being delivered for.
MAILDIR=/var/spool/mail
Set pwd (mailboxes and INCLUDERC files).
Set pwd (for mailboxes and INCLUDERC files). Note that this means when you
go to write your almost-certainly-spam message, it'll be writing to a
directory which shouldn't be world writeable. Joe schmuck user shouldn't
have privs to write to a file there, and if they did, certainly shouldn't
be able to write to it if while messages were delivered to Annie Schmuck
the file was created by (and thus owned by) her.
:0fw: spamassassin.lock
* < 256000
| spamc
No problem here.
:0:
* ^X-Spam-Level: \*\*\*\*\*\*\*\*\*\*\*\*\*\*\*
/dev/null
#almost-certainly-spam
/dev/null is world writeable. almost-certainly-spam almost certainly
isn't. Note that if you used a LOG, you'd have seen the delivery failure
message which procmail would have emitted.
:0:
* ^X-Spam-Status: Yes
probably-spam
This delivery has the same problems as almost-certainly-spam would have as
well. I didn't see you reporting it was wonky.
Quick fix: move DROPPRIVS=YES to AFTER all the spam filing. Alternatively
(and not really a good idea) would be to check for the presence of these
mailboxes, and if they don't exist, create them and set permissions,
including world writeability, then let the recipes run. You could also
consider putting the mailboxes elsewhere - why put them in the spool
directory if there isn't a user account that can log in and retrieve them?
Your account balance: 6 pints of dark ale.
---
Sean B. Straw / Professional Software Engineering
Procmail disclaimer: <http://www.professional.org/procmail/disclaimer.html>
Please DO NOT carbon me on list replies. I'll get my copy from the list.
____________________________________________________________
procmail mailing list Procmail homepage: http://www.procmail.org/
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail