• your ISP is responsible for security — it needs to ensure that only messages from its own subscribers are accepted and messages from spammers or hackers are rejected.
  
• your ISP has the responsibility for making sure the message is actually delivered — and for advising you of any problems.

But There Is a Downside

You may be accustomed to using a good reliable mail server like smtp.melbpc.org.au but unfortunately that level of service is not universal. You need only refer to media reports of the troubles experienced by Telstra subscribers to be aware that ISP mail servers can have their problems — especially with all the additional pressures, courtesy of computer virus and Trojan activity.
 

So with that in mind, note that when you send an e-mail message via your ISP in the normal manner, all you know is that the message was accepted by your ISP's mail server. You do not know whether: Your ISP was able to send the message or whether it had to be delayed (queued) because the recipients mail server could not be contacted. Messages are sometimes delayed for hours or even days and the sender is not always made aware of this. Some error or malfunction on the part of your ISP caused your message to be lost and not sent. This is by no means a remote possibility — instances of such problems have beset at least one major ISP in recent months. In short, you have no guarantees. If your message was important, you have no way of being certain it was sent or received. On the other hand, it is possible to run software on your own computer which does exactly the same job as the server run by your ISP. (See Figure 2). This software (a local SMTP server) can:

Figure 2

• receive a message from your normal e-mail client program (also running on your computer),
  
• send that message directly to the recipient's mail server,
  
• maintain records which you can easily access, telling you of the status of all message you have attempted to send.

This provides you with full accountability — if any message you send is important you can tell immediately if and when it reached the recipient's mail server. If there is any delay or problem you will have that information available immediately.

So, to summarise, using your own mail server to send your mail can give you much better accountability and information about your mail deliveries.

It also gives you ample opportunity to learn more about exactly how mail works.

There are similar arguments about the topic of receiving mail and I will deal with that in a later tutorial. For now let's concentrate on what is required to send email direct.

What do I need to use my own mail server to send mail?

1. Firstly and most importantly, you need an ISP that does NOT block port 25 — the TCP port used for sending mail. Unfortunately a number of Trojans use port 25 for exactly the same purpose we want to use it — to send mail direct. In the case of the Trojans, that means your system sending infected messages or junk mail.

For that reason some ISPs block the use of port 25 to any destination other than to their own mail servers. Melb PC dial-up is one of those ISPs and if your ISP does this, unfortunately you will not be able to install your own mail server. WestNet has also recently blocked port 25 by adding it to its Access Control port filtering service. You can unblock it by turning off Access Control but you must be aware that in doing so you will open up all other ports blocked by that facility.

2. Secondly you need a commonsense approach to security. Using port 25 to send mail is not especially hazardous but you need to ensure that you have a good and effective firewall, that your operating system updates and antivirus definitions are up to date and that you regularly scan your system for Trojan activity. These are all things you should already have well in hand.

3. And you need the server software itself — for this tutorial we will use a very reliable, freeware product named Mercury.

Note for WestNet users

For Westnet users to allow port 25 access you can turn off Access Control at https://myaccount.westnet.com.au/Services/AccessControl.
 
Because other previously blocked ports are also unblocked by this action, the need for your security to be watertight, as described in point 2 of the previous section, is paramount. For broadband users that shouldn't be an issue provided that you have a router correctly set up as per the following article http://www.melbpc.org.au/pcupdate/2410/2410article8.htm.

Note for users of Windows XP Professional Edition

It is possible that you may already have the Microsoft IIS Mail Server installed and possibly even active on your system. This would prevent any other mail server from operating on your system. Unless you are totally conversant with the operations of the Microsoft server (in which case you are unlikely to require this tutorial) I recommend you disable it and install Mercury as shown in the next section of this tutorial, so that you can follow the tutorial as presented.

You can check whether you have this server installed by opening the Services Window (Start Menu | Control Panel | Administrative Tools | Services) and look for the entry "Simple Mail Transfer Protocol (SMTP)" as highlighted in the screen shot (Figure 3) adjacent. Right click on the entry to set it "Stopped" and "Disabled".

Downloading and Installing Mercury

Download the Mercury installer from ftp://pegasus.topnz.ac.nz/pegasus/mercury32/m32-401a.exe. You can
install (and run) Mercury from a standard (non Admin) account if you wish. The installer does a good job of guiding you through a number of setup issues to ensure your mail server is correctly and securely installed. But you may need a little guidance along the way.

Firstly, early in the installation you will be prompted concerning Netware Support and Pegasus Mail Integration. You do NOT require either (although Pegasus Mail Integration may be useful if you are actually running the Pegasus mail program).

Some of the later screens are as follows:

Mercury is modular. When the screen shown in Figure 4 appears, the modules you need are those shown in Figure 4, previous page.

When the screen in Figure 5 (previous page) is displayed — select "Install MercuryE"

When the the screen shown in Figure 6 displays, if you have a domain name, enter it in the first field. If not press the Help button and follow the advice given. Leave the second field as is.

When you are asked to select an SMTP Relaying Mode, as in Figure 7, IMPORTANT - Select "Strict" relaying mode.

Once Mercury installation is complete, fire up the Mercury program (you can run it from a non Admin account if you wish) and continue with the configuration.

Post Installation Configuration

From the Mercury Window menu, select Configuration, Protocol Modules. In the Window (Figure 8) that appears select ONLY these modules shown selected in Figure 8. Then restart Mercury.

Select Configuration, Manage Local Users. Set up a username in the manner shown in Figure 9. This will be used later for receiving mail. The (local) username can be anything you wish - it does not have to be your Melb PC username.

