Wednesday, August 28, 2013

How to test mailing functionality or setting up local mail server under windows


Sometimes you need to test how your application sends the mail (quite regular objective in QA). Whether the mails are properly configured, whether the mail list is properly configured, the attachments are in place etc. Sometimes you need to test if your application reads the mail in the expected way. At the same moment you do no like to use your corporate mail server or services like gmail as:
  • you have no all required permissions to operate with the server
  • protocol properties configured for existing server do not meet the production case
  • ports or other existing server properties do not meet the production case
  • you violate user agreement of the mail service if you load it with test traffic
  • you're working inside isolated network so all the outgoing traffic is prohibited
  • due to any other reason
The above restrictions do not leave the chance to go without your local mail server deployment.

Test sending the mail

Once you're going to only test e-mail sending feature you may manage with the tool called PaperCut. This is the simple SMTP server which does not push the mail to the addressees but just stores it and lets you to see it in three possible views: raw view, body view and html view. It does not require installation and starts working just by doublecliking its executable file. You are notified about new mails by the animation in your system tray. So, once your have PaperCut running, configure your appliaction to use the SMTP server set to the PaperCut host and test.

Test receiving the mail

If your application receives the mail or somehow operates with the mail on the server the testing might become a bit more difficult. So you obligatory need to setup the dedicated server. This post is mostly devoted to the basics of hMailServer deployment and configuring. hMailServer is running under Windows OS and have user-friendly administration. It also provides all the well-known mail protocols such as:

  • POP3
  • SMTP
  • IMAP

So, here is the example of environment topology that one could use to deploy e-mailing functionality test harness.
Test mailing topology
A couple of words regarding the picture. As it is seen, the mail server stands out of the other intranet cloud. That basically means that we should not allow that server to communicate with other network boxes to prevent the accidental mail delivery. Moreover the application server and tester station should not have any mail servers running or some mail port routing configured.
In my example I'm gonna use Win7 box to host the mail server of version 5.4.

Test scenario

The schema above may vary on the specific circumstances of your personal objectives. So lets guess script the mentioned topology will fit in the best way. I think the simple scenario might be the following:
  • Conditions: 
    • application uses one mail account to communicate with mail server
    • application reads the mail and then, say, parses it
    • parsed data is stored on the hard drive according to some application rules which we are aware of
    • we've got the way to customize the mail interface properties for the application
  • Steps:
    1. Send the mail to the mailbox the application is listening to
    2. Verify that the mail data is parsed according to the application rules
Step #1 looks conflicting with the mail server isolation statement. It really does in some case. In such the schema we'll not be able to send the mail to the isolated mail server account from anywhere except of another account hosted on that server. However lets get back to the problem a bit later.

hMailServer installation and configuration

In this section we're implementing the simple and working configuration of mail server 
  1. Download the distribution from here.
  2. Run the installer and just click Next for each request. Choose recommended Full Installation
  3. Once you're done the administrative console is started automatically
  4. Choose the only server you have yet and proceed (use the password you set up during installation process).
  5. You should now see the main administrative form where all the magic happens
  6. Add new domain. This is what will be following @ symbol in your mail addresses. It should conform your hosting address not to give the problems with mail routing inside your intranet - say, MAILHOST.SUBDMN.YOURCOMPANY.COM (the case does not matter)
  7. In this example we're gonna configure sender and receiver accounts. You may extend the steps for configuring accounts for other roles your application supports.
    1. Expand your domain, right-click Accounts folder and choose Add... from context menu
    2. Specify address and password for the account
    3. You've got the account created now. If you look at the corresponding tree item you see that the account is defined in "full qualified" style. It means that once you're attempting to connect to the server you need to specify that string as your server account. So add two account, specify the following addresses for them: sender, receiver
  8. You now should configure mailing protocols and privileges for certain IP addresses.
    1. So, to make our simple configuration working we may leave the protocol settings set to default values
    2. Lets now configure our IP ranges. IP ranges allow or disallow certain actions for the users whose IP address matches the specified one. To configure IP ranges you should expand the branch Settings\Advanced\IP ranges
    3. By default the server has two configurations which describe the privileges for the host where your server is running and the entire range of available IP addresses. In our example we are to configure the less secure configuration but providing the easiest way to access the mailing feature. 
      1. Click Internet item under IP ranges folder
      2. Check all the check-boxes under Allow deliveries from
      3. Uncheck all the check-boxes under Require SMTP authentication
  9. To ensure our server will be the finish point of any mail even addressed to the boxes hosted at some external domains block outbound SMTP port via the firewall

Configuring clients

We still need to be capable to implement our test script. So now we have the server configured and the last thing to do is to configure the clients. According to the script we should configure the following clients:
  • The application that reads the mail from the receiver box (requires POP3 configuration only)
  • Some convenient "well-known" mail client like Thunderbird where you'll be pushing your test mails from. (Usually mail clients imply both the protocols - for sending and receiving mails - are to be configured)
So use the following settings for your clients:
  • POP3
    • account
      • for sender: sender@MAILHOST.SUBDMN.YOURCOMPANY.COM
      • for receiver: receiver@MAILHOST.SUBDMN.YOURCOMPANY.COM
    • pop3 port: 110 (or that one you configured for your server)
    • authentication type: password
  • SMTP
    • account
      • for sender: sender@MAILHOST.SUBDMN.YOURCOMPANY.COM
      • for receiver: receiver@MAILHOST.SUBDMN.YOURCOMPANY.COM
    • smtp port: 25 (or that one you configured for your server)
    • Authentication: none
So having all your clients mapped to your local server you are free to play with your tests without the risk to send some unwanted mail to your colleague or clients :)

No comments:

Post a Comment