Carlos E. R. wrote:

...

I like to write a procmail recipe which does the following: All malware mails (tagged with header "^X-Spam-Virus: Yes") should be delivered to a specific mailbox (e.g. /home/malware/Maildir/) regardless of the recipient of the mail.

I tried this with

/etc/procmailrc # ... malware scanner etc. :0: * ^X-Spam-Virus: Yes /home/malware/Maildir/

The problem is, that all mails delivered to /home/malware/Maildir/ get uid "root" and gid "mail". I think that you have to forward to the user "malware" instead, not to

On 2016-06-01 10:33, Bjoern Voigt wrote: the folder in there:

* ^X-Spam-Virus: Yes ! malware Yes, but without the complex mail loop prevention this recipe does not work.

"! malware" sends the mail using Sendmail, Postfix etc. to local user "malware". So /etc/procmailrc is processed again (for user "malware"). The malware scanner has to run twice. This is a problem because my scanner unfortunately needs some seconds for each mail because it's not a client-user program and the program has to load all the malware definitions etc. for each mail. Also I get an endless loop. With loop prevention it will work, but it stays complex and I search a compact solution. Greetings, Björn -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Carlos E. R. wrote:

Ah, yes, you are right.

I remember a release note when SuSE switched from Sendmail to Postfix that may be relevant to this, but I don't remember the details and I failed to locate it.

I think the issue was that postfix would never run as root, so procmail failed to send mail to "root". I find references to this here: http://postfix.1071664.n5.nabble.com/Invoking-procmail-with-suid-root-tp6676...

«Postfix does not execute (mail) commands as root, period. Please follow Fedora instructions for mail configuration. // Wietse» Nice to know. But I use Sendmail as MTA. Sendmail calls Procmail. Procmail delivers mails with "deliver" from Dovecot IMAP.

This brings me to the idea, that I can write a script, which switches the UID to user "malware" with "su" or "sudo" first and then calls Dovecot's "deliver" to deliver the malware mail to user "malware". /etc/procmailrc can call this custom script. Greetings, Björn -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 06/01/2016 12:56 PM, Patrick Shanahan wrote:

* Bjoern Voigt [06-01-16 10:26]:

...

Bjoern Voigt wrote:

...

/etc/procmailrc # ... malware scanner etc.

Don't use /etc/procmailrc! To invoke procmail as <user>, make ~/.procmailrc and recipies in another file called from ~/.procmailrc

I believe this will solve your permissions problems. I use procmail and employe it that way.

+1 I do too; I use spamc for SpamAssassin that sets a flag, and have a series of scripts that determine "SPAM-ness" and process by degree[1]. I also note that the SpamAssassin package had a procmailrc file that begins ... # SpamAssassin sample procmailrc # ============================== # The following line is only used if you use a system-wide /etc/procmailrc. # See procmailrc(5) for infos on what it exactly does, the short version: # * It ensures that the correct user is passed to spamd if spamc is used # * The folders the mail is filed to later on is owned by the user, not # root. My procmailrc does some preprocessing (such as my known whitelist and know blacklist, so as relieve SpamAssassin of some load) then and only then pipes though spamc. On return I have a series of rules nested under :0 H * ^X-Spam-Flag: (YES|yes|Yes)|^X-Spam-Status: (YES|yes|Yes) You could append |^X-Spam-Virus: (YES|yes|Yes) to that. [1] This an other lists are smart in that they are plain text and don't use attachments. Not all lists are smart; some idiots still use HTML mail. Eventually I recognise them and whitelist them, but along the way I need to differentiate them from the outrageous stuff that needs to be dropped on the floor immediately. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 2016-06-01 18:56, Patrick Shanahan wrote:

* Bjoern Voigt [06-01-16 10:26]:

...

Bjoern Voigt wrote:

...

/etc/procmailrc # ... malware scanner etc.

Don't use /etc/procmailrc! To invoke procmail as <user>, make ~/.procmailrc and recipies in another file called from ~/.procmailrc

I am unable to understand this paragraph :-? Two references to "~/.procmailrc"? -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)

* Bjoern Voigt [06-01-16 10:26]:

...

Bjoern Voigt wrote:

...

/etc/procmailrc # ... malware scanner etc. Don't use /etc/procmailrc! To invoke procmail as <user>, make ~/.procmailrc and recipies in another file called from ~/.procmailrc

I believe this will solve your permissions problems. I use procmail and employe it that way. Yes, but how should the usage of ~/.procmailrc solve my specific

Patrick Shanahan wrote: permission problem? (BTW, my users have additional ~/.procmailrc files too, but I usually place recipes for all users/mailboxes in /etc/procmailrc.) I wrote:

I like to write a procmail recipe which does the following: All malware mails (tagged with header "^X-Spam-Virus: Yes") should be delivered to a specific mailbox (e.g. /home/malware/Maildir/) regardless of the recipient of the mail. The problem is, that all mails delivered to /home/malware/Maildir/ get uid "root" and gid "mail". DROPPRIVS=yes also does not work, because DROPPRIVS changes uid/gid to the recipient user and this uid/gid usually has no write permission for /home/malware/Maildir/.

Mails in /home/malware/Maildir/ should get gid/uid of user "malware".

Greetings, Björn -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org