Select Configuration, SMTP Server. Using the "Add restriction" button enter the IP numbers of computers on your local network which are allowed to send mail via this server (see Figure 10).

If you are using a local network you may find it simpler to add the network range (eg. for an NB1300 route add the range 192.168.1.1 - 192.168.1.254.) That would enable any computer on your local network to connect to Mercury.

Make sure "Use strict local relaying restrictions" is ticked, as shown in Figure 10.

Select Configuration, Mercury Core Module. Check that the settings al similar to those show in Figure 11. Especially make sure the "Hard to quit" item on the General Tab is ticked, so that Mercury cannot be shut down accidentally.

Save your configuration by holding down the Ctrk key and selecting File Exit to quit Mercury and save all settings.

Then restart Mercury

That completes the configuration of Mercury and you are almost ready I see if it actually works. But before we do that let's review the most important aspect of this exercise.
 

Security and Relaying

The important thing to understand that once you are running a mail server which is visible from the Internet, you will have intruders trying to use your server to send spam. It is absolutely vital that your sever is correctly configured so that accepts requests to send (relay) messages only from computers which are entitled to do so — in our case, from your local computer or from computers on your local network. When (and I say when, not if) when intruders contact the server, that contact must rejected.

Should your server be incorrectly configured to accept unauthorised contact (such a server is known as an open relay), all mail emanating from your ISP may be banned by other mail servers. So get this wrong and you will not be popular.

At this moment, we are only using our server to send mail and we have addressed this important issue in two ways:

1. The SMTP server configuration shown in Figure 10 has been set to "Strict Relaying" — accepting messages only from IPs we specify.
   
   
2. Because we are using the server only to send mail, we can (for the moment) set our firewall to ensure the server is invisible to the Internet. Details of these settings follow.

Firewall Settings

Set your firewall as follows:

1. Mercury needs to connect outwards to the Internet — otherwise it can't send out mail.
   
   
2. For now Mercury doesn't need to be able to accept inward connections from the Internet (ZoneAlarm calls this 'server access'). But it does need to be able to accept inward connections from your local computer and from any other computer on your local network that you wish to use to send mail via this server. For ZoneAlarm that means that you allow server access only from your your "Local Zone".

Once you have set your firewall in this way, and with Mercury running, go to http://grc.com and use the "Shields Up" test to ensure that port 25 is not visible from the Internet. This test must report port 25 as "closed" or "stealth".

With that done, you can be sure that your server is secure. If you have any concerns, reboot your system and test it again, just to be sure everything was correctly saved.

In the second part of this series, when we use the server to receive mail, I will show you how to use an external service specifically designed for mail relay testing, to ensure that your configuration is safe.

Although the consequences of poor mail server security can be serious, there's no need to be unduly alarmed —just be careful. Follow the directions given here and you won't have a problem.

Configuring Your e-mail Client

Setting up your e-mail client program to use your own SMTP server is simple — simply change the server to "localhost" as displayed in Figure 12 — or if you are using a local network — to the local IP of the machine running Mercury). See Figure 12. Changing the server details in Outlook Express.

Now you're ready to see if it works. Send a message to your normal ISP account and see if it arrives OK. If so, you now have a means of sending e-mail messages independently of your ISP's mail server (see Figures 13 and 14).

Monitoring Your Mail Server

Now that you have been able to send your message. lets look at how the Mercury console window enables you to easily monitor the activity of your server. And if by any chance, your attempt to send a message didn't work, fear not. This section will help trace the problem.

Switch to (and preferably maximise) the Mercury window. Use the Window Tile command to have the three monitor windows visible. You should get an arrangement like that shown in Figure 15.

The two Windows that will help us most are the SMTP Server window and the SMTP Client Window. Let's look at those in more detail.

The SMTP Server window shows your local computer (127.0.0.1 in this case) connecting to the Mercury mailserver. If there were any problem with your access control settings it would show here (Figure 16).

If your firewall settings were preventing the connection there would be no entry here.

In this instance there has been a successful connection and Mercury has accepted our message for delivery to the remote server.

The SMTP client window shows a shortened form of the dialog between Mercury and the recipient's mail server — in this case the Melb PC mail server (Figure 17).

If there were any problem with contacting the remote server — or if the remote server refused delivery for an reason, it would show in this window.

Here you can see clearly that the message was received and accepted by the recipient's mail server.

You can also view some of this information in more detail by looking at log files that are created by Mercury and at other reports generated by the Console Window. I will deal with these matters in more detail in the next article in this series. But you can already see that information about the status of messages and details of whether and when they were received by the recipient's mail server are readily available to you.

Possible Problems

You should find that sending mail messages direct using Mercury will work quite reliably and with immediate feedback. But you should be aware that for various reasons, mail sent in this way by ordinary users has a greater chance of being flagged as spam or even being rejected. Melb PC/WestNet ADSL users who have selected the static IP option will be less affected than those using a normal dynamic IP (where the IP address changes at each log in). I will discus this issue (and some remedies) in the next part of this series.

What Have We Achieved?

This has been a fairly long and if involved tutorial, particularly if the subject is new to you. But you should have achieved the following:

1. You should have gained an understanding of why running your own mail server might be beneficial
   
   
2. You have successfully installed and configured the Mercury mail server
   
   
3. You understand why great care needs to be taken to ensure the server cannot be misused by intruders and how correct server and firewall setting can prevent misuse
   
   
4. You have sent your first message using Mercury
   
   
5. And you have seen how the Mercury console provides exact information about the progress (or fate) of any messages it sends.

There's quite a bit more to be covered but that will have to wait for Part Two of this series. It's an interesting topic.