(subject changed back to what the topic subject was, rather than the DIGEST
you most recently replied to)
At 08:40 2007-08-15 -0500, Skip Brott wrote:
The mailbox does exist and has the proper ownership.
Then you need to focus on the POP3 interface, and check your logs for what
the error is when you connect via POP3. I suspect the ownership _looks_
okay, but really is not.
I suspect the issue is that I need to forward the message rather than dump
it directly into the mailbox. (The account set up to pull spam
successfully checks its email but always returns no messages).
Like, it's really checking a different mailbox name than you're writing to.
So rather than use:
/var/spool/mail/spamaccount
Should it be?:
| formail -A "X-Spam-Status: Yes" | spamaccount
This would pipe the message from into formail and then into a program
called spamaccount. To forward, as an action, you either:
! spamaccount
or, since you're trying to use a pipeline:
|formail -A "X-Spam-Status: Yes" | "$SENDMAIL" $SENDMAILFLAGS spamaccount
(this invocation of sendmail should directly mimic what the '!' does,
though the flags generally aren't necessary, and quoting of the sendmail
invocation shouldn't be either)
Some notes:
* $SENDMAIL is a procmail variable, and contains the submission
program the procmail build determined your MTA uses. Pretty much all *nix
MTAs have a sendmail stub though.
* if you just scanned the message and SA added the header in
question, why use formail to add it again? i.e. excepting for possibly
adding a loop header, you really don't need the formail invocation and
could just use the simple forward syntax.
* loop and bounce handling are both potential problems. If
delivery to the spamaccount fails for some reason (mailbox over quota, some
temporary permissions issue, etc), the mail could go back to the original
sender...
I am unclear about how to forward the message without having it rescan the
message.
Near the top of your /etc/procmailrc, add:
:0
* $ LOGNAME ?? ^^spamaccount^^
{
# if so, drop elevated privledges and deliver the message,
# this particular method allows for the spamaccount to possibly
# have it's own procmailrc, but if not, mail will be delivered to
# it's default destination.
DROPPRIVS=YES
SWITCHRC=
}
# SA invocation and forwarding happens after here
that IS a space between the $ and LOGNAME, not a typo.
The username which the current message is being delivered on behalf of is
checked against the spamaccount username (NOT the address, but the local
username), and if it is a match, the message is handled without running SA
or trying to forward it again.
You COULD use the $LOGNAME variable to pull up some user-specific options
from a file, and determine if spam should just be ditched, forwarded to the
user marked as spam, forwarded to a separate user-specific account, or
forwarded to you for coddling.
get thru). I quickly run thru all these messages to verify no FPs. They
are about 1 every few thousand,
Which sounds like you're doing a lot of extra work to check other peoples
email for them. If instead, you deposited each users spam mail in an
account which THEY could access (perhaps even a $LOGNAME-spam sort of
second account), then those users could rummage when THEY believe they have
a message which may have been misfiled.
"Hey Skip, could you check the spam mailbox for me - my mistress sent me
some risque' pictures of herself, and I haven't received them...."
If you have a webmail interface available to your users, then they don't
need to configure their MUAs to access the spam box - they can just log
into the website and access either their regular mailbox (as they would if
travelling without their own computer), or THEIR spam one.
That offloads the responsibility to the user, saving you time and hassle,
not to mention keeping each users mail private. Then, all you really need
to do is have some cron process in place to trim the spam mailboxes
periodically so that they don't get huge just because some users don't
manage them.
Besides, why should YOU suffer extra workload when some nimrod user does
something stupid and gets their email address plastered all over the place
- forcing you to review more spam to make sure that none of their
legitimate mail is being misfiled?
---
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