On Tue, 2009-04-28 at 13:32 -0500, Robert Ober wrote:
> On 4/28/09 11:34 AM, Karsten Bräckelmann wrote:
>
> >> DROPPRIVS=yes
> >
> > procmail is being run on behalf of the recipient.
>
> Makes sense, any way to make sure the log is writeable other that to
> put all the users in a group?
Ah, just answered the same question at the very end. ;)
> >> LOGFILE=/var/log/procmail.log
> >> VERBOSE=yes
> >> LOGABSTRACT=all
> >
> > MAILDIR is not set, so it defaults to $HOME.
>
> How does this apply for doing Spamassassin globally?
It doesn't. I mentioned it to point out where mail will be delivered to
by procmail. Or rather would, if the $HOME would exist...
However, there *is* a point here that matters to SA. It's not the
delivering, which is important only to your IMAP server, or whatever
else you plan to access the "spam" folders procmail delivers to.
The point that matters to SA is the existence of a $HOME. Since you told
procmail to drop privs, and do the filtering on behalf of the recipient
user, spamc will be invoked as that user, too -- and spamd will attempt
to access per-user configs, and maybe even attempt to create it.
How exactly did you do the SA filtering before?
Site-wide config and dedicated SA or mail processing user? Are these
email users real system users, or virtual? Sounds like you have been
using some site-wide setup before -- and now you just switched to a
per-user config. Do you really want that?
> > Does your "main offsite user" even have a $HOME? What user is this being
> > run as? Check its home...
>
> Yes, but all mail goes to /var/spool/mail. Each user has a file there
> under their name.
So? See my post again, about the setting of MAILDIR and where procmail
will deliver according to your recipes. Which, BTW, does not impact the
default folder, when procmail reaches the end of the recipes. It most
likely will be the same as it currently is -- given you're doing
*per-user* processing with procmail...
Which might not be what you want to switch to. Humm...
Site-wide SA integration with procmail using a single, side-wide
quarantine folder. Anyone? :)
Did you check the SA site and wiki for some hints?
> >> SPAMFOLDER=spam
> >> :0:
> >> * ^X-Spam-Level: \*\*\*\*\*\*\*\*\*\*\*\*\*\*\*
> >> #/dev/null
> >> almost-certainly-spam
> >
> > This would deliver in *mbox* format into $MAILDIR/almost-certainly-spam
> >
> >> :0 w :$SPAMFOLDER/.lock
That lock file likely isn't writable either.
> >> * ^X-Spam-Status: Yes
> >> $SPAMFOLDER/.
> >
> > Here you specify *MH* format, delivering into $MAILDIR/spam/
>
> Well I just copied from an article. How do I change it for mbox?
You'd better carefully review the source you copy from. That's quite a
gross mis-configuration. Oh, and also carefully check if the source
actually applies to your case.
As for changing to mbox, see man procmailrc, last paragraph of the
section "Recipe action line". Spoiler: mbox format will be used if you
specify a regular *file*, that's no / or /. suffix.
> >> No spam is going to the spam file in /var/spool/mail although the main
> >> offsite user did have a .lock . I even dropped the level from 8 to 5 .
> >> The main offsite user is being flooded and sees all the spam on his
> >> phone. I even rebooted the server (Fedora Linux Core 6) last night.
> >> Also, what ownership should the logfile(procmail.log) have? I did 660
> >> and tried mail.mail and it still complains in the maillog that it cannot
> >> write to the logfile.
> >
> > procmail is not being run as user mail. See DROPPRIVS in man procmailrc.
>
> Will do.
>
> > You should sort out *where* to deliver, and what *format* to use. Also
> > it seems the user procmail runs as is not allowed to write to the
> > delivery destinations -- and/or does not have a $HOME.
>
> Sendmail with mbox. As I stated, it was working just for rewritting the
Well, *how* was it working before? How did you integrate SA? (see above)
> subject. How do I set procmail to run as mail or whatever. This is
> unclear to me. I want this to work globally, all spam to the same file.
Hmm, never done such a stunt, but this *could* work. NOTE: I did NOT
try it, use on your own risk!
In the global procmailrc file, first do the filtering through spamc/d,
deliver spam to dedicated, system mbox files -- and then set DROPPRIVS
for default mail spool delivery.
Again, this is untested!
And I really don't like the idea of a global quarantine anyway, possibly
containing sensitive and private data. Who will review the spam !?
> > You will see the failed delivery attempts and falling through to the
> > next recipe / default mailbox in the procmail logs, once they are
> > writable...
>
> Still do not understand how to do that.
Add the user to the group? Or even make it world-writable, just for
debugging purposes. But without a log, you're stabbing in the dark.
Procmail can't even complain to you, which it would loudly.
--
char *t="\10pse\0r\0dtu...@ghno\x4e\xc8\x79\xf4\xab\x51\x8a\x10\xf4\xf4\xc4";
main(){ char h,m=h=*t++,*x=t+2*h,c,i,l=*x,s=0; for (i=0;i<l;i++){ i%8? c<<=1:
(c=*++x); c&128 && (s+=h); if (!(h>>=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}
