Contents
SMTP Introduction. 1
Open Relay. 1
IP Addresses and MX records. 1
Reverse DNS and the SMTP Banner
(FQDN). 1
Enabling Windows SMTP Server. 1
Configuring Windows SMTP Server. 1
Postmaster. 1
Setting up hMailServer. 1
Testing your SMTP Server. 1
Telnet. 1
MX Toolbox Website. 1
Send an email from C#. 1
Receive mail to the Drop directory. 1
Spotting Problems. 1
SMTP (Simple Mail Transfer protocol) is the basis of all
email transfer. It is the mechanism used for sending and receiving email
messages, nothing else. If you want your application to send or receive mail
you are going to need, or have access to a SMTP server.
As the name suggests it is simple and it does the
transferring, it has nothing to do with storing messages or providing any other
functionality.
You may be aware of other mail related protocols, like POP3
and IMAP, these are not competing with SMTP and have nothing to do with message
transfer, they are only used for storage and access to the store. So if you are
learning email then start with SMTP and forget about everything else for now.
SMTP essentially has 2 access points:
·
TCP Port 25 – Email clients and other SMTP servers connect to
submit a message, either for “relaying” to another SMTP server or receiving to
a local recipient.
·
“Drop” directory – a file system directory where received
messages are dropped.
When you send a message your email client, or your
application, connects to your SMTP server on port 25 then submits the message.
It then looks up where to send it using DNS from the domain part of the target
email address and then uses the exact same process to submit to the target SMTP
server.
When you receive a message your SMTP server detects that the
message is intended for a local recipient and drops the message to the Drop
directory.
That is all SMTP servers do, they are simple beasts.
One of the main concerns when setting up an SMTP server is
making sure only people within you organization can use it to send messages
out.
The worst thing you can do is misconfigure it so people on
the outside can connect to it and send messages to external email addresses.
This is known as an “Open Relay” and will quickly lead to your SMTP server
being abused and the IP address getting blacklisted, so other SMTP servers
refuse to accept connections from it. This is bad.
I will discuss this further down when it comes to
configuring SMTP but I wanted to mention it early on as it isn’t something to
be taken lightly.
By default SMTP serves won’t allow any relaying so don’t let
it worry you too much until you come to configuring it.
I will first mention that, in theory, an SMTP server can be
used to send messages out even if it is not accessible from a public IP
address, just setting one up inside the LAN. Only problem is many SMTP servers
out there may not take too kindly to this and will refuse to receive messages
from this kind of setup, but you may want to use this configuration for testing
sending messages to another of your own SMTP servers for example.
So let’s talk about setting up an SMTP server that can
receive messages. First off port 25 needs to appear on a static public IP
address. How you achieve this depends on you network topology, you may either
have a separate network card on the host configured with a public IP or be
using port forwarding from a firewall, please see the “Network topology”
section for more on this.
You can test your SMTP from a remote network with a simple
telnet to port 25, hit return a few times and you should see a greeting banner.
If not then try a telnet from the local machine then work your way out checking
Windows Host firewall, then try telnet from another host on the LAN, and then
port mapping on the router.
SMTP uses DNS to lookup where to send an email, this is what
happens:
·
The domain name is taken from after the @ sign. Fred@spludlow.co.uk -> Spludlow.co.uk
·
The “MX” record is looked up from that DNS zone. “MX” is a DNS
record type that holds the full domain name of the SMTP server in question
-> mail.spludlow.net
·
The “A” record is looked up from DNS like any other DNS name mail.spludlow.net
-> 11.22.33.44
·
This is the address of the SMTP server to connect to
That was the very basics of MX records, here are a few extra
points:
·
There are often multiple MX records each with a priority on large
setups. If the first is down then SMTP will try the next.
·
If you only have one MX record and the SMTP server is down when
another server attempts to send mail then it will automatically try again
later. The sender may get a warning (generated by the server at their end), but
the message should still arrive. This is typically the case when a host is
temporally down.
·
The “MX” record target hosts don’t have to be in the same DNS
zone, they can point to any DNS name (may not even be within your
organization).
·
An “A” record must exist for the “MX” target, obviously.
·
You can use sub domains in the email address without setting up
sub DNS zones. For example you could have an “MX” record for
“test.spldulow.co.uk” setup within the zone “spludlow.co.uk” that would accept
mail to fred@test.spludlow.co.uk
Changing a domains “MX” records is normally done through
your domain registrars/hosting control panel under the DNS section, log in and
have a look round I’m sure you’ll find it.
A typical “MX” entry will be as follows
Mail Zone Mail Server Priority TTL
test.spludlow.co.uk mail.spludlow.net 10 7200
The A record “mail.spludlow.net” should exist with the
public IP address of your SMTP server.
TTL is “Time to live” and means how often other DNS server
should check back to see if it’s changed, your DNS control panel may hide it
completely, if not then 7200 seconds is a reasonable value.
Some mail servers can be fussier than others about which
SMTP servers they allow connections from. One of the main criteria they can
often be strict about is reverse DNS, this is part of the DNS system that looks
up a host name from the IP address (the reverse of what you normally do).
NOTE: The SMTP banner (fully qualified domain name) and
reverse DNS do not have to match the MX record.
When an SMTP servers starts a session it sends out a
“banner” of the servers fully qualifies domain name, this should match the
reverse IP lookup of the servers public IP address. If they don’t match then it
is considered a “SMTP Reverse DNS Mismatch” and connections may be refused.
On big networks you may be in charge of your reverse DNS
zone but you may never have heard of it. This is not a problem as you can just
use the reverse DNS record that your ISP has automatically configured, enter
the following command:
nslookup 11.22.33.44
The bit you are interested in will look something like this:
Name: host11-22-33-44.in-addr.btopenworld.com
You can prove it resolves back to the original IP:
ping host11-22-33-44.in-addr.btopenworld.com
You should see the original IP (it may not actually ping
from outside due to firewall).
This fully qualified name can be used for the SMTP banner
(FQDN) setting within the SMTP server.
Your ISPs automatically provided reverse DNS entry could
potentially change, from a re-brand or merger, so be aware.
Here I will discuss enabling SMTP on Windows Server. SMTP
used to be included on all editions of Windows but Microsoft decided to only
include it on Server editions now. If you are running a client version of
Windows then you will have to install SMTP as a separate piece of software,
surf the web to find a product.
On Windows Server do the following:
·
Start “Server Manager”
·
Click “Add roles and features”
·
Click “Next” through everything past “Roles” until you get to
“Features”
·
Scroll down and find “SMTP Server” click it
·
A window will pop up listing all the additional features it wants
to install, accept it and click “Add Features” (Note: SMTP is configured
through the “IIS 6 Management Console” this is an old version that you will use
only for configuring SMTP)
·
Click “Next” though everything until you get to “Install” and
click it
·
Wait for it to do it
The host now has SMTP.
I will talk through the real basics of getting your SMTP up
and running. I’m not enabling any security measures other than the standard IP
restrictions on relaying:
·
First off the SMTP Service by default is set to a start-up type
of “Manual”, find it within the Services management console, it’s listed as “Simple
Mail Transfer Protocol (SMTP)”, and change the start-up type to “Automatic”.
·
Windows firewall seems to get automatically configured but you
can check there is an entry for “Simple Mail Transfer Protocol (SMTP)” and it
is enabled on all network types
·
Configure your router/firewall to allow incoming traffic on port
25 to the host running SMTP
·
Start up the old (6.0) IIS Management console: Control Panel
-> Administrative Tools -> Control Panel -> Administrative Tools ->
Internet Information Services (IIS) 6.0 Manager
·
Within the Manager you should see “[SMTP Virtual Server #1]”
right click here and select “Properties”
·
Click the “Access” tab and click the “Relay…” button a relay
restrictions dialogue will appear
·
Be careful here, add the local IP addresses of the hosts that
will be able to send mail, for example your application server and development
box. Only add the whole local network if you are using a separate public IP
network adapter. If your router is port mapping to a local IP address and you
grant relay for the whole local network then you will have created the dreaded
“open relay” as the SMTP server will see the routers local address and not it’s
external public IP address. OK the Relay Dialogue box when finished adding
local IPs
·
Click the “Messages” tab, these limits are a bit tight by today’s
standards, set the “Limit Message Size” and “Limit Session Size” to something a
bit more like it 262144 (256 MB) It’s in KB so multiply by 1024 for MB.
·
Click the “Delivery” tab and click the “Advanced” button the
“Advanced Delivery” dialogue will appear.
·
Under “Fully-qualified domain name:” enter the mail server that
is used by the “MX” record this should be the one that will reverse lookup to
the public IP. OK the dialogue.
·
OK the main “Properties” dialogue, returning back to the main
management console.
·
Click on “Domains” under “[SMTP Virtual Server #1]” you should
see the default domain in the right hand panel.
·
Right click the default domain and select “Rename”. Name this as
your primary email domain. This domain will be used for the postmaster address
“postmaster@primarydomain.com”, this will be NDRs from address.
·
Right click the default domain again and select Properties.
·
This is where you set the “Drop” directory, change it to where
you want the raw email messages to appear. Ensure this folder has permission
for “SpludlowGroup” to read and delete files here if necessary. The SMTP
Service runs as “Local System” so by default will already have permission to
any local directory. You may want to share this directory if a remote hosts is
going to be accessing received mail. OK the dialogue.
·
Now right click on “Domains” and select “New -> Domain…”
choose “Alias” from the radio buttons and click “Next”.
·
Now enter the email address space (the bit after the @) that you
want this server to accept. This has to match up with the “MX” record in DNS.
Click “Finish”.
·
Repeat the previous 2 steps for any other domains you are
receiving mail for that all have the “MX” record setup. Like if you have
domains for .co.uk, .com, and .net.
That’s your lot is should now be sitting there ready to
receive mail into the drop directory (provided MX records are setup in DNS) and
let you send mail from inside your network (that are in the allow relay IP
list) to the outside.
Every mail server must accept messages to a postmaster@
address and someone should be reading them. This is intended for people to get
in touch with the administrator of the mail server to report delivery problems
and abuses.
This is internet law described in the SMTP specification,
currently RFC 5321. Failure to comply may result in blacklisting
If you are running a client edition of Windows (not Server)
then SMTP is no longer included hMailServer is a good option.
This product uses a database you can choose to use a built
in database if you want to keep things simple. Here I will use an existing SQL
Server database running on another host with Windows Authentication.
The hMailServer Windows Service runs as “Local System” so it
will authenticate to a remote database server as “DOMAIN\MAILHOST$”, add this
logon to the database with permission to create the database.
Let’s run though some tests to prove everything’s right.
The most basic test is to telnet to port 25, preferably from
an external network (telnet needs to be enabled as a feature in Windows, by
default it is disabled). If you don’t have access to an external network get a
friend to try it for you, or proceed to the next test. Issue the following
command from a command prompt:
telnet host11-22-33-44.in-addr.btopenworld.com
25
Hit return a few times and then type “quit”. You session
should look something like this:
220 host11-22-33-44.in-addr.btopenworld.com
Microsoft ESMTP MAIL Service, Version: 10.0.14393.0 ready at Wed, 1 Feb 2017
11:00:26 +0000
quit
221 2.0.0 host11-22-33-44.in-addr.btopenworld.com
Service closing transmission channel
Connection to host lost.
If you see something like this then it’s working. If it just
sits there doing nothing then something’s not right, go back and check
everything.
This excellent free to use web site can be used to confirm
things are looking good. It will check all the important stuff like open
replay, reverse DNS, and the banner all check out.
·
Go to https://mxtoolbox.com/
·
Enter you mail domain (the bit after the @ sign) and hit the
button MX button
·
The site will look up your MX records and list out host(s) that
receive mail for it
·
You can now click the link “SMTP Test” on the server line and
some tests will be performed
·
Everything should all check out except for a warning that it “Does
not support TLS”
If you are only getting the TLS warning then I’d call that a
passed test.
Digging around this web site you can find many other tests.
Clicking the big green “Find Problems” button will set it off looking for all
kinds of problems, like “DMARC”, you can read through this site and fix these
problems if you like.
If you are seeing any more serious problems like “open
relay” then look into this immediately.
Run the following code substituting the mail server name and
“me@myemail.co.uk” to your real personal email address
using (System.Net.Mail.SmtpClient client = new System.Net.Mail.SmtpClient("mailServer"))
{
client.Send("myapp@mycompany.co.uk", "me@myemail.co.uk", "Hello
World",
"Test
Message Body");
}
Go and check your email, did you receive a message?
If you get an exception along the lines of “The server
response was: 5.7.1 Unable to relay” try using the local name of the SMTP host
not the external domain name. If that still fails make sure the host you are
running the code on is listed in the SMTP relay allow IP address list.
Use your personal email to send a message to “fred@test.mycompany.com”
or whatever domain aliases you configured, the local part “fred” can be
anything.
Go and look in the “Drop” directory you configured earlier.
You should see a file with a name like “4a67f54201d27c7f00000001.eml”.
Open this file with any email client program like Outlook or
Firefox. You should see a message that looks like any other email.
You can also open this file in notpad.exe and look at the
raw message. This is the standard RFC 5322 message format. In its simplest form
it starts with header lines, has an empty separator line, and then the body
lines.
Mail servers will send a NDR (Non Delivery Report) back to
the sender if it can’t send the message with details of the problem. This will
only work if the sender address is valid and the SMTP server is functioning.
Most SMTP servers will have an option somewhere to send a copy of NDRs to a
specified email address.
If the Windows SMTP server experiences problems it will log
events to the Windows “System” log from a source of “smtpsvc”.
There is also a directory with a default location of “C:\inetpub\mailroot\Badmail”
where it will drop messages it can’t send in certain situations. I’ve seen it
do this when it has trouble looking up the MX record from DNS.