From: Phil Howard (no email)
Date: Mon Jul 01 2002 - 18:21:15 EDT
On Mon, Jul 01, 2002 at 06:03:42PM -0400, wrote:
| On Mon, 1 Jul 2002, Phil Howard wrote:
|
| > Obviously I've picked the wrong concept here. If "local" and
| > "virtual" can't be the same thing, I'm not sure how to get this
| > done.
|
| This is the first step, knowing what you don't know.
|
| >
| > When a very basic simple one-host setup is done, I don't have to
| > use a map which translates a username to path (file for mailbox or
| > directory for maildir). So why should it be different for virtual?
| > Oh I know, because of the traditional kludge to fake virtual that
| > originated with sendmail, where user at domain was translated to a
| > local system user. But I don't need that. If local can deliver
| > to /var/spool/mail/${user} why not allow something to deliver to
| > /var/spool/vmail/${domain}/${user}. This would be such a simple
| > concept and not need a map file (but certain you can have one that
| > can override the default for the cases where you want something
| > different done).
| >
|
| The "virtual" delivery agent is not very sophisticated. I believe that
| this is in part because most sites don't use it! It is not very useful by
| itself, and a complete POP/IMAP product (such as Cyrus or Courier) comes
| with a dedicated delivery agent.
How does a delivery agent "hook up" to Postfix? Is LMTP the only way,
or can it be a dynamic library?
What about local_recipient_maps and/or making smtpd reject unknown users
when the delivery is keeping separate users spaces for each domain (which
apparently is what is called virtual).
| > It looks like what I need to do is abandon virtualizing on this
| > server, and address how I want to set up the NEXT project. It seems
| > figuring things out is going to take more time than I thought. The
| > next project does have more time, though not enough time to develop
| > a new MTA for it. Now would it be better for me to try to figure it
| > out and have others fix my mistakes, or explain it up front and let
| > you tell me what concept in Postfix matches up to it (if any)?
| >
|
| Yes, for now it may be simplest to deliver using "local" to shell accounts
| listed in /etc/passwd. Some of us think that migrating to Courier is not
| too difficult given the availability of decent HOWTO documents, but a
| conservative step-by-step approach is wise. First get your server working,
| then teach it new tricks.
Once the server is working, it won't be changed for a while.
But, there is the next project. This is what it needs:
1. Support for many domains.
2. Support for separate user name space for each domain (except where
a domain is linked/aliased to another, then they share the user
name space).
3. NOT one giant map with every user at domain dot That will be too big to
maintain. A separate map for each domain is best.
4. Mail delivered to ${prefix}/${domain}/${user}/ in maildir format
5. If ${prefix}/${domain}/${user}/ exists, the address is valid for
delivery. If it doesn't, then the address is non-existant.
6. If ${prefix}/${domain}/${user}/.forward exists, obey it.
7. One single system user owns everything from ${prefix}/ on down.
To carry out some of these things, the thought I had was to write a new
map type handler which does a lookup for an existing directory or file.
The "name" for the map will actually be a complex specification that
tells the path, what to return if the file object does not exist, what
to return if it is a directory, and what to return if it is a file with
a special code to indicate that the file should be read and its content
be returned. Then Postfix can think it is a map, but it's just a directory.
Users will be added/deleted/changed by web CGI programs. Rebuilding a
whole map is a bad idea in this case.
-- ----------------------------------------------------------------- | Phil Howard - KA9WGN | Dallas | http://linuxhomepage.com/ | | | Texas, USA | http://phil.ipal.org/ | ----------------------------------------------------------------- - To unsubscribe, send mail to with content (not subject): unsubscribe postfix-users
|
|
|