|
Email Services (2)
pg. 6
Using a Catchall
Usually, when someone on the Internet sends email to a non-existent address, the
mail gets bounced, or returned to the sender as undeliverable. Even if the
domain name is valid, the mail will still bounce if the user specified in the
address does not exist on the server that the domain name points to.
By use of a catchall, however, your virtual server is able to successfully
receive all mail that is sent to an address on an associated domain, even if the
specified user does not exist. By using a catchall, email addressed to your
domain that cannot find a valid recipient–and would therefore bounce under
normal circumstances–gets successfully delivered to whatever destination you
specify, without returning an error message to the original sender.
To create a catchall, open a SSH connection to your virtual server and follow
the steps below:
Go to your ~/etc/mail directory and pico the catchall file:
cd ~/etc/mail
pico catchall
Add the domain name and a destination email address where unknown email
addresses should be forwarded. Use the following format, and be sure to separate
the domain and the destination with a space or tab:
domain destination
NOTE: The domain must be a complete domain name (such as abc.com) that is hosted
on your virtual server, and the destination must be a valid alias, virtmap,
email account, or email address. You can include separate entries, one per line,
for each domain name hosted on your virtual server; however, you can only have
one catchall entry per domain.
Run the vnewcatchall command to update the catchall database:
vnewcatchall
All improperly addressed mail that includes "@domain.com" will now be forwarded
to the destination email address.
Auto-Responders
An Auto-Responder is an automated program that sends pre-written responses to
all messages that arrive at a specified alias. Auto-Responders can be very
useful as a means of providing information about your business, or they can be
used to simply confirm that a message has been received. Auto-Responders can
help give your business a more professional image.
You can use Auto-Responders with as many aliases on your virtual server as you
wish, and each one can be set up to return a different message.
Setting Up an Auto-Responder
You can set up an Auto-Responder for any email alias by following three easy
steps:
1) Create a text file for your reply.
2) Define the Auto-Responder and Autoreply aliases in your aliases file.
3) Update the aliases database by running the vnewaliases command.
Step 1: Create a text file for your reply
If you have never before set up an Auto-Responder on your virtual server, you
should first create a directory to store all your replies in one place for easy
maintenance. Create a subdirectory of your ~/etc/mail directory called replies.
To do so, type the following at the command prompt:
cd ~/etc/mail
mkdir replies
Now, go into the replies directory you created by typing:
cd replies
You are now ready to set up a simple Auto-Responder for an alias called "info."
Using the pico text editor, create a file containing the text message you want
the Auto-Responder program to send in response to an incoming mail. To make your
reply text files easy to track, you should name them the same as the alias that
you're going to assign them to. So, in this case, type:
pico info
This will open pico and create an empty file called info.
The first section of your reply file should contain three headers. Headers are
pieces of information that give standardized instructions to email programs. The
three headers that should be included in every reply file are as follows:
From: Tells the recipient who the reply came from.
Reply-To: Tells the recipient's email client where to send a reply to this
message (although some older email clients ignore this header and just use the
From header).
Subject: Controls what will appear in the subject area of your reply.
Now, add the following lines to your new file in pico (Remember to press Enter
at the end of each line!):
From: info-reply@yourdomain.com
Reply-To: info-reply@yourdomain.com
Subject: Thanks! We've received your message
This message is to inform you that we have received your message and that
we will be getting back to you as soon as possible.
You can choose any subject and message text that you like. When you're finished,
press Enter at least twice at the bottom of the message. Finally, save the file
by pressing Ctrl+X, Y, Enter.
You should now have a reply text file called "info" in your ~/etc/mail/replies
directory.
Step 2: Define the Auto-Responder and Autoreply
aliases in your aliases file
The next step is to create an alias to be associated with this reply, and then
tell your virtual server to reply with this file to anyone who sends mail to
that alias. In this example, you'll need to create an alias called info, which
will trigger the Auto-Responder, and another alias called info-reply, which will
receive any responses to your autoreply and help you avoid serious
Auto-Responder problems (see Autoreply War in the following section).
To edit your aliases file, type:
cd ~/etc/mail
pico aliases
At the end of your aliases file, add the following two lines, pressing Enter at
the end of each:
info: destination,"|/usr/bin/autoreply –f
info-reply@yourdomain.com –a info –m /etc/mail/replies/info"
info-reply: destination
Note: Please make sure, especially if you cut and paste the above lines into
your pico editor, that the entire info: alias appears on a single line, and that
the info-reply: alias appears on a separate line.
The destination can be any valid email address or alias, but it should not be
another alias that will trigger an Auto-Responder. The destination should be the
same for both aliases. In essence, what you've just done is create an alias
called "info" that sends one copy of the incoming email to a destination
address, and another copy of the incoming email so the Auto-Responder program
can reply to the sender.
Take a close look at the information following the destination in the first
alias. The first character after the comma is a quotation mark. This is
necessary to include in your alias definition because the remainder of the line
contains some spaces. By enclosing this definition in quotation marks, you can
ensure that your virtual server sees the rest of the line as onesingle
destination. The first character inside the quotation marks is the pipecharacter
(|). On your computer's keyboard, the pipe is usually found on the same key as
the backslash (\) character. It's probably near the Enter key or the Shift key.
This character "pipes" or passes the incoming email message to the
Auto-Responder program, which is located in the ~/usr/bin directory. The
Auto-Responder program will then read the information passed to it and respond
accordingly. This example passes the following:
–f This option stands for "From," and the address following the –f option
shows the Auto-Responder program who the mail is from. This helps the
recipient's email client know who the message came from.
–a This option stands for "Allowed." The alias following the –a parameter is
the only alias that the Auto-Responder is allowed to reply for. This is included
for security purposes, and helps avoid Auto-Responder problems (see Autoreply
War in the next section). It must match the alias that you're defining, which,
in this case, is "info."
–m This option stands for "Message." The file path following the –m parameter
is the location of the message file to send as the autoreply. This is the file
you just created in the replies directory, so it points to
/etc/mail/replies/info.
All instances of yourdomain.com should be replaced with the actual domain name
of your virtual server.
When you're ready to save the aliases file, press Ctrl+X, Y, Enter.
Update the aliases database
The final step in setting up your Auto-Responder is to reload the aliases
database with the contents of your newly updated aliases file. To do so, enter
the following command at your virtual server's command prompt:
vnewaliases
If you receive and an error message, you'll need to re-open the aliases file,
check for errors, and repeat the vnewaliases command. Make sure that each
complete alias is on a single line.
If you received no error messages, you can test your Auto-Responder alias by
sending mail to it and seeing if you receive a message in response. In this
example, you should receive the contents of the info file in the replies
directory in response to mail sent to info@yourdomain.com.
Avoiding "Autoreply War"
Unless you take proper care when setting up your Auto-Responders, you could face
a serious problem known as Autoreply War.
Autoreply War can occur if your return address points to an alias that triggers
an Auto-Responder.
When you send email to an alias that triggers an Auto-Responder, an autoreply
message is sent back to you. If your return address includes an alias that in
turn points to an Auto-Responder, the two Auto-Responders will repeatedly
trigger one another, clogging up your mail services with autoreply messages and
filling up your virtual server's disk space in the process. This can cause
serious headaches for everyone involved.
The best way to avoid Autoreply War is to ensure that the From: and Reply-To:
headers in your message file do not point to an alias that will trigger an
Auto-Responder. If you follow the instructions for properly setting up an
Auto-Responder as outlined in section 5.8, you shouldn't have a problem with
Autoreply War.
To stop Autoreply War once it's started, you must remove the autoreply from your
~/etc/mail/aliases file. After waiting a few minutes, you can then put it back.
Creating an Information Only Auto-Responder
An Information Only Auto-Responder is an alias that simply sends a reply to an
incoming email message, without forwarding the incoming message, and without
accepting replies. This feature is useful for sending standard request forms,
especially if you lack the resources to respond to individual email messages.
To set up an information only Auto-Responder, you must use a special file on
your virtual server called /dev/null. Technically speaking, /dev/null isn't
really a file, it's a system device, but you can think of it as simply a
bottomless pit to which data can be sent, never to return or be heard from
again.
For the following example, suppose you want to create an alias called faq that
would only return the message contained in the faq file of the replies
directory, and then discard any replies to the Auto-Responder. Your aliases file
would include the following lines:
faq: "|/usr/bin/autoreply -f faq-reply@yourdomain.com -a
faq -m /etc/mail/replies/faq"
faq-reply: /dev/null
All incoming mail to faq@yourdomain.com will now be forwarded directly to the
Auto-Responder. The sender of the email receives the requested information, and
any replies that respond to your Auto-Responder (which come to
faq-reply@yourdomain.com) get "thrown away" in /dev/null.
Spam Protection
Like most Internet providers, virtual servers strictly prohibits the sending or
relaying of bulk or otherwise unsolicited email, commonly known as spam. Spam is
widely regarded as the email equivalent of junk mail, but unlike regular junk
mail, spam places much more cost on the recipient than the sender with respect
to spent time and resources.
In the past, typical spam content revolved around get-rich-quick schemes or
other potentially illegal or unethical content. Today, spam can take the form of
just about any kind of content. Many recipients consider spam to be not just a
nuisance but also an invasion of privacy or, depending on the content, an
affront to their social and moral values.
Spammers (people who distribute bulk email) know beforehand that their message
will not be well received by most recipients; therefore, they often employ
tactics that make it appear as though the message were originating from another
source.
Spammers may even try to use your server's outbound mail service to forward
their email, a practice known as spam relaying. Through spam relaying, spammers
use your service to bombard their unsuspecting victims, but it appears as though
you are the culprit. Other ISPs may even blacklist you as a result of spam
relaying.
Fortunately, your virtual server comes equipped with tools to help you combat
the efforts of spammers, including built-in software that prevents others from
using your mail server as a relay.
Blocking Unwanted Email
Your virtual server's Mail Blocking feature allows you to set access
restrictions based on individual email addresses, hostnames, or even top level
domains such as .cc or .my.
Your ~/etc/mail/access file contains a list of email addresses and/or domain
names from which you wish to restrict access to your mail server. You can edit
this file to maintain your own email blacklist.
NOTE: The ~/etc/mail/access file is a new feature that makes the ~/etc/spammers
file obsolete. Any pre-existing entries within this file at the time of the
sendmail upgrade can be found in the ~/etc/mail/access file with a "550" access
restriction code.
To restrict access to your mail server, SSH to your virtual server and follow
the steps below:
Go to your /etc/mail/ directory and pico the access file:
cd ~/etc/mail
pico access
Enter all the addresses or domains, one per line, for which you wish to restrict
access, according to the following format:
sender restriction
The sender can be an email address (user@domain.com), full domain (domain.com)
or top-level domain (.com).
The restriction can be any of the following:
REJECT – Returns an "accessed denied" code to the sender
DISCARD – Deletes the message with no further action. Does NOT return a message
to the sender.
RELAY – Allows a sender to relay through your virtual server.
As in the above example, place each entry on a separate line, and separate each
restriction with a tab.
Close the file and run the following command to update the access database:
vnewaccess
This command creates or updates your ~/etc/mail/access.db database file using
the entries contained in the ~/etc/mail/access file.
Example: Suppose you wish to reject all mail from
the individual address 'spammer@aol.com' and to discard any mail received from
'cyberspammers.com.'
To do so, you would need to add the following to your ~/etc/mail/access file:
spammer@aol.com REJECT
cyberspammers.com DISCARD
As in the above example, be sure to type only one address or domain per line.
Preventing Spam Relay
Spam Relaying is a dishonest practice employed by spammers whereby bulk email
messages are forwarded, or relayed, through someone else's outbound mail server
in an effort to mask the original source of the email.
Although spammers usually act without the knowledge or consent of the
administrator whose server is being used as a relay, it is impossible to tell
whether the spammer was actually given permission to use the server as a relay.
For this reason, Internet providers commonly blacklist any server that is
identified as an open spam relay, even though you may be more a victim of the
spammer than the spam recipients themselves.
Fortunately, your virtual server has built-in protection against spam relay as
part of its sendmail package. The options are as follows:
Standard Anti-Relay and Anti-Spam. Includes default sendmail configuration,
which prevents others from using your virtual server as a mail relay unless they
are granted RELAY access in the ~/etc/mail/access file.
Mail User Authentication
Mail User Authentication is a useful tool for preventing spam relay for users
who check their mail from remote locations. Rather than restrict access based on
IP address or domain, Mail User Authentication allows only authenticated users
(users who have checked their email on your virtual server) to send mail through
your virtual server's outbound mail server.
When a user checks for mail on your virtual server, the IP address from which
the request was made is recorded in the pophash database, ~/etc/mail/pophash.db.
Then, when a request is made to send mail through your virtual server, the
pophash database is checked to verify the request is coming from a validated IP
address. Because most dial-up ISPs provide you with a slightly different IP
address each time you connect, each of your users may end up with several
entries in this database.
For Mail User Authentication to work properly, the email client that is used
when checking for email must check for incoming mail before sending outgoing
mail. Although most email clients do check for incoming mail first, there exists
the possibility that certain email clients may not follow this practice. If you
or your users experience any trouble with Mail User Authentication, you may
remove it from your virtual server without affecting the anti-relay features
that are built into sendmail.
If you wish to enable Mail User Authentication, SSH to your virtual server and
enter the following command at the prompt:
vinstall popauth
You can also enable Mail User Authentication by manually creating and saving the
following files within your ~/etc/mail/ directory:
pophash
pophash.db
popauth
If, at a later time, you wish to remove Mail User Authentication from your
virtual server, Telnet or SSH to your virtual server and enter the following at
the command prompt:
vinstall –u popauth
You should make sure when you disable Mail User Authentication that you have
Standard or Advanced Anti-Relay and Anti-Spam in place by running the newconf
sendmail command.
Should you ever wish to clear out the contents of the pophash database, SSH to
your virtual server and type the following at the command prompt:
vcleandb
You may want to do this, for example, after you remove an email account from
your virtual server with the vrmuser command. The vcleandb command prevents a
discontinued user from continuing to send email through your virtual server.
Allowing Selective Relaying
Although it is not recommended, you can override your virtual server's
anti-relay features to allow certain trusted domains, IP addresses or IP blocks
to forward mail through your virtual server. Please be advised, however, that by
allowing selective relaying you are opening up your virtual server to the
possibility of being misused or identified as a spam relay.
If you want to allow certain IP addresses to relay mail through your virtual
server, you can place the IP addresses or IP address blocks in your
~/etc/mail/relay-domains file as "exceptions" to your anti-relaying protection
measures.
For example, if you want the IP addresses 207.32.33.5 and 192.44.44.22 to be
able to relay mail even if they don't have email accounts on your virtual
server, you would need to add the following lines into your
~/etc/mail/relay-domains file:
friendlydomain.com
207.32.33.5
192.44.44.22
You can also allow groups of IP addresses to relay through your virtual server
like this:
207.32.33.
192.44.
In the above example, any IP addresses starting with 207.32.33 or 192.44 are now
permitted to relay mail through your virtual server. Allowing groups of IP
addresses is useful if the person you wish to grant relay access to uses an
Internet provider that assigns slightly different IP address every time they
connect.
Sending / Receiving Attachments via the Command Li
There are two useful commands for sending and receiving email attachments from
the command line or from within a CGI program.
The mpack command allows you to MIME encode a file and attach it to an email
message from the command line. Likewise, the munpack command can be used to
extract an attachment from an incoming email, decode it, and save it as a file.
Sending Attachments
Mpack is an excellent command line tool for sending email attachments. It can be
used from a CGI script or directly from the server itself.
To use mpack, enter one of the following four commands at your virtual server's
command prompt on a single line (no wrapping). Each of the following commands is
explained in corresponding examples 1-4 below.
1) mpack [options] file [addresses]
2) mpack [-s subj] [-d message] [-m maxsize] [-C
content-type] file email-address...
3) mpack [-s subj] [-d message] [-m maxsize] [-C
content-type] -o file file
4) mpack [-s subj] [-d message] [-m maxsize] [-C
content-type] -n groups file
Replace [options] with one or more of the options detailed above. Replace "subj"
with the subject that you wish to give this message. Replace "message" with the
name of the file that you with to send that may have descriptive or message
information. Replace file with the file you wish to pack. Replace [addresses]
with the e-mail addresses of those you want to send the MIME-encapsulated file
to. If you are sending the file to a newsgroup or saving it to another file, you
do not need to include e-mail addresses.
Here is an example of sending an attachment with a description file from a
command line:
NOTE: The commands in all of the below examples must each be issued on a single
line! Due to formatting constraints, some commands may appear to be on separate
lines.
Example 1: Typical command line use of sending an attachment with a description
file
Command format:
mpack -s "subject!" [options] file [addresse(s)]
Sample Use:
mpack -s "Test message" -d email.txt attachment.exe user@domain-name.com
This example assumes that you are in the directory that contains both the
email.txt and attachment.exe files. If these files are not in the directory you
are currently in, you will need to use the file paths.
Example 2: Sending an attachment with a description file from a command line
using the file paths
Sample Use:
mpack -s "Test message" -d ~/ftp/pub/email.txt
~/ftp/pub/attachment.exe user@domain.com
Example 3: Packing a file without sending it
This example takes a file named original_file and creates a mime encoded file
called encoded_file_name. The -o option will cause mpack to write the encoded
file out to a new file rather than try to mail it directly:
Command format:
mpack –s "Subject required" -o encoded_file_name original_file
Sample Use:
mpack -s "Encoded Message File Example." -o encoded attachment.exe
Example 4: Using mpack as a command in a CGI
script
Now, suppose that you wanted to have a CGI on your website that mailed a visitor
a specific file if they submitted their email address. Then, you would have your
CGI call the mpack program with something like:
Command format:
/usr/local/bin/mpack -s "Subject" filename email_address
If I wanted to include text in the message to, I could have the CGI write it to
a temporary file and use this instead:
mpack -s "Subject" -d textfile filename email_address
For more information regarding mpack, type man mpack at a command prompt.
Receiving Attachments
The munpack command allows you to extract the contents of a file (or piped-in
email) to a separate file. The file is saved in the current directory, or to
whatever directory is specified using the -C flag. Munpack can handle both MIME
and UUENCODED files. The syntax for this command is:
munpack [ -f ] [ -q ] [ -t ] [ -C directory ] [
filename... ]
Please note that the entire command must appear on a single line; due to
formatting constraints, the above syntax may appear on more than one line.
Example: Saving attached files to a directory
Suppose you wish to accept attached files sent to an alias "files@domain.com"
and save them in your ~/tmp directory.
First, copy /usr/local/bin/munpack to your ~/usr/local/bin directory:
cp /usr/local/bin/munpack ~/usr/local/bin/
Then, put a line like this in your aliases file:
files: "|/usr/local/bin/munpack -C /tmp"
This line sends any incoming mail to files@domain.com to the munpack program,
which extracts the file and saves it in the directory specified by the -C flag,
which in this case is the tmp directory in your home directory. If the -C flag
is not given, files are saved to your home directory. Munpack can only handle
one file per message, so multiple attachments are not supported.
Unless you use the -f flag, munpack will never overwrite existing files.
Instead, it will add a number to the end of the filename and ensure that the
file doesn't overwrite any file that already exists by the same name.
Quick Command Reference
The following commands can be issued at your virtual server's command prompt.
pine: Starts the PINE text-based email client on your virtual server.
vmailhash: Runs the following four commands all at once:
vnewaccess: Updates the access permissions to your virtual server's email
services, according to your /etc/mail/access file.
vnewaliases: Updates the active email aliases on your virtual server
according to your /etc/mail/aliases file.
vnewcatchall: Updates the active catchalls on your virtual server
according to your /etc/mail/catchall file.
vnewvirtmaps: Updates the active email mappings on your virtual server
according to your /etc/mail/virtmaps file.
vadduser: Adds a new email account.
vlistuser: Displays information about all active email accounts.
vedituser: Allows you to edit an email account.
vrmuser: Removes an email account.
vpasswd: Changes the password for an email or FTP account.
Virtual Server Lite |
Virtual Server Standard |
Virtual Server Pro |
Virtual Server Ultra |
400 megs |
1000 megs |
1500 megs |
6000 megs |
Details |
Details |
Details |
Details |
Order |
Order |
Order |
Order |
|
