test

[hcoop/zz_old/ikiwiki] / EmailConfiguration.mdwn

Before continuing with this page, you probably want to read DomainTool to learn the basics of how we handle shared daemon configuration.\r
\r
There are two ways to control how exim handles mail sent to your domains.\r
\r
The first, simpler, and preferable way is to ask exim to redirect messages from particular input addresses to particular output addresses. These redirections are called aliases. This method avoids creating any new mailboxes, and it even supports redirecting to e-mail accounts on other servers.\r
\r
If you really need distinct mailboxes for different addresses at your domain, then you can use virtual mailboxes. While aliases work similarly to other DomainTool features, virtual mailboxes are managed with a special command-line tool {{{vmail}}}.\r
\r
= E-mail aliases =\r
A {{{.aliases}}} file in a domain's directory controls its e-mail aliases. A {{{target}}} below may one of three things:\r
\r
 * a local username, to deliver mail to that user\r
 * an e-mail address, to forward mail to it\r
 * {{{!}}}, to drop mail to this address\r
The file then consists of a sequence of lines of the following types. In each case, {{{targets}}} means a comma-separated list of one or more targets.  \r
\r
 * {{{user targets}}}: Send all mail to {{{user@domain}}} to {{{targets}}}.\r
 * {{{* targets}}}: Send all mail to {{{domain}}} not matching any other rule to {{{targets}}}. However, if mail is sent to an existing UNIX username, the message will go to that account.\r
 * {{{** targets}}}: Send all mail that does not match another rule to {{{domain}}} to {{{targets}}}, even mail addressed to real UNIX usernames.\r
\r
After you modify the {{{.aliases}}} file, run the command {{{domtool}}} followed by the command {{{reloadusers}}} for the changes to take effect.\r
\r
== Example: Using aliases to send e-mail to multiple accounts ==\r
\r
The email aliasing feature can be used to set up a mailing list where email to one address is sent to multiple addresses.  In order to do this, include a line similar to the following in your .aliases file (no caps, no spaces):\r
\r
{{{admins    beth@test.org,bob@test.org}}}\r
\r
In this example, {{{admins@yourdomain.org}}} would be the destination address that would send an email to both {{{beth@test.org}}} and {{{bob@test.org}}}.\r
\r
After you modify the {{{.aliases}}} file, run the command {{{domtool}}} followed by the command {{{reloadusers}}} for the changes to take effect.\r
\r
= Virtual e-mail addresses =\r
You may create virtual e-mail boxes for any domains for which you have write permission in DomainTool. I think a few examples will explain the process well enough.\r
\r
Before continuing, however, please note that DomainTool allows you to create aliases that forward mail from one address to another. Aliases are much preferable to extra mailboxes, both in terms of conserving server resources and convenience for you, as you can continue checking one mail account even if multiple aliases point to it. The basic rule is: If you are creating a virtual mailbox that only you will read, or if you are creating multiple virtual mailboxes to be read by the same other person, then you should be using aliases instead.\r
\r
{{{\r
% vmail your.domain add new.user\r
Password: password\r
Reenter password: password\r
Mailbox created.\r
% vmail your.domain list\r
new.user\r
% vmail your.domain passwd new.user\r
Password: password'\r
Reenter password: password'\r
Password set.\r
% reloadusers\r
% vmail your.domain rm new.user\r
Are you sure you want to remove new.user@your.domain? (yes/no) yes\r
Removed.\r
}}}\r
Running {{{reloadusers}}} is necessary to update Courier's database with your new user information. You only need to run it at the end of a batch of modifications, including just a single modification. After doing this in the example, your new user can access his e-mail with username {{{new.user@your.domain}}} via SSL IMAP or POP3 at {{{mail.hcoop.net}}}. He could also use [http://mail.hcoop.net/ SquirrelMail].\r
\r
In the example above, the created mailbox lives at {{{/home/vmail/your.domain/new.user}}}. The files are owned by the creating user, so they will count towards your disk quota. This also means you can muck around with your virtual mailboxes directly, but I wouldn't advise it. However, you should only be able to screw yourself over by doing so. The one time when it's helpful to access them directly is when transferring mailboxes across machines.\r
\r
For your virtual mailboxes that are intended to be used by other people (which should be all of them!), we have [https://members.hcoop.net/passwd a web page] where your users can change their own passwords.\r
\r
= Backup MX services =\r
See the {{{BackupMail}}} directive in DnsConfiguration.\r
\r
= Debugging mail problems =\r
If you are having problems with e-mail accounts associated with a domain that you don't own, post a support request on [https://members.hcoop.net/portal/ the portal].\r
\r
For domains that you ''do'' own, you can run the {{{rlog domain.name}}} command to see those lines from the current mail log that contain your domain name. This won't always be all the information that you'd like to see, since log entries can be grouped without containing the domain name on each line, but it can be helpful all the same. A better solution might be put into place if someone develops one.\r