At 22:06 2004-05-11 +0200, Oliver Thiele wrote:
Thanks for your answer, but I'm having problem with some explanations. For
easier understanding I put some logging below.
Every user has his own .procmailrc. Here is the interesting part:
INCLUDERC=${SBDIR}/sb.rc
###### Virus #####
:0bfi
* ^(X-SBCLASS: Virus|X-Virus-Status: Yes)
| /usr/bin/head -n 0 && echo "Mail body was deleted because of a virus"
:0:
* ^(X-SBCLASS: Virus|X-Virus-Status: Yes)
| ${FORMAIL} -A"X-Folder: Virus" >>${VIRUSFOLDER}
FYI, rather than using the EXACT SAME CONDITION in a following recipe, you
can use:
:0a:
| ${FORMAIL} -A"X-Folder: Virus" >>${VIRUSFOLDER}
You're also bodging something BIGTIME: you're discarding the body, but the
HEADERS of that message still contain MIME information - including the
content-boundary, which is what a mail reader will use to define where the
mime parts start and end. No surprise you _think_ there's no body.
You're certainly NOT using the code I posted, which would have taken the
original headers and made them the new BODY of a message, generating a
completely new header.
It'd be a good idea to actually view the generated message with a file
viewer (or pager, such as less), rather than from within your email client
which is no doubt interpreting the bogus MIME headers...
What happens when the recipe appears not to work?
Sorry, I just don' t know. I guess if the recipient doesn' t exist the
mail won' t be delivered to a specific user. And because of not having a
general /etc/procmailrc this won' t happen..
Uh, lemme rephrase that - you're reporting that there's a problem, but not
actually reporting what the message ACTUALLY contains when it "doesn't
work" as you expect it to. You said "empty mail", but what is that exactly
- intact headers but no body? No headers whatsoever? Rewritten headers,
but no body? After seeing your recipes above (which are most certainly NOT
the same as the recipes you excerpted earlier), I can see why you're having
trouble.
What do you mean with an inoperable SHELL ? The users / recipients are
just normal users on the system and they catch their mail with IMAP on
their windows clients.
... In which case, in a secure environment, many of them might not actually
have permissions to shell into the host (to log in and run unix commands in
a SHELL). A user that has a shell like "/bin/ftponly" or somesuch that
just reports "you have no permission to log in" isn't going to be able to
run commands requiring a shell operation (such as pipelining) from a
.procmailrc unless a functioning shell is defined in the .procmailrc file
-- that includes the /etc/procmailrc.
Sorry, but that part is heavy for me. How can I define a temporary shell ?
Please refer to "man procmailrc"
However, my original comments on SHELL pertained to the (incorrect) data
provided in your previous message. Your real problem is that you're
retaining the original message headers and you're not viewing the mailbox
outside of a mail client, which would permit you to see that in fact the
text IS stuffed in there, but you're doing it wrong.
I think every user has his own working and defined shell and is able to
execute commands. Overall, is it necessary to reset the shell when every
user has his own procmailrc file?
Setting a known shell for /etc/procmailrc is important. Is ensures that
the shell being used is one which the sysadmin knows will work for the
commands being used there, and does not rely on the user having the SAME
shell selected, or even having a valid one. If a USER is so dense as to
use shell commands from within their OWN procmailrc when they don't have a
functioning shell and aren't definining it with SHELL from within the
procmailrc file, that's THEIR problem.
Keep in mind that /etc/procmailrc is processed with elevated privledges
until it terminates or DROPPRIVS=yes is set, so fsckups caused by the admin
making poor assumptions can cause BIG problems.
If you're running ANYTHING in /etc/procmailrcs, I'd strongly advise you to
be sure it works BEFORE placing it there (using a sandbox - see my .sig),
and that you properly evaluate all the security issues introduced by the
process.
---
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(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail