| sean finney on 15 Sep 2004 13:20:03 -0000 |
|
hey stephen, On Tue, Sep 14, 2004 at 11:30:04PM -0400, Stephen Gran wrote: > I''m starting to think about setting up a database as a backend for ane > exim installation, with the idea that it would hold the information that > usually goes into sendmail's local-host-names, virtusertable, > relay-domains, and alias files. I am running into some design problems, > and Ithought I'd run it by you all to see what ideas pop up. have you looked at how it's done in postfix? i haven't ever done something like this myself, but i imagine the postfix docs would give some good insight into how they decided the best way to set it up was. i imagine that it's more or less a 1:1 relationship between aliases, virtual domains, and transport overrides and their respective tables: > Basically, I've gotten as far as something like: > > Table domains > ----------------------------------------------------------------- > | domain | local_or_relay | destination | > ----------------------------------------------------------------- > | varchar | boolean | varchar | > ----------------------------------------------------------------- > > Table users > ----------------------------------------------------------------- > | uid | alias | domain | > ----------------------------------------------------------------- > | varchar | varchar | domains.domain | > ----------------------------------------------------------------- what about something a little simpler/more discrete, like table aliases +---------+---------+ | alias | dest | +---------+---------+ | varchar | varchar | +---------+---------+ table transports +---------+----------+---------+ | domain | protocol | dest | +---------+----------+---------+ | varchar | varchar | varchar | +---------+----------+---------+ and leave it to the mailer daemon to determine whether that means a local or remote delivery should happen. whether it would be better to have only one record with a list of addresses in dest, or one row per destination i think depends on what would be easier to implement with your mta. the tricky part would be with virtual domains. in postfix, at least, there are three syntaxes: # user@domain address, address, ... # user address, address, ... # @domain address, address, ... which take precedence in about that order. i don't know if it's anything the same in exim, but if that's the case, it would probably be cleanest to just have something like: table "virtual" +---------+----------+ | pattern | dest | +---------+----------+ | varchar | varchar | +---------+----------+ where again, dest is either a list of addresses, or there's one row for each destination, depending on how the mta would prefer it. and again, it's left to the mailer dæemon to do what it should. > But this sucks. It means that multiple aliases for an address store > more than one piece of data in a field, and that's terrible. It also > means that one user can't easily be updated in several domains at once - > say joe has a joe@ address in several domains, and all his email is > forwarded elsewhere - I would have to update all of them individually if > he changes his forwarding address. A more complicated arrangement, liek if it were in "aliases": update aliases set dest='newdest' where alias='joe'; if it were "virtual" update aliases set dest='newdest' where pattern='joe@%'; (note this is assuming the 1-row setup, the multiple row setup would be a little different) > he changes his forwarding address. A more complicated arrangement, liek > joe has addresses joe@domain, joe1@domain2, and joey@domain3 would also > fail, but I'm not sure what to do with that (work by gecos? Make a uid > field? Seperate table that lists all real people, and then have a link > table link that with email addresses and aliases?) also, doesn't that make an assumption that the user has an account on the mail host? or perhaps you're trying to to something much less generic than i'm suggesting? if that's the case, you'll want a table for people, with a unique identifier as primary key that can be used as a foreign key in other tables (unless they *do* all have local accounts, in which case their uid would be fine). table people +-----------------+--------------- | person_id | user info .... +-----------------+--------------- | int primary key | +-----------------+--------------- table aliases +---------+---------+-----------------+ | alias | dest | person_id | +---------+---------+-----------------+ | varchar | varchar | int foreign key | +---------+---------+-----------------+ > In case my background and rough sketch weren't clear, I would like > to have a database structure that allows routing decisons to be made > for a given address. The mail server handles several domains, some of > which are delivered locally (usually through aliases), some of which are > forwarded offsite (again, after aliasing), and some of which have manual > routes set up. The last is for cases where this machine is the MX, > but people want the actual mail to end up somewhere else - this would > be useful to protect an exchange server from ever actually seeing the > internet directly, for example. my opinion on this is that you should leave those decisions to the mta, because it already does a fine job at making those decisions, but provide an alternate source for it to get its configuration. like i said, i've never actually done this, but i know that postfix can do this from a variety of backends, including passwd, *sql, nis, and ldap, by changing only a few lines in your config. if none of this makes sense, it's possible i just don't know enough about exim's configuration and how it would expect the sql backend to work (usually the first thing i do on a new debian box is drop exim for postfix, and even when i don't, debconf has already configured it for me, so i never see the config). sean Attachment:
signature.asc
|
|