I recommend using a mail service provider that offers SMTP relay service with STARTTLS. One that I know of is fastmail.fm, which has a good free IMAP service, and seems to provide STARTTLS-compliant SMTP service for a small one-time fee.
Here is another option that provides a secure way to get realtime mail delivery to a dialup host with a dynamic ip adress from a cooperating site with a static address: Postfix DynDNS Dialup Host from Thalmann Computersysteme.
I'll leave the rest of this up in case to explain some of the goals and technical issues, in case it helps folks with small servers that don't get blocked, but I don't use it any more.
In the meantime, your help in fighting the spammers, as described at, e.g. Spamfighting Overview, would be appreciated.
By default, when you install a Linux machine running a common distribution like Redhat's, and you send mail using a standard mailer like Mail or mutt or elm or xemacs, the mail is sent directly from your machine to the service that hosts your recipient's mailbox. This is usually good. But sometimes it doesn't work, and this is an attempt to tell you what you need to know to make it work better.
There are lots of good reasons to run your own mail server. It isn't for novices, but it is the only way to really control how your mail works.
It causes your mail to be sent as directly as possible to your correspondents, rather than thru an intermediary. A basic design principle of the Internet was originally to prefer "end-to-end" (aka peer-to-peer) connections. This is faster, more secure, and lets you know via your log files (/var/log/messages) whether your message has gotten thru yet. It eliminates one more fallible link in getting your email out. And you can get nearly end-to-end encryption much of the time via STARTTLS (see below).
This page is mainly focussed on sending mail, assuming that the user receives incoming mail via a mailbox on some other more reliable server, and uses something like fetchmail to transfer that to their home computer. It is also possible to receive mail directly to a home computer with a dynamic address, e.g. via a dyndns.org address, but it is more important for an incoming server to be up and reachable all the time, so be sure your setup is sufficiently stable if you do this.
But, even if you just want to send mail, you probably need to allow your MTA (e.g. sendmail) to receive mail from outside machines, because they sometimes bounce messages after the initial delivery connection is closed. But when you do this, you also have to be careful to keep your Mail Transport Agent (e.g. sendmail) up-to-date with security patches, like any service that listens on a port that the outside world can connect to.
Because of the scourge of spam, some sites bounce mail from computers on cable or DSL or wireless or dialup lines - those with dynamic IP addresses, e.g. from DHCP. They typically do this via special DNS servers configured to identify such IP addresses, such as the MAPS Dial-up User List, or by keeping track of which address ranges seem to be generating spam to them.
Rather than giving up on direct connections altogether, I use the "mailertable" feature of sendmail to re-route just mail to those domains thru the smtp service that my ISP provides.
Here's my /etc/mail/mailertable. It is just an example, since in general, different servers will use their own criteria on which address ranges to block. You need to fill in the name of your own SMTP relay, as documented by your ISP or 3rd party email service provider, in place of "smtp.comcast.net".
aol.com smtp:smtp.comcast.net juno.com smtp:smtp.comcast.net netscape.net smtp:smtp.comcast.net cs.com smtp:smtp.comcast.net umn.edu smtp:smtp.comcast.net .umn.edu smtp:smtp.comcast.net
The default sendmail.cf already has mailertable enabled:
FEATURE(`mailertable',`hash -o /etc/mail/mailertable.db')dnl
After changing the mailertable file, run
makemap hash /etc/mail/mailertable < /etc/mail/mailertable
and it should take effect. See
Using Mailertables
for more information.
If your SMTP relay requires that you use a userid and password with it (like smtp.comcast.net), you will also need to configure sendmail to send that authorization information. E.g., in /etc/mail/access add a line like this:
AuthInfo:smtp.comcast.net "U:userid" "P:passwd" "M:CRAM-MD5"and run
makemap hash /etc/mail/access < /etc/mail/access
qmail has a "smtproutes" file where you can specify the SMTP server/port to use based on the domain name you're sending to. E.g.:
echo aol.com:smtp.comcast.net >>/var/qmail/control/smtproutes
The sites listed above all notify you via a bounce message when they block your mail from a dynamic address. The risk is that some sites may just silently reject your mail, or classify them as spam so that the recipient is less likely to see them. Yahoo's spam filter may be an example of the latter. Does anyone know of sites that silently discard such mail?
An alternative, especially for computers that are not connected all the time, is routing all outgoing mail thru a relay as described at a mail-abuse.org page and at Sendmail on a dialup.
The STARTTLS
SMTP extension allows for encrypting an email connection
and authenticating hosts. TLS is a newer form of SSL.
STARTTLS requires getting or signing your own certificate, e.g. by
running openssl. To set it up on RedHat Linux 9 or beyond,
run
make -C /usr/share/ssl/certs sendmail.pem
to create a
certificate, then
remove the leading comment marks ("dnl ") on the lines dealing
with certs in /etc/mail/sendmail.mc and restart sendmail.
For other platforms and more detailed instructions, see sendmail.org on SMTP STARTTLS, or Authenticated Sendmail over SSL from Open Source Digest, or provos notes and more notes.
See also:
Pointers to ISPs that offer SMTP relay service with STARTTLS and perhaps even ways to check your outgoing mail in their logs would be appreciated. One that I know of is fastmail.fm, which has a good free IMAP service, and seems to provide STARTTLS-compliant SMTP service for a small one-time fee.
The following more terse hints still need some fleshing out.
Note that sometimes ISPs don't do a good job of
providing dns and/or reverse-dns service on their dynamic addresses,
which can result in lack of delivery with warnings like this:
Domain of sender address user@xxx.client.example.com does not
resolve. Warning: message still undelivered after 4 hours.
Sendmail's option
FEATURE(`accept_unresolvable_domains')dnl turns off
this checking on the recipient side, but the checking is usually a
good idea.
Consider using a free service like dyndns.org to track your DHCP address so
your /etc/hosts file (often used for the HELO message?) can point to
a stable and accurate domain name for your machine.
Then put this in your /etc/hosts file:
127.0.0.1 example.dyndns.org localhost.localdomain localhost
and run "service sendmail restart"
There are other, less common reverse-dns issues. E.g. "check_reverse": checking the IP of the sending machine for reverse and forward DNS resolution which match each other. Or "strict_reverse": Perform this check on the helo address too.
Note that Bernstein's page on HELO explains why linking the two together is a bad idea:
A few servers reject messages from clients whose HELO parameters do not match the results of PTR lookups on their IP addresses. This behavior is a disaster in practice; surveys in 1998 found that more than 10% of all clients by volume use invalid HELO parameters.And note that there is an Internet Standard, RFC1123, which prohibits doing that:
The HELO receiver MAY verify that the HELO parameter really corresponds to the IP address of the sender. However, the receiver MUST NOT refuse to accept a message, even if the sender's HELO command fails verification.
Discuss other MTA's (Mail Transfer Agents) like postfix (with STARTTLS in Redhat 7.3?), qmail (has patches for STARTTLS?), smail, exim (standard for debian? no STARTTLS?), zmail etc.