|
Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com |
Re: The old virtual delivery feature
From: Allen (postfix
rfnj.org)
Date: Sun Feb 27 2005 - 00:02:29 CST
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
At 00:08 2/27/2005, Glenn Sieb wrote:
>Allen said the following on 2/26/2005 11:00 PM:
>
>>What makes you say that? It should work perfectly fine. I also use
>>pfadmin for my virtuals and I came up with a procmail recipe in no time
>>that would work. It simply set MAILDIR=/var/mail/vhosts/$1/$2/ and I
>>would call procmail from within main.cf via something like
>>/usr/local/bin/procmail -a $DOMAIN -a $USER.
>
>http://archives.neohapsis.com/archives/postfix/2003-09/2249.html
>
>That makes me say that :) hehe
That is because of the limitation in postfix, not procmail -- and was the
whole point to my post. I'd like to see that limitation removed. :)
The problem isn't that procmail can't handle it, but that postfix provides
no way at all to hand it off to procmail to begin with. If there were such
a method like the one I outlined, then procmail could deal with it no problem.
>Plus--um--do you have two separate /etc/procmailrc's? How do you do local
>delivery with procmail if you're doing virtual delivery with procmail too?
>Do all of your users, regardless of being local or virtual go into
>/var/mail/vhosts/$1/$2/ ?
I never did it in the past.. because postfix won't use procmail to filter
virtual mailboxes! :)
However, having two procmailrcs would work just fine. If you're using
procmail in a site-wide setting then you provide the name of the rc to load
when calling it -- via "-m <procmailrcfile>" this is documented in
procmail(1). So you could use two different (or multiple different)
procmailrc's, one for local, and one for virtual.
You could even, if you want, do something like in my scenario/layout:
"procmail -m /var/mail/$DOMAIN/$USER/procmailrc ..." if you wanted to use
it in "site wide" mode while still leaving each user free to edit their own
procmailrc file.
In short, yes, procmail can do this. The only reason you can't use
procmail to do it currently is because postfix won't allow you to. I'd
like to see that changed.
>>I'm not certain. I also use courier for my pop/imap daemon so I'll look
>>into this as well. Still, I'm a lot more familiar with procmail recipes
>>than I am with maildrop, and would like to continue using the ones I
>>already have.
>
>*nod* this is why I'd like to keep procmail for local delivery and have
>some kind of server-side filtering available for my virtual domains.
Currently I don't do any "local" delivery to answer your question
above. All my mail, even the mail for the "local" domain, is done through
pfadmin. Local delivery requires unix accounts, unix accounts with a valid
shell no less. I don't charge for services and just give email accounts
(and pfadmin domain admin status) to people I know or only
semi-know. Basically if someone asks me to host their mail, or asks for an
email address in one of my domains, and they aren't someone I know to be a
total jerk, I'll do it.
Since I don't really "know" some of these people, I do not want to create
full blown shell accounts for them.
>>I use courier, postfix, and pfadmin as well. All the "real" users
>>mailboxes are created automatically as they are supposed to be -- the
>>caveat being it doesn't happen until the first piece of mail comes in for
>>that user. So a simple workaround is to have a standard "Welcome!" type
>>message mailed out whenever a user is created. This isn't something that
>>needs done for virtual users, obviously.
>
>Actually PFadmin does send a welcome email, if you have it configured to
>do so in it's config.php.inc file.
Right, I have that disabled however. Anyway that's all it takes to get the
maildir created.
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]