[Date Prev][Date Next]
On 27 Feb 2000, Turbo Fredriksson wrote:
# > * Mail multi-hosting (several domains on the same phisycal machine)
# > * Each domain will have it's own user space. Each IP alias will appear as a
# > different domain on the SMTP and POP-3 port. I mean: user jdoe on
# > mail.domain1.com will be completely different to jdoe on mail.domain2.com.
# I don't know THAT much about sendmail, I find it anquard :)
You can do this quite non-sendmail specifically...
# What i use is qmail, it's quick and 'reasonable' scalable. I've seen
# tests that indicate it's not as good for GIGANTIC mail hosts (> 500k
# users), but that could be easily accomplished with a mail cluster.
I use postfix which is a great mail server, and has LDAP support
out of the box, although I've yet to do anything excessively complex with
# Specifying that 'firstname.lastname@example.org' delivers to
# '/var/spool/mail/domain/jdoe' and 'email@example.com' deliver to
# '/var/spool/mail/whatever/jdoe' is just a matter of specifying the
# correct attributes in the LDAP db (mail and mailMessageStore).
This is a function of the local delivery agent (which is
cross-mailserver portable. You can test this kinda thing on the
commandline in a standalone configuration, and you can move it from mail
server to mail server. The way I would approach this would be as follows:
Get a mail server that you can get working with LDAP usably
Build a custom delivery agent that will speak to the LDAP servers
Build a custom POP/IMAP proxy that will speak to the LDAP
servers and find the POP server for the user.
Build/modify a custom POP/IMAP server that will find the mail in
the filesystem (or wherever).
My LDAP entry, for example, might be as follows:
That should provide enough information to support delivery and
pickup in a clustered environment.
Postfix, sendmail, qmail, etc... should use the
mailacceptinggeneralid (which in the above example is used incorrectly, it
typically doesn't have an @domain in it) to find the match(es) for the
E-mail address. A match contains a maildrop that says where the mail for
the individual goes. In this example, the MTA would know that it needs to
send the mail on to cluster1.mail.spy.net for final delivery.
Once it gets there, cluster1 will know by configuration that it is
the final delivery point, and will accept that mail. At this point, it
passes on to the local delivery agent, which knows has to deliver mail for
The purpose of the proxy is so that you can have a common
front-end to the mail cluster so you don't have to configure each client
to go to the server you want. Alternatively, I've seen it done with
username.pop.spy.net, for example. This is also OK, you just have to
figure out which will work better for you. I prefer the proxy because it
makes firewall policy a lot easier to deal with.
Anyway, there are lots of ways to do this. I'm not suggesting
anyone actually do it this way, but it should get you thinking. Doing
this type of mail configuration, especially with POP, isn't terribly
complicated, I don't think. It gets a lot more complicated with IMAP,
especially with more than simple authentication.
dustin sallings The world is watching America,
http://2852210114/~dustin/ and America is watching TV.