users:werner:mailserver2
no way to compare when less than two revisions
Unterschiede
Hier werden die Unterschiede zwischen zwei Versionen angezeigt.
— | users:werner:mailserver2 [2006-02-06 1834] (aktuell) – angelegt - Externe Bearbeitung 127.0.0.1 | ||
---|---|---|---|
Zeile 1: | Zeile 1: | ||
+ | ====== Implementation ====== | ||
+ | |||
+ | This section describes how to implement a virtual mail solution. Not every little detail is covered, just what is needed above and beyond the " | ||
+ | |||
+ | ===== Prerequisites ===== | ||
+ | |||
+ | Here is the list of software, with their version numbers, that we have tested this configuration with: | ||
+ | |||
+ | Software | ||
+ | |||
+ | * Red Hat Linux 6.2, 7.1, or 7.2 | ||
+ | * Postfix 1.1.3 | ||
+ | * OpenLDAP 2.0.21 | ||
+ | * Courier-IMAP 1.4.1 | ||
+ | * Procmail v3.22 | ||
+ | |||
+ | ===== Preparing the Unix System ===== | ||
+ | |||
+ | |||
+ | To prepare the Unix system there are a few tasks you'll need to accomplish: create the vmail user and decide where you're going to store the virtual users email. | ||
+ | |||
+ | Creating the vmail user is just like creating any other system account. You'll want to have a UID and a GID that is used alone for vmail. You may also want to set its home directory to the location you've selected for the storage area of the virtual users' email. | ||
+ | |||
+ | In our system we used vmail as the user and group name. We also decided to store our virtual users email in ''/ | ||
+ | |||
+ | The following example would work on a RedHat Linux distribution and result in a vmail user being created and an empty mail storage directory being created. | ||
+ | <code bash> | ||
+ | % useradd -k -m -r -d /home/vmail vmail | ||
+ | % mkdir ~vmail/ | ||
+ | % chown vmail.vmail ~vmail/ | ||
+ | </ | ||
+ | You will also need to create an account and two groups for postfix, but that is covered in Postfix' | ||
+ | |||
+ | ===== OpenLDAP ===== | ||
+ | |||
+ | |||
+ | You do not need to follow any special instructions for compiling and installing OpenLDAP, so please consult its documentation for full instructions. For a production environment, | ||
+ | |||
+ | ==== Configuring slapd ==== | ||
+ | |||
+ | All slapd configuration is in slapd.conf. | ||
+ | |||
+ | === Adding Schemas === | ||
+ | |||
+ | You need to make Courier' | ||
+ | <code bash> | ||
+ | include | ||
+ | include | ||
+ | include | ||
+ | </ | ||
+ | === Adding a Database Definition === | ||
+ | |||
+ | Next, you need to set up a database definition. You can do this with the following lines: | ||
+ | <code bash> | ||
+ | database | ||
+ | directory | ||
+ | suffix | ||
+ | </ | ||
+ | The database directive specifies the back-end type to use. You should use LDBM as the back-end database. The directory directive specifies the path to the LDBM database. The suffix directive specifies the root suffix for this database. | ||
+ | === Creating the root User === | ||
+ | |||
+ | The next few lines set up the "super user" or " | ||
+ | <code bash> | ||
+ | rootdn | ||
+ | rootpw | ||
+ | </ | ||
+ | The rootdn entry has complete access to the database, which is why the password is stored outside the actual database. The password in rootpw should always be stored in hashed format. Do not store the password in clear text. To convert the clear text password secret to a hashed format, use the slappasswd command: | ||
+ | <code bash> | ||
+ | % slappasswd | ||
+ | New password: secret | ||
+ | Re-enter new password: secret | ||
+ | {SSHA}ra0sD47QP32ASAlaAhF8kgi+8Aflbgr7 | ||
+ | </ | ||
+ | Take the output from slappasswd, and copy that into slapd.conf, as we did above. | ||
+ | === Defining Indexes === | ||
+ | |||
+ | To speed up searches, you should create indexes for commonly searched attributes. In OpenLDAP, you can not only choose which attributes to index, but you can choose which types of searches to index on. For example, if you index the field mail, you have the option of creating indexes for presence, equality, approximate, | ||
+ | |||
+ | * Create presence and equality indexes on objectClass. | ||
+ | * Create equality and substring indexes on mail and cn. | ||
+ | |||
+ | To implement this policy, add these lines to '' | ||
+ | <code bash> | ||
+ | index | ||
+ | index | ||
+ | </ | ||
+ | === Setting up Access Control === | ||
+ | |||
+ | The last part in '' | ||
+ | |||
+ | * The user can change any of their own attributes. | ||
+ | * Anyone in the postmaster group of the domain may change any user's attributes in their domain, including the password. This allows the postmaster to reset a users password if they forget it. | ||
+ | * Anonymous (non-authenticated) users may read all information, | ||
+ | |||
+ | Access control statements are evaluated in order, so they should be defined from most specific to most general. Access to the password attribute, userPassword, | ||
+ | <code bash> | ||
+ | access to dn=" | ||
+ | attr=userPassword | ||
+ | by self write | ||
+ | by group/ | ||
+ | " | ||
+ | by anonymous auth | ||
+ | by * none | ||
+ | </ | ||
+ | The access to line specifies what entries and attributes to which the following rules apply. The dn regular expression matches any entry in a domain of our hosting tree, and attr limits these rules to the userPassword attribute. Write access is granted to the user itself and anyone in the postmaster group. Anonymous users may only access this field when trying to authenticate. For all other cases, access is denied. | ||
+ | |||
+ | Next, all other attributes to entries in a domain' | ||
+ | <code bash> | ||
+ | access to dn=" | ||
+ | by self write | ||
+ | by group/ | ||
+ | " | ||
+ | by * read | ||
+ | </ | ||
+ | This access to line is very similar the previous one, except that there is no attr specification. Hence, this matches all other attributes other than userPassword. Again, write access is granted to the user and anyone in the postmaster group. Everyone is granted read access. | ||
+ | |||
+ | Finally, we provide read access to all other elements in the database: | ||
+ | <code bash> | ||
+ | access to * | ||
+ | by * read | ||
+ | </ | ||
+ | |||
+ | ==== Creating the Directory Tree ==== | ||
+ | |||
+ | Now that slapd is configured, it's time to start adding data to the LDAP directory. We will use the command line tools that come with OpenLDAP and create LDIF files to modify the directory. | ||
+ | === Creating the Base Directory === | ||
+ | |||
+ | The first step is to create a base tree structure with our root node, the hosting organization, | ||
+ | <code bash> | ||
+ | dn: dc=myhosting, | ||
+ | objectClass: | ||
+ | |||
+ | dn: cn=Manager, dc=myhosting, | ||
+ | objectClass: | ||
+ | objectClass: | ||
+ | cn: Manager | ||
+ | |||
+ | dn: o=hosting, dc=myhosting, | ||
+ | objectClass: | ||
+ | objectClass: | ||
+ | o: hosting | ||
+ | </ | ||
+ | Now use ldapadd, binding as the root user, to add this LDIF: | ||
+ | <code bash> | ||
+ | $ ldapadd -x -D " | ||
+ | adding new entry " | ||
+ | adding new entry " | ||
+ | adding new entry " | ||
+ | </ | ||
+ | === Adding a Domain === | ||
+ | |||
+ | Domains may now be added under the hosting tree. Each domain needs to have postmaster and abuse entries at a minimum. To create a tree for domain1.example, | ||
+ | <code bash> | ||
+ | dn: o=domain1.example, | ||
+ | objectClass: | ||
+ | objectClass: | ||
+ | o: domain1.example | ||
+ | |||
+ | dn: cn=postmaster, | ||
+ | objectClass: | ||
+ | objectClass: | ||
+ | objectClass: | ||
+ | cn: postmaster | ||
+ | mail: postmaster@domain1.example | ||
+ | maildrop: postmaster | ||
+ | |||
+ | dn: mail=abuse@domain1.example, | ||
+ | | ||
+ | objectClass: | ||
+ | objectClass: | ||
+ | mail: abuse@domain1.example | ||
+ | maildrop: abuse | ||
+ | </ | ||
+ | Notice that the maildrop attributes are local email accounts and will forward to the postmaster and abuse accounts in ''/ | ||
+ | <code bash> | ||
+ | $ ldapadd -x -D " | ||
+ | -f domain1.example.ldif | ||
+ | adding new entry " | ||
+ | adding new entry " | ||
+ | </ | ||
+ | === Adding a User === | ||
+ | |||
+ | Now, let's add a user with an email < | ||
+ | <code bash> | ||
+ | dn: mail=user1@domain1.example, | ||
+ | | ||
+ | objectClass: | ||
+ | objectClass: | ||
+ | mail: user1@domain1.example | ||
+ | homeDirectory: | ||
+ | uidNumber: 101 | ||
+ | gidNumber: 101 | ||
+ | mailbox: domain1.example/ | ||
+ | |||
+ | dn: cn=postmaster, | ||
+ | changetype: modify | ||
+ | add: roleOccupant | ||
+ | roleOccupant: | ||
+ | | ||
+ | </ | ||
+ | The first section adds a new entry for the user. The home directory and mailbox point to the physical mailbox on the file system. The uidNumber and gidNumber attributes are required, but not used, so they are filled in with dummy values of 101. The second section modifies the postmaster entry by adding a roleOccupant attribute with the DN of '' | ||
+ | <code bash> | ||
+ | $ ldapadd -x -D " | ||
+ | -f user1.domain1.example.ldif | ||
+ | adding new entry " | ||
+ | modifying entry " | ||
+ | </ | ||
+ | The user does not have a password yet, so even though he has been granted postmaster privileges, he cannot be authenticated. Use the ldappasswd command to set the initial password to user1: | ||
+ | <code bash> | ||
+ | $ ldappasswd -x -D " | ||
+ | " | ||
+ | Result: Success (0) | ||
+ | </ | ||
+ | Other domains and users may be added with similar LDIF files. Creating LDIF files by hand can be cumbersome and error prone. We will talk about alternatives for administration in Section 5. | ||
+ | |||
+ | ===== Postfix ===== | ||
+ | |||
+ | We'll only cover the sections of Postfix that pertain to the mail hosting. To deal with other parts of Postfix setup, please visit the Postfix web page[14]. However, we do recommend that you set up as much of Postfix as you can to run in a chroot environment. In our experience, this means all of the Postfix daemons except pipe, local, and virtual. | ||
+ | ==== Compiling Postfix with LDAP ==== | ||
+ | |||
+ | This is covered fully in README_FILES/ | ||
+ | |||
+ | Download the Postfix source and untar it. You need to rebuild the Postfix Makefiles to be aware of LDAP and link against it. To do this, execute the following command. | ||
+ | <code bash> | ||
+ | % make makefiles CCARGS=" | ||
+ | AUXLIBS=" | ||
+ | </ | ||
+ | At this point, follow the normal Postfix compiling and installing instructions as documented in its INSTALL file. | ||
+ | |||
+ | ==== Configuring Postfix ==== | ||
+ | |||
+ | While configuring Postfix for this task, we'll be mostly concerned with ''/ | ||
+ | |||
+ | For most of the Postfix configuration, | ||
+ | === Procmail === | ||
+ | |||
+ | Having Postfix use procmail for delivery is easy. All you need to do is define the '' | ||
+ | <code ini> | ||
+ | mailbox_command = / | ||
+ | </ | ||
+ | === The transport map === | ||
+ | |||
+ | The transport table maps domains to message delivery transports (as specified in ''/ | ||
+ | <code bash> | ||
+ | domain1.example | ||
+ | anotherdomain.example | ||
+ | domain2.example | ||
+ | </ | ||
+ | After making your transport table in plain text, you need to make it into a binary DB file. To do this, you run the postmap program against the text file. | ||
+ | <code bash> | ||
+ | % cd / | ||
+ | % postmap transport | ||
+ | </ | ||
+ | postmap can create three different database files: btree, dbm, and hash. For more information on this, see the postmap(1) man page. It should be noted that hash is the default on Linux systems. | ||
+ | |||
+ | At this point, you need to tell Postfix that there is a transport table and where to find it. You also need to let Postfix know that we accept mail for those domains. This is done through the transport_maps and mydestination directives in '' | ||
+ | <code ini> | ||
+ | transport_maps = hash:/ | ||
+ | mydestination = $myhostname, | ||
+ | </ | ||
+ | This information could be stored in LDAP as well, in theory. However, we aren't aware of an object class that fits our needs here. For now, we feel safer doing it as a map file. | ||
+ | === Configuring LDAP sources === | ||
+ | |||
+ | You can easily define multiple LDAP sources. LDAP source parameters are documented in README_FILES/ | ||
+ | == Aliases == | ||
+ | <code ini> | ||
+ | aliases_server_host = localhost | ||
+ | aliases_search_base = o=hosting, | ||
+ | aliases_query_filter = (& | ||
+ | aliases_result_attribute = maildrop | ||
+ | aliases_bind = no | ||
+ | aliases_cache = yes | ||
+ | </ | ||
+ | This first LDAP source definition is for virtual aliases. We've named this LDAP source aliases. In our configuration, | ||
+ | == Accounts == | ||
+ | <code ini> | ||
+ | accounts_server_host = localhost | ||
+ | accounts_search_base = o=hosting, | ||
+ | accounts_query_filter = (& | ||
+ | accounts_result_attribute = mailbox | ||
+ | accounts_cache = yes | ||
+ | accounts_bind = no | ||
+ | </ | ||
+ | The accounts source is very similar to our aliases source. The big difference here is that we're looking for entries that have an object class of // | ||
+ | === The virtual alias maps === | ||
+ | |||
+ | |||
+ | Now that the aliases LDAP source is defined, we need to let Postfix know to use it. This is taken care of using the '' | ||
+ | <code ini> | ||
+ | virtual_maps = ldap:alias | ||
+ | </ | ||
+ | === The virtual accounts === | ||
+ | |||
+ | Telling Postfix about the virtual accounts is a bit trickier than the aliases. This is due to the fact that we need to define a lot of extra information about the virtual mail storage. | ||
+ | |||
+ | For this example, we assume that there is a vmail Unix account created that has a UID of 101, a GID of 101, and its home directory is ''/ | ||
+ | <code ini> | ||
+ | virtual_mailbox_base = / | ||
+ | virtual_mailbox_maps = ldap: | ||
+ | virtual_minimum_uid = 101 | ||
+ | virtual_uid_maps = static:101 | ||
+ | virtual_gid_maps = static:101 | ||
+ | </ | ||
+ | Most of the above is pretty straight forward, except for '' | ||
+ | |||
+ | We also need to edit the '' | ||
+ | <code ini> | ||
+ | local_recipient_maps = $alias_maps unix: | ||
+ | </ | ||
+ | |||
+ | ===== Courier ===== | ||
+ | |||
+ | You do not need to follow any special instructions for installing Courier, so please see its documentation for full instructions. It should auto-detect LDAP and build it in. You should seriously consider passing the '' | ||
+ | |||
+ | ==== Configuring the Authentication Daemon ==== | ||
+ | |||
+ | Courier uses an authentication daemon to keep authentication separate from the other parts of the system. We need to configure it so that a valid email user is either found in LDAP or in PAM. You specify this in authdaemonrc using the '' | ||
+ | <code ini> | ||
+ | authmodulelist=" | ||
+ | </ | ||
+ | |||
+ | ==== Configuring LDAP ==== | ||
+ | |||
+ | All LDAP parameters are in '' | ||
+ | <code bash> | ||
+ | LDAP_GLOB_UID | ||
+ | LDAP_GLOB_GID | ||
+ | LDAP_HOMEDIR | ||
+ | LDAP_MAILDIR | ||
+ | LDAP_CRYPTPW | ||
+ | </ | ||
+ | Three other settings we must concern ourselves with is '' | ||
+ | |||
+ | If you use '' | ||
+ | |||
+ | The last change you need to do is to enable the IMAP server by setting the '' | ||
+ | |||
+ | ==== Setting up IMAP over SSL ==== | ||
+ | |||
+ | If you had OpenSSL installed when compiling Courier, you will have support for IMAP over SSL. Courier can either do SSL using the '' | ||
+ | <code ini> | ||
+ | IMAPDSSLSTART=YES | ||
+ | IMAPDSTARTTLS=NO | ||
+ | TLS_CERTFILE=/ | ||
+ | </ | ||
+ | |||
+ | ===== SquirrelMail ===== | ||
+ | |||
+ | Since SquirrelMail works directly against IMAP it does exactly what we want it to out of the box. Consider it to be the same as any other IMAP client. There is nothing special about SquirrelMail' | ||
+ | |||
+ | We recommend that you set up SquirrelMail on a webserver that is running SSL. This will allow you to make sure that passwords are not going across in the clear. |
users/werner/mailserver2.txt · Zuletzt geändert: 2006-02-06 1834 von 127.0.0.1