Re: [qmailadmin] Qmailadmin & Procmail
>> I would not set up the machine the way you propose. > > Well, sometimes you gotta make do with one server =) It's basically a non-commercial operation. > > So I'll assume that it is unwise to use vpopmaild in a shared-hosting environment, and look to another solution to this challenge. Another note on this topic - there is some prior art that works with procmail and maildrop filters, though I can only speak of experience with the maildrop side. It works as a SquirrelMail plugin. http://www.squirrelmail.org/plugin_view.php?id=210 I have some local modifications as well, if you're interested. Regards, -- Dave Steinberg http://www.geekisp.com/ http://www.steinbergcomputing.com/ Regards, -- Dave Steinberg http://www.geekisp.com/ http://www.steinbergcomputing.com/
Re: [qmailadmin] Qmailadmin & Procmail
Ken Jones wrote: I would not set up the machine the way you propose. Well, sometimes you gotta make do with one server =) It's basically a non-commercial operation. So I'll assume that it is unwise to use vpopmaild in a shared-hosting environment, and look to another solution to this challenge. rick
Re: [qmailadmin] Qmailadmin & Procmail
Rick Root wrote: Ken Jones wrote: Maybe the vpopmail daemon could work for you http://www.qmailwiki.com/Vpopmaild Sorry, I meant http://www.qmailwiki.org/Vpopmaild That url isn't what you think it is... I assume you mean this: http://qmailwiki.inter7.com/Vpopmaild What you could do is run the vpopmail daemon and have the php web I take it this would be highly insecure in a shared hosting environment... being able to read/write files with vpopmail/vchkpw permissions. Ie, a user could put arbitrary code in his or her procmailrc then - even if the interface *I* developed wouldn't allow it, they could, if they had a web site on the server. build their own such interface I would not set up the machine the way you propose.
Re: [qmailadmin] Qmailadmin & Procmail
Ken Jones wrote: Maybe the vpopmail daemon could work for you http://www.qmailwiki.com/Vpopmaild That url isn't what you think it is... I assume you mean this: http://qmailwiki.inter7.com/Vpopmaild What you could do is run the vpopmail daemon and have the php web I take it this would be highly insecure in a shared hosting environment... being able to read/write files with vpopmail/vchkpw permissions. Ie, a user could put arbitrary code in his or her procmailrc then - even if the interface *I* developed wouldn't allow it, they could, if they had a web site on the server. build their own such interface Rick
Re: [qmailadmin] Qmailadmin & Procmail
Rick Root wrote: Hi, I wondered if anyone had devised a way for individual vpopmail users to manage a procmailrc file via a web-based interface. I use procmail in my vpopmail environment to drop certain messages into specific IMAP folders. But obviously it could also be useful for custom spam assassin stuff and other filtering. I could probably write something like this in Perl (although to be honest I'd probably build the interface in some other environemtn and just build a web service in perl to handle the actual file management Anyway... anyone done anything like this? Maybe the vpopmail daemon could work for you http://www.qmailwiki.com/Vpopmaild What you could do is run the vpopmail daemon and have the php web interface talk to the daemon. You can read and write files under a users Maildir directory with the correct permissions. So you could read the procmailrc file, display it in your php interface and then write changes to the disk. The two vpopmaild commands would be: read_file /full/path write_file /full/path (data lines). Ken Jones
Re: [qmailadmin] Qmailadmin & Procmail
Kyle Wheeler wrote: I did something like that. The trick is you can't just give people blank access to a procmailrc file because they can use procmail to execute arbitrary commands with vpopmail permissions. Absolutely. besides a messed up procmailrc can cause all incoming mail to be lost in the bit bucket =) The way I did it was via PHP script that uses a very simple setuid binary to fetch and save the procmailrc to and from the user's vpopmail home directory. It's not very complicated, and not very capable, but it lets users file and delete mails based on sender/destination/subject. I could probably pull that off, and do my interface in php or cfml thanks for the ideas. Rick
Re: [qmailadmin] Qmailadmin & Procmail
On Wednesday, November 2 at 07:03 PM, quoth Rick Root: I wondered if anyone had devised a way for individual vpopmail users to manage a procmailrc file via a web-based interface. I did something like that. The trick is you can't just give people blank access to a procmailrc file because they can use procmail to execute arbitrary commands with vpopmail permissions. I use procmail in my vpopmail environment to drop certain messages into specific IMAP folders. But obviously it could also be useful for custom spam assassin stuff and other filtering. I could probably write something like this in Perl (although to be honest I'd probably build the interface in some other environemtn and just build a web service in perl to handle the actual file management The way I did it was via PHP script that uses a very simple setuid binary to fetch and save the procmailrc to and from the user's vpopmail home directory. It's not very complicated, and not very capable, but it lets users file and delete mails based on sender/destination/subject. ~Kyle -- The criterion of truth is that it works even if nobody is prepared to acknowledge it. -- Ludwig von Mises pgpvZ6odGyDr8.pgp Description: PGP signature
[qmailadmin] Qmailadmin & Procmail
Hi, I wondered if anyone had devised a way for individual vpopmail users to manage a procmailrc file via a web-based interface. I use procmail in my vpopmail environment to drop certain messages into specific IMAP folders. But obviously it could also be useful for custom spam assassin stuff and other filtering. I could probably write something like this in Perl (although to be honest I'd probably build the interface in some other environemtn and just build a web service in perl to handle the actual file management Anyway... anyone done anything like this? Rick -- Internal Virus Database is out-of-date. Checked by AVG Anti-Virus. Version: 7.0.344 / Virus Database: 267.12.4/146 - Release Date: 10/21/2005
