Most people retrieve their e-mails from one or more POP3 accounts at their Internet Service Provider. With a DSL flatrate access which is online 24 hours a day and 7 days a week, receiving e-mails directly is an interesting alternative. For instance, if you are using Shamrock's NetMail e-mail system for Windows, there are two add-on modules allowing this: An SMTP server for reception, and a DynDNS utility for using a dynamic-IP DNS provider like dyndns.org or selfhost.de.
Using your own SMTP server (standard mail transfer protocol) for e-mail reception instead of retrieving mails from a POP3 mailbox has pros and cons. Let's look at the sunny side first.
Correct BCC handling: If somebody sends you a blind copy (BCC) of an e-mail, it depends on non-standard header lines inserted by the POP3 server -- like Delivered-To or Envelope-To -- if it is still possible to determine the correct recipient. While it does work in some cases, receiving mail with your own SMTP server is the only way to receive BCC-addressed mails reliably.
Instant delivery: While you have to poll your e-mails every ten or fifteen minutes using a POP3 account, an SMTP server gets incoming mails within seconds after they have been sent. E-mail gets nearly as fast as a chat!
Bounces to true sender: If an e-mail is denied, the SMTP server will bounce it to the actual sender even if the From address is faked (which is quite typical for viruses and spam), while a return mail would go to somebody else.
Less data volume: Since the SMTP server has full control over which data it accepts and which not, it is able to reject mail which goes to non-existing user names, comes from barred IPs, or is in some way suspicious. This reduces the traffic volume significantly and leaves more bandwidth for other applications like web browsing.
Easy user management: Since catch-all POP3 accounts are now often victims of random-address spam and virus attacks (with fantasy characters before @your-domain), mailbox names have to be configured at two places -- at your provider and in your local e-mail system. When using your own SMTP server for reception, it can check valid usernames locally and block invalid ones.
Accepted mails 81 Blocked by IP 197 Invalid HELO 57 Blocked sender 4 Blocked by RBL 39 User unknown 32 HTTP requests 9 RBL cache size 183 RBL cache hits 95 Greylisted 67
|Sample statistics from a
NetMail SMTP server with
Better virus and spam protection: Using a DNS-based real-time blackhole list (RBL) and a list with explicitly barred IP ranges of spam-friendly foreign countries (you know their names!), you can block many spam and virus senders even before their payload is transferred to your system; please see our article about spam for more information. Your mail acceptance policy can be perfectly adapted to your personal needs, which would never be possible for a POP3 mailbox at an ISP (Internet service provider). The sample statistics on the right are based on the following characteristics:
As stated above, running your own SMTP server for e-mail reception requires a (near-to) 24/7 Internet connection. Since most DSL/cable lines have dynamic IP addresses, this may cause some unexpected problems.
IP change: Most DSL or cable providers disconnect the line once a day, typically after 24 hours. It is a good idea to force a disconnect at night to avoid this during business hours. If you do not own a static IP address, someone else -- who now gets your old IP -- might receive your e-mails until you register a new IP at the DNS provider. (This is not very likely, though, and even if it happens, a correctly configured alien server will not accept mails to your domain but answer "relaying denied" instead.)
DSL or PC failure: Similar problems occur if your PC is down, of your local DSL/cable line is out of service. (However, even then you will most probably not lose any mails since the sending server will retry them for several hours or even days.)
The logical consequence is that you should not run your own SMTP service if your DSL or cable connection is unstable, if you often have power outages, or if the server PC is frequently used for running unstable applications which sometimes crash the operating system. Also, not all Internet service providers offer a configurable MX (mail exchange) DNS record for hosted domains. Setting the MX record to a different domain (typically a DynDNS subdomain) is a prerequisite for running your own SMTP server for mail reception.
If you have a professional e-mail system for your network with an SMTP server module (like the free NetMail SMTP add-on), you will need to register at a dynamic IP DNS service like dyndns.org or selfhost.de (which is free for basic functions). Your server is then accessible via a (sub-)domain of this service, like example.dyndns.org.
> 220 example.com < XXXX mail.xyz.com > 500 Syntax error: XXXX < HELO mail.xyz.com > 250 example.com Hi mail.xyz.com
|Sometimes you may see strange syntax errors with XXXX in the SMTP dialogue. This is a Cisco PIX firewall not capable of ESMTP and replacing an outgoing EHLO by XXXX. The client then retries using HELO instead of EHLO which works. The retry could be avoided by disabling the "SMTP Fixup" option in the Cisco firewall.|
You will also need either a DynDNS-compatible router or, if using RAS/PPPoE DSL connectivity, a utility program (like the dyndns add-on for NetMail) which checks if your IP has altered, and if so, tells it the DynDNS server using a personalized IP-update URL with username and password. This utility program should also have a keepalive function which avoids that the DSL provider disconnects the line after 20 or 30 minutes of inactivity. (You will not need this keepalive function if you still poll mails from a POP3 account with an interval of 15 minutes or less.)
Now, if you have your own domain like example.com and your webspace provider allows you to change the DNS MX (mail exchange) entry in his nameserver, you can enter your new DynDNS domain there (like example.dyndns.org). Set the priority value to 10 (configured in steps of 10, with 10 being the most privileged one).
A backup MX field (typical priority 20) can be set to another subdomain of the same DynDNS account also pointing to your local dynamic IP. This will allow faster retries of sending servers using your second MX if you enable greylisting. It is not a very good idea to set the backup MX to a POP3 account at your provider: Many spammers and viruses prefer the backup MX since it is often less protected than the primary MX, so the better filtering of your SMTP server would be circumvented by using a POP3 backup.
Sometimes spammers or broken systems (typically with a full hard disk) flood
your SMTP server with unwanted connections and endless retries. If you are not
using a firewall or do not have quick access to it, you can still block an
attacker using the "route" command, routing him to a non-existing LAN address.
He will run into a timeout of a minute or more without bothering your server
any more. The following Windows commandline blocks 126.96.36.199 by routing it to an
unused IP 192.168.0.222 in your local netblock:
route -p add 188.8.131.52 192.168.0.222
The optional parameter -p makes the blocking survive rebooting your system. To disable it later, enter:
route delete 184.108.40.206
However, as always in life, there is a drawback: Every redirected connection occupies a socket. If there are many connections in a short time, the operating system will be short of free sockets. A real firewall is still a better solution in this case.
Instead of letting the DNS MX record of your domain point directly to your SMTP server, you might think that an alternative is not to change it at the ISP and configure a redirection from there to your local SMTP server instead. While this does speed up the delivery a bit compared to POP3, it has some big disadvantages, even if you choose to do so for the backup MX only:
So if you set up your own SMTP server, you should configure the DNS MX record to point directly to it, instead of redirecting e-mails at your provider. Otherwise the improvement would be marginal compared to a POP3-based mail retrieval.
If you can receive your e-mails directly from servers around the world, why not send all outgoing e-mails directly to them, too? Well, while this is actually possible, it is a very bad idea since many of your mails would never reach their destinations: An increasing number of ISPs, companies and users block all incoming mails coming from dynamic IP addresses.
The reason is that so many PCs with dial-up lines are hijacked by viruses and spam-relaying trojans (which are often the same thing, by the way). So it is strongly advisable to send all e-mails through the SMTP smarthost of your provider, even if you are using your own SMTP server for direct reception. The additional delay is typically below five seconds and not noticeable.
Another reason for not sending e-mails from a dynamic IP address is that many mail servers are using greylisting, i.e. they first defer an e-mail with a temporary error code and then expect that the sender retries later using the same IP address as before. This will frequently cause problems when the sender uses a dynamic IP address.
© 03/2008 Herwig Feichtinger, Shamrock Software GmbH