A simple understanding of autodiscover is that it is the configuration necessary to allow advanced email programs like macmail and outlook to configure themselves with only an email address and password. No more telling clients all the server settings necessary to get them all setup.
At least that is the theory.
Exchange server has supported it for some time, but configuration under a multi domain setup is a total pain in the butt. Typical off MS to dream something up, then balls it up in the implementation.
SmarterMail does a much better job of it. Configuration is virtually non existent, it basically just works.
But their article is a little skimp for the non server admins.. so this is a step through course.
Assuming that you are using Microsoft DNS server for your DNS hosting (and I realise that most probably don’t but it is the more difficult to configure), this is how you add the SRV records mentioned in the article above.
On the DNS server, select New other record on the domain in question.
Scroll down and select SRV
Type the name: _autodiscover
Change the port to: 443
Put in your mail servers address that will respond to an HTTPS request.
The resulted record looks like this:
If you click on the _tcp link, it will look like this:
On your local machine, bring up a command prompt “CMD” and type in nslookup:
Type in “set type=SRV”
Then type in :_autodiscover._tcp.dnnform.com (replace dnnfrom.com with your domain that you just configured above) It should reply wiht the sver hostname matching the record you created in the DNS server above:
Performing an external test of the SRV record, and the fact that the server responds with XML reply.
The email solutions we provide at InteractiveWebs is capable of using a more advanced connection technology than POP3 and IMAP. Known as Exchange Web Services, the technology is a covenant and robust way of connecting to the mail servers.
All your email, calendars, contacts, and notes will reside on our mail servers. Your devices (computers, laptops, iPhones, and iPads) will link to our servers. This way, every device will see the same information at all times. If you view a message on one device, then you can see that message “as viewed” on all your other devices.
We have elected to use the latest technology for this service. At this time the only software that connect to Exchange Web Services are:
Mac Mail – Snow Leopard, Lion and later
Outlook 2011 - Mac and later
Outlook 2012 – Windows and later
How to setup Exchange Web Services Email
Follow these steps to set up Apple Mail to sync with Exchange Web Services
On your Mac, open System Preferences.
Click Mail, Contacts & Calendars.
Click Microsoft Exchange.
Complete the display name, full email address and password fields.
An account summary screen will display. Click Continue.
Click Add Account.
Apple Mail is now configured to sync with InteractiveWebs SmarterMail. Depending on how much data there is to synchronize, the first sync may take a few minutes.
iPhone and iPad Touch
The iPhone and iPad still use the IMAP connections to the mail server.
On the iPhone, tap Settings.
Tap Mail, Contacts, Calendars.
Tap Add Account.
Tap Add Mail Account.
Complete the Name, Address(email address), Passwordand Descriptionfields.
Ensure IMAP is selected.
Enter your incoming mailserver information:
Username is your full email address
Password as provided.
Enter your outgoing mailserver information:
Hostname is generally mail.interactivewebs.com.
Username is your full email address
Password as provided
The iPhone will attempt to establish an SSL connection to your IMAP and SMTP servers. If this succeeds, you will be done and can proceed to step 13. If this fails, you will see the prompt, "Do you want to try setting up the account without SSL?"
When prompted, "This account may not be able to send or receive emails. Are you sure you want to save," tap Save.
Tap the account you just added (identified by your email address)
Scroll down and tap the SMTP button.
Select the server you just added, identified by the hostname from step 9.
Select OFF for Use SSL.
Select Password for Authentication
Select 25 for Server Port.
Tap the SMTP button to go back.
Tap your email address to go back.
Scroll down to Incoming Settings.
Select OFF for Use SSL.
Select Password for Authentication.
Select 143 for Server Port.
Tap your email address to go back.
Tap Mail to go back.
Tap the Home button.
Tap the Mail App to check your configuration.
With the phone and iPad, it is possible to use a service that pushes email messages to your phone, rather than your phone being set to constantly run off and check for new messages. This saves on battery life, saves on data used on your monthly plan and ensures your email messages always arrive on time.
If it is important to you to have email messages when they arrive, then this service is what you need. Known as Active Sync, it can be enabled by us with a a small additional cost for each account. $5 per month.
Larger Mail Accounts
Because your email remains on our servers, it means that your accounts will grow and grow in size. This takes up resources on our mail servers (which is fine) but if you like to keep past history of mail sent, and all your arriving email messages, then you will need to extend the storage space of your mail account on our servers.
This can be done easily with a small monthly fee per account. $15 per month.
E-Mail Anti-Spam Settings
– Using Only SmarterMail Anti-Spam Tools and No Wizard
Beginning with SmarterMail 6, SmarterTools began incorporating some very powerful tools into the SmarterMail e-mail server software which made the control of undesired SPAM much easier.
Prior to version 6 of the SmarterMail software, it was necessary to maintain blacklists, build complicated tables of undesired words, phrases, IP address, e-mail addresses, and domains – all of which changed almost every hour.
The spammers knew the ISPs and e-mail server operators were up against a wall and, in spite of new state and federal regulations being put into place almost daily, continued to churn out ever more junk mail because they were unconcerned with being stopped or caught. With the introduction of SmarterMail version 6, the tide began to turn in favor of the e-mail server operators.
Between the more frequent adaptation of SPF, the general requirement of large ISPs that mail server operators have both IN-ARPA [reverse DNS] AND PTR records pointing back at the HOST and MX records of their respective mail servers, and the new tools being coded into the SmarterMail e-mail server system, e-mail server operators finally began to accumulate an arsenal in the war of the spammers vs the mail server operators.
In July 2009, ChicagoNetTech converted from IMail to SmarterMail version 5. Within a week of our purchase and conversation, SmarterTools introduced the BETA of SmarterMail version 6, and with SmarterMail Version 6 BETA, a powerful new set of anti-spam tools which would change our relationship with our customers significantly.
As ChicagoNetTech began to work with SmarterMail version 6 BETA, and experimented with various anti-spam configurations, and soon found the tools introduced with SmarterMail version 6 beta allowed some very powerful capabilities in the fight against spammers.
After testing with one of our minor domains, we decided to “flip the switch” and ran the new anti-spam settings we were using on just one domain on all of the domains. Suddenly, instead of complaints about the large quantities of spam users previously received in their in-boxes, we were receiving compliments about how pleasant it was to open their e-mail in the morning and find that everything in those boxes was 100% related to business.
The spam was gone, the customers were extremely happy, and we have not looked back since then.
In July of 2009, after assisting many SmarterMail admins on the SmarterMail forum with anti-spam issues, I decided to publish my settings for the benefit of everyone’s SmarterMail installations.
Since then many have adopted and, to their surprise, have had similar results to those we experienced from the beginning.
Unfortunately the software used for the SmarterMail forums allows for a limited number of characters in each post. Thus it was necessary split the original post into two sections. The forum software also limits the number of images in any given post and that has resulted in many questions as to the implementation of specifics relating to the anti-spam settings effectively implemented on our and other SmarterMail server operators.
This document will restate those settings, in somewhat greater detail, along with IETF specifications relating to why they work and why you should make certain you are in full compliance with both IETF requirements and recommendations.
The antispam settings listed below are the settings currently used by ChicagoNetTech Inc, an ISP in Chicago Illinois, with client base consisting primarily of not-for-profit agencies, healthcare facilities, and small businesses. ChicagoNetTech runs SmarterTool’s SmarterMail Enterprise version 9 – latest available software release.
These settings are based on SmarterMail Enterprise Edition, Version 9. Non-Enterprise, as well as versions earlier than version 9 may have slightly different settings or screens. More information about the differences in SmarterMail versions is available on the SmarterMail Version Comparison Page.
Many thanks for the proofreading and editing assistance provided by Jim Murphy of Digital Webby who is also a user of, and a regular in, the SmarterMail forums. 1. Setup your primary GREYLISTING settings:
To do this, login as the primary ADMIN for the SmarterMail server and goto: SECURITY è GREYLISTING è OPTIONS
– SELECT ENABLE GREYLISTING
– UNSELECT ENABLE USERS TO OVERRIDE GREYLISTING
– SET your BLOCK PERIOD – we use 4 minutes
– SET your PASS PERIOD – we use 360 minutes
– SET your RECORD EXPIRATION – we use 36 days
The Greylisting settings shown above reject an e-mail sent to your mail server by anyone who has not sent e-mail to your server for the past 36 days with a notification to the sending e-mail server that the message was GREYLISTED, in accordance with RFC 821. The Greylisting rejection message will include a notification that the sending server should RETRY the message again after a specific number of seconds. In our case the GREYLISTING BLOCK PERIOD is 4 minutes or 240 SECONDS
When someone who has not sent an e-mail to someone hosted on our SmarterMail server SmarterMail checks to see if they have e-mailed the intended recipient previously. If they have, and the previous delivery timeframe falls within the record expiration period, the message is allowed to be delivered, provided it does not meet other anti-spam measures.
If not, the initial Greylisting rejection response issued by SmarterMail is: “rsp: 451 Greylisted, please try again in 240 seconds”
If the sending mail server attempts to resend the original message prior to the 240 second wait period expiring, they will receive another ““rsp: 451 Greylisted, please try again in XXX seconds”, where XXX is the difference between the initial send time and XXX is the time remaining until the 240 second wait time has expired.
If they send the same message after 240 seconds, but do not wait longer than 360 minutes, then the mail server white lists the sending mail server’s ability to send to the e-mail address the message was originally sent to for a period of 36 days. Greylisting works for two reasons:
A. Because most spammers attempt to send an e-mail message only one time. They have so many spam messages in their outbound queue that they want to send them out as quickly as possible, and;
B. Because the International Engineering Task Force [IETF] states that all e-mail server must retry to send an e-mail message for up to a minimum of four  days if the message is not deliverable the first time.
The specific IETF rules concerning redelivery attempts are located at: http://www.ietf.org/rfc/rfc2821.txt, http://www.ietf.org/rfc/rfc3261.txt, and http://www.ietf.org/rfc/rfc3265.txt.
For more information about Greylisting, please see www.Greylisting.org NOTE: GREYLISTING WORKS ON A PER USER E-MAIL ACCOUNT BASIS. Just because email@example.com has been Greylisted for firstname.lastname@example.org does not mean that email@example.com is now Greylisted for firstname.lastname@example.org. Each time a sending e-mail address sends to a receiving e-mail address on your server which has not received e-mail from the sending e-mail address within the timeframe of the Greylisting table established for your server, they will have to be Greylisted for the receiving e-mail address to which they are sending a message.
Some users will balk at the initial delay imposed on the receipt of messages from “new” senders. Remind them that e-mail is not instant messaging and Greylisting is only a momentary delay – amounting to a mere 4 minutes, under the settings used in our example. You can also remind them that Greylisting plays an important roll in ensuring their e-mail box is not overflowing with junk mail every morning. They will get over it.
To make certain your SmarterMail server installation is properly trying to resend messages which may be Greylisted by receiving mail servers, or otherwise non-deliverable on a temporary basis, you can check your RETRY INTERVAL settings.
SmarterMail’s RETRY INTERVAL SETTINGS are located under: SETTINGS è GENERAL SETTINGS è SPOOL
IMPORTANT NOTE: YOUR SPOOL PATH MAY BE DIFFERENT THAN THE ONE SHOWN IN THE EXAMPLE BELOW. NEVER ATTEMPT TO CHANGE A SPOOL PATH ON A FUNCTIONING MAIL SERVER!
IETF retry requirements call for “shall retry for up to 4 days”, but they do not specify the frequency of the retry attempts. The sooner a message is delivered, the better. In reality however, technology does break down and is not always repaired immediately. Attempting to retry delivery too quickly might not allow a message to be delivered at all, so most ISPs have opted to try several times within the first couple of hours and then retry at longer intervals to allow the receiving ISP time to resolve non-receipt issues.
ChicagoNetTech has opted to run the following retry interval schedule: 15, 30, 60, 90, 120, 240, 480, 960, 1440, 2880 minutes after the initial attempt.
This schedule sets the first retry time for 15 minutes after the initial delivery attempt. If still not deliverable, message delivery is reattempted at 30, 60, 90, and then 120 minutes. After the initial schedule, the amount of time doubles for each successive retry attempt.
In all, the server attempts to retry the delivery for a little more than four days. This satisfies the IETF retry requirement of four days.
If you loose an incoming e-mail message because a server does not retry their deliveries after the first delivery attempt they are either a SPAMMER or non compliant.
If a sending mail server is non-compliant, you do not have an obligation to whitelist them because of their ignorance.
If the receipt of a blocked e-mail is important to you, and/or your client, you may want to try to figure out what caused the problem and notify the sending mail server administrator. DON’T GET CAUGHT UP IN THE AUTOMATIC WHITELISTNG TRAP!
If a valid ISP has a problem sending e-mail to your server, take the time to find out what the problem is. Your logs will reveal many of the issues for you. You can also use outside DNS testing tools to make certain the sender’s DNS is properly configured.
ISPs and e-mail server operators have an obligation to know how to properly configure both their e-mail server software, firewalls, server operating system software and their DNS records.
Ø DNS records include “A” or “HOST” records, “MX” records, “IN-ARPA” records, and “PTR” records.
Ø PTR is always setup on the LOCAL DNS server.
Ø IN-ARPA record mapping to the e-mail host must always be done by the INTERNET SERVICE or “bandwidth” PROVIDER – the company who provides the connectivity and IP ADDRESS range assignment to the ISP.
Ø You should also setup IN-ARPA mappings for any e-mail domains on your local DNS server(s) by creating reverse DNS mappings for your IP ADDRESS range on your DNS servers.
Ø RFC974, RFC1034 3.6.2, RFC1912 2.4, and RFC2181 10.3 prohibit the use of C-NAME records in MX or mail server host names. All MX records must be mapped to “A” or “HOST” records directly.
Ø ALL IP ADDRESSES ASSIGNED TO PUBLIC E-MAIL SERVERS MUST BE PUBLIC AND AVAIALBLE ON THE INTERNET! EXAMPLE: The only issue we have ever encountered because of GREYLISTING was with a vendor who does shredding for medical companies who was trying to send an e-mail to one of our customers. The vendor’s e-mail server was configured to attempt to send messages only once. It was not configured to retry if a message was non-deliverable.
When the sending e-mail server encountered the “rsp: 451 Greylisted, please try again in 240 seconds” message, they aborted the process and never resent the message.
When the client complained they had not received the message, we checked the logs and found the problem. The customer asked me to whitelist the domain and IP address and I said no, the vendor needed to fix the configuration of their mail server. I also told our customer I would work with their vendor to resolve the mail server’s configuration so it would not happen in the future.
After contacting our customer’s vendor and explaining the how Greylisting works, along with the requirements that their server must be compliant, the vendor resolved the issues with their mail server’s retry times and we have had no problems with delivery of their e-mail since. The customer’s vendor was unaware of the issue and glad to learn of the problem so it could be corrected.
Because our customer’s vendor’s mail server never attempted to resend the message never got past the greylisting. 2. Once you have configured the GREYLISTING SETTINGS, it is time to configure your ANTI SPAM according to the following settings.
These settings work because they IMMEDIATELY DELETE any incoming message which is found to be from a server that DOES NOT HAVE an IN-ARPA or REVERSE DNS ENTRY.
Messages received from any of the RBL or URIBL are IMMEDIATELY DELETED if they are on one of those lists. If you UNCHECK the column labeled ENABLE FOR SMTP BLOCKING, the CENTER column in the main antispam section, and run according to weights, these settings WILL NOT WORK and you will be back to fighting with spammers.
Protecting your e-mail server from spam depends on total server spam lockdown.
SETUP AN ACCOUNT WITH BARRACUDA CENTRAL and ADD THE BARRACUDA REPUTATION BLOCK LIST to your ANTISPAM settings.
Before you can begin to use the Barracuda Reputation Block List, you will need to setup an account at Barracuda Central. That account must be linked to the IP ADDRESS used by your e-mail server to RECEIVE e-mail. If you have multiple IP addresses for your SmarterMail server, as in a situation where you have hosted domains with dedicated IP addresses, you will want to list the IP address which is MAPPED TO THE HOST NAME OF THE SERVER ON WHICH SMARTERMAIL IS INSTALLED in your Barracuda account as that is the IP address which will actually contact the BRBL to do the lookup.
To setup your account go to http://www.barracudacentral.org/. Then go to the TOP OF THE PAGE and click on REQUEST ACCESS. This links to http://www.barracudacentral.org/account/register
Once your setup your Barracuda account you will need to configure your SmarterMail server to use it. To add your BRBL listing configuration goto: SECURITY è ANTISPAM ADMINISTRATION è ADD RBL.
Configure your new RBL as follows:
Once you have entered all of your data into the configuration box, then click SAVE and you have added your new BRBL too to your list of Antispam measures. B. NOW TURN ON the ANTI-SPAM SETTINGS per the SCREEN CAPTURES SHOWN BELOW:
Your SPAM CHECKS TAB is located at: SECURITY è ANTISPAM ADMINISTRATION è SPAM CHECKS A note about the settings for each of the line items below:
v Depending on the version of SmarterMail you have, you may not have some of the items shown below;
v Depending on the version of SmarterMail you have, you may have more items than are shown below;
v There is no need to modify the REQUIRED LOOKUP VALUE in any of the items listed below. They all map to localhost addresses in the 127.0.0.X range, where X is always greater than 1, because 1 is always reserved as the LOCALHOAST address in the HOSTS files in Microsoft operating systems.
v By checking the ENABLE FOR SMTP BLOCKING [center] column, all weights are overridden and meaningless. Weights are only used when the ENABLE FOR SMTP BLOCKINGcolumn is NOT checked.
v URBL: MailPolice no longer exists and was eliminated in June 2010. SmarterMail was supposed to have removed the URBL for MailPolice in Version 7, but when we installed SmarterMail version 9 it magically re-appeared in the antispam list. Whether you are running pre-SmarterMail version 7, or a later version of SmarterMail, with MailPolice still in the antispam settings, it is easily removed by highlighting, right clicking, and hitting DELETE. Even if left in, it no longer does anything because they are out of business.
v There is no need to check OUTBOUND messages for spam unless you have known spammers on your server, in which case you have a much bigger problem. Most outbound spam is caused by someone hacking your server and sending via one of your hosted accounts. Secure passwords can go a long way toward prevent having your server hacked and hijacked by spammers and are discussed elsewhere in this document.
v Note that we ENABLE REVERSE DNS FILTERING. This checks to see if the sending e-mail server has a public IN-ARPA or REVERSE DNS entry which maps to the sending e-mail server’s HOST NAME and IP ADDRESS.
v While not REQUIRED by the IETF, RFC1912 2.1 says you SHOULD HAVE a reverse DNS for all your mail servers. It is strongly urged that you have them, as many mailservers will not accept mail from mailservers with no reverse DNS entry.
v With ENABLE REVERSE DNS checked in the ENABLE FOR INCOMNG SMTP BLOCKING column, anyone who does not have BOTH an IN-ARPA or REVERSE DNS AND a PTR entry associated with the IP ADDRESS of their primary mail server will be unceremoniously disconnected and their message will not be accepted by your mail server. This is an extremely important antispam setting as most spammers will not make the effort to, or will be blocked from, setting up an IN-ARPA address.
v Anything checked in the “ENABLE FOR INCOMING SMTP BLOCKING” column will UNCEREMONIOUSLY DELETE an incoming message which meets the criteria. Mail Servers are notified you are using SMTP Blocking with the following message:
“554 Sending address not accepted due to spam filter”
v These settings do not use content filtering. I strongly suggest you do not use content filtering in addition to these settings because the maintenance of any content filtering is a maintenance intensive, self-loathing task which is never done. Should you choose to enable content filtering in addition to the settings suggested in this document, you may run the risk of having your e-mail server tagged as a spammer by BACKSCATTER.ORG, BARRACUDA, and SORBS. You do not want to put yourself in that position.
To DISABLE BACKSCATTER, goto SECURITY è ANTISPAM ADMINISTRATION è OPTIONS and make certain you have set CONTENT FILTER BOUNDING to DISABLED. It should be configured as follows:
Note: Your Auto-Responder, Spool Proc, and Catch-All settings may be different.
ü Your DomainKeys may be set to different values, ours are set as follows:
ü Your DKIM settings may be set to different values, ours are set as follows:
ü We have initiated some different settings for SPF records. Our SPF is set as follows: C. FILTERING:
The FILTERING settings are available under: SECURITIY è ANTISPAM ADMINISTRATION è FILTERING
We initially set our LOW PROBABILITY to PREFIX SUBJECT WITH TEXT [**** Junk E-Mail ****] to make certain we were not deleting legitimate e-mail.
Once you are comfortable with the new antispam settings, and are convinced you are not turning away legit e-mail, you can change LOW to DELETE if you like. If you are more comfortable with initially setting the MEDIUM or HIGH to PREFIX or MOVE, please feel free to do so.
In order to alleviate any confusion about what we show in the SMTP BLOCKING screen, I have include a capture from our SmarterMail setup below. Your settings may be different.
The following options are available under: SETTINGSè DEFAULTS è DOMAIN DEFAULTS è TECHNICAL
You will also want to make certain that your PRIMARY IP ADDRESS is properly mapped to your SmarterMail host’s server name.
Because we run TLS on the mail server [available in the Enterprise edition only], and run SSL, we have ALL of our clients setup to use the IP ADDRESS which is bound to our SSL/TLS.
In the event of a failure of that IP ADDRESS, SmarterMail will automatically pick up with the primary IP ADDRESS of the NIC card, which is also bound to all domains, but not as a primary.
Our two MX records point to:
v SECUREMAIL.CHICAGONETTECH.COM, with a PRIORITY of 5, which makes that our PRIMARY e-mail server, running on an IP ADDRESS of 126.96.36.199, and;
v FIFI.CHICAGONETTECH.COM, with a PRIORITY of 10, makes that our SECONDARY e-mail server, running on an IP ADDRESS of 188.8.131.52
Make certain these are both setup in DNS, with the appropriate HOST NAME records, MX records, and PRT records pointing to the HOST NAME records.
The MX record number which is the LOWEST will always be the first to be attempted when e-mail is delivered to your server from outside your domain.
You will also want to have your internet service bandwidth provider, the company who allocates your static IP ADDRESSES, map IN-ARPA or REVERSE DNS entries back to those HOST NAMES for your MX records.
These settings are available under the SmarterMail primary ADMIN account via: SETTINGS è PROTOCOL SETTINGS è SMTP OUT:
v The OUTBOUND IP is the DEFAULT OUTBOUND IP for all domains hosted on your SmarterMail server. If you host multiple domains with separate IP ADDRESSES assigned to those domains, or you have SSL setup to use a specific IP ADDRESS as would probably be the case if you have enabled TLS, then you may need to change this default IP ADDRESS for specific domains or services.
v If you run more than one domain on SmarterMail, remember to check the OUTBOUND IP address for each domain you host. This can be found by selecting the domain, EDITING the domain settings and then navigating to the TECHNICAL TAB and selecting the OUTBOUND IP address from the drop down box. If you should ever have to change IP address ranges, or add additional IP ADDRESSES to the server hosting your SmarterMail installation, it will be necessary to change the outbound IP ADDRESS in EVERY domain you host via these settings.
v DO NOT CHECK the DISABLE GREYLISTING box. If it is checked, UNCHECK it. Allowing users or domains to disable greylisting will override one of the most important aspects of your new anti-spam settings and result in your users, once again, being deluged in spam.
v The EXCLUDE IP FROM RECEIVED LINE was added in SmarterMail version 9. While this may be something which is perceived as being needed by some admins, I highly recommend NOT checking this box.
v In our case, we have TLS enabled. TLS is an encryption protocol which became available in SmarterMail 8.
v Beginning with the most recent versions of SmarterMail 9, TLS is available on a PER DOMAIN basis and is enabled or disabled only after enabling TLS on the SmarterMail server, via the TECHNICAL TAB under EDIT DOMAIN. TLS must be enable in BOTH AREAS for TLS to be available for a domain.
So, now that I have told you we have TLS enabled, you may wonder, what does TLS do and why is TLS important?
TLS enables the full encryption of e-mail, along every step of the message chain, from the desktop to the recipient, where the inter-transport e-mail servers also support TLS and an SSL encryption is used between the desktop and the SmarterMail server.
ü TLS uses PUBLIC KEY CERTIFICATES to verify the identity of the endpoints;
ü In the case of e-mail servers, these endpoints are the SMTP servers which interconnect to transport the e-mail messages;
ü TLS is the upgrade to the SSL protocol which is now partially depreciated.
ü Both work under SSL certificates;
ü Implementation of SSL in SmarterMail requires you run SmarterMail under IIS and disable the SmarterMail web server;
ü The full benefit of TLS is realized only if e-mail originates either via an SSL web interface or a TLS or SSL encrypted client, whether desktop or SmartPhone;
ü TLS is included only in SmarterMail Enterprise edition;
For more information about SSL/TLS, see: http://en.wikipedia.org/wiki/Transport_Layer_Security. For information on how to implement SSL/TLS in SmarterMail, see my post at: http://forums.smartertools.com/showthread.php/29845-SM-9-x-and-SSL-(Free-Version)
If you decide to implement TLS on your SmarterMail server you should then test your server to make certain your implementation is working properly.
To test either your SmarterMail TLS installation, or any other e-mail server which claims to be TLS enabled and capable, you can use the free testing tool at: http://www.checktls.com/perl/TestReceiver.pl
Once you have opened the testing website, use the drop-down and select CertDetail after entering a full e-mail address for the server you wish to test. Use the e-mail address of Test@CheckTLS.com to see demonstration output for a properly configured TLS e-mail server.
Here is the summary output for the test e-mail address:
CheckTLS Confidence Factor for “Test@CheckTLS.com”: 100
In the example above the e-mail address, email@example.com shows that the e-mail servers used by checktls.com are both capable of fully supporting the TLS encryption protocol and the SSL certificate is both valid, not expired, and properly installed on the server.
The CertDetail level test performed will also generate approximately 5 pages of test data showing all negotiations, results, and certificates used during the testing process.
If this test positively validates a TLS server, then the server is both capable of, and properly configured to use, TLS negotiations and encryption during the process of sending, and receiving, of e-mail messages. Failure to encrypt e-mail in today’s hacker rich environment can cause unwanted and undesirable results in today’s hacker and corporate raider environment. Every e-mail server operator should consider upgrading their mail server to support TLS and SSL. Read on, McDuff!
RESULTS FROM A NON-TLS COMPLIENT E-MAIL SERVER, or How the FBI and Scotland Yard Shot Themselves In the Foot: For an interesting sidebar on how the lack of TLS got the FBI and Scotland Yard into trouble with the nefarious group Anonymous, see the following blog:
Here is the FAILED TLS test from the FBI’s e-mail server:
It was not just the FBI’s e-mail server which failed the TLS testing, but the e-mail servers of intelligence groups the United States deals with on a day-by-day basis as we attempt to prevent infiltration of government, military, corporate and personal e-mail communications.
Had TLS been properly installed and tested on the e-mail servers of the various intelligence communities involved, the incident outlined in the blog would probably never have happened.
Out of the six intelligence agencies involved, only three passed the basic TLS encryption security capabilities on their e-mail servers.
v E-Mail servers which run Greylisting may require a second test after a few minutes to display completely accurate results.
v Failure to validate an e-mail address as part of the test does not mean the TLS enabled e-mail server has failed the TLS testing.
E: SETTINGS è PROTOCOL SETTINGS
Make certain you are not an open, or partial open, relay: [Your SMTP BANNER may be different. I keep ours up to date with the current VERSION information whenever we update.]
F: PASSWORDS – the Bain of Every Administrator:
To check your password requirement settings, goto SECURITY è ADVANCED SETTINGS è PASSWORD REQUIREMENTS
and modify your password settings as necessary.
We currently require passwords to be a minimum of EIGHT  characters in length with at least ONE UPPERCASE LETTER, 1 NUMBER and 1 SPECIAL CHARACTER in the password.
We do not allow any exceptions to the password rule. This prevents a lot of headaches because it eliminates short and simple passwords and prevents having our mail server hacked.
Note that setting a minimum of 8 characters does not preclude longer passwords as SmarterMail does not check for a maximum password length. This is actually a good thing because it allows your users to use PASS PHRASES.
So, with the settings show above, both: “rG#34_1@4b” and “meYe d0Ggi3 hA$ f133Z” are acceptable passwords – with the second actually being a pass phrase, which is longer, and easier to remember than the first. They both meet the secure password requirements shown in the password configuration screen below, and they are both secure.
Generally speaking, the longer the password or pass phrase, the more secure it is, and the less likely it is to be hacked by spammers, and the safer your SmarterMail installation will be:
NOTE: leaving the DISABLE PASSWORD STRENGTH FOR EXISTING PASSWORDS box checked will allow users to keep passwords which DO NOT meet the defined password requirements.
Leaving this blank will force everyone to change their passwords to meet the new requirements.
G: FURTHER PROTECTING YOUR SMARTERMAIL E-MAIL SERVER REPUTATION
To help protect your SmarterMail installation, you can do a couple of additional things:
Ø Setup an SPF record which points ONLY to the IP ADDRESS or IP ADDRESSES authorized to send messages from your e-mail server(s). Do NOT use a range. Setup specifically for the e-mail server, or servers, allowed to send. For more information see: http://www.spfwizard.net/
Ø Setup both DOMAIN KEY and DKIM signing: NOTE: DOMAIN KEYS ARE SPECIFIC TO THE DOMAIN. EACH DOMAIN MUST HAVE A UNIQUE DOMAIN KEY CERTIFICATE.
v These keys are setup on a PER DOMAIN BASIS via the MANAGE tool for the domain.
v To setup DOMAIN KEYS:
Ø SELECT THE DOMAIN FOR WHICH YOU WISH TO CREATE THE KEY
Ø SELECT MANAGE
Ø SELECT SETTINGS è DOMAIN SETTINGS è ADVANCED SETTINGS è MAIL SIGNING è OPTIONS.
v Enable BOTH ENABLE DOMAIN KEY SIGNING and ENABLE DKIM SIGNING
v Then click on the tabs CERTIFICATES, DOMAIN KEYS SIGNING, and DKIM SIGNING, and complete the forms according to the HELP FOR THIS PAGE from SmarterMail. They have done a pretty good job with this section of the help files.
Here is a picture of the process of generating the certificate required for DOMAIN KEYS. Note that the KEY SIZE can be selected as 512, 768, and 1024. Shorter keys require less work on the part of both the sending and receiving e-mail servers but are less secure. The longer the Domain Key certificate, the better.
Most modern e-mail servers can handle 1024 bit keys without any problems.
v Note the TXT record name? Domain Keys are added to your DNS as TXT records.
v First enter a SELECTOR to differentiate your domainKey and give it a name.
v Now Generate Key. This will both create the TXT Record Name and the TXT Record Value.
v When you add them to the DNS record, the only portion of the TXT RECORD NAME you enter into RECORD NAME portion of the DNS is, according to the example above, is “CNT.domainKey”. [without the quotes]
v The Microsoft GUI DNS tool will automatically append your domain name to the TXT record and create your domainKey certificate record.
v If you are using DNS other than Microsoft’s DNS, consult your DNS to see how to add a TXT record.
v The TXT Record VALUE is your actual certificate and goes into the TXT box of the TXT record. Save both the new TXT record value in SmarterMail and the newly created TXT record in your DNS for the domain, and you should be able to click on the TEST DNS and receive a PASSED notation at the top.
A test of a successful generation, and DNS install, of your domainKey certificate will look like this:
An explanation of DOMAINKEY SIGNING and DKIM SIGNING can be found in the SmarterMail KB at http://help.smartertools.com/SmarterMail/v9/Default.aspx?p=_SA&v=9.0.4408&lang=en-US&page=domainadmin%2ffrmdomainkeys
For more information on DOMAIN KEYS see: http://en.wikipedia.org/wiki/DomainKeys_Identified_Mail and http://www.dkim.org/
H: TEACH YOUR USERS NOT TO RESPOND TO PHISHING E-MAIL MESSAGES!
Sorry if I appear to be shouting, but the long, ALL CAPS, bolded title was deliberate.
General rule of thumb: If you don’t recognize the sender, or were not expecting an attachment, DO NOT OPEN THE MESSAGE – DELETE IT!
Phishing e-mail responses cause more problems with compromised e-mail accounts, identity theft, and compromised business networks and workstations than all other problems combined.
No matter how much you secure your e-mail server, no matter how well you protect your network, no matter how good the tables in your firewalls are constructed, all it takes is one hair-brained user sharing personal information with a total stranger to undo all of your hard work.
The FTC has published an excellent article on Phishing scams, which is available as a FREE PDF from their website, in both English and Spanish, that is both well written and easy to understand.
The FTC’s Phishing Scam article is available on the FTC website at: http://www.ftc.gov/bcp/edu/pubs/consumer/alerts/alt127.shtm
A downloadable, and re-distributable, PDF version is available at: http://www.ftc.gov/bcp/edu/pubs/consumer/alerts/alt127.pdf
If you are an ISP, make this available for download, via a link from your website or e-mail FAQ page, so that every person who you provide services for has an opportunity to read it.
For your business customers, you have an excellent opportunity to help them run a tighter workplace by making this available to them for distribution to their employees.
If you are a business, you might consider making the FTC’s PDF part of your employment or IT security manual which you distribute to all employees when they are hired.
Once you have your new antispam settings configured you will be able to monitor your server and see the actual results of your efforts.
First, you will have to make certain your logs are set for DETAILED recording of all log data. To do this go to SETTINGS è LOG SETTINGS andmake certain you have your logs set to DETAILED for both DELIVERY and SMTP.
Once you have your logs set for detailed logging you can search. Logging can only be performed by SmarterMail admins. To view your SmarterMail logs, go to MANAGE è VIEW LOGS.
Ø Search both the DELIVERY LOGS and the SMTP logs [be certain to check the ENABLE RELATED TRAFFIC BOX] for
v “rsp: 554 Sending address not accepted due to spam filter“.
v The results will show you which messages were denied messages because of spam and why they are being denied.
Ø You will also be able to see both the spam tests, and results, for the delivery of all other messages processed by the server.
Ø [NOTE: We designed our servers with enough capacity to keep all logs for a minimum of FIVE  years because of our medical and healthcare clients. This is in compliance with the new HIPAA / HITECH Agency requirements which were made law in October 2011.]
Ø By using these settings we have close to ELIMINATED our spam problem. It CAN be done and it does not take a lot of effort or extra cost.
Ø Get rid of content filtering. It is a pain to maintain and will drive you crazy trying to stay ahead of the spammers and hackers as they come up with new ways to get around your content filters.
Ø Do not use the wizard. Use the capabilities of the built in antispam tools in SmarterMail to your advantage.
Ø LIMIT WHITELISTING. A well created and properly setup e-mail servers should not have to be whitelisted. Poorly designed and improperly setup e-mail servers are not our problem. They are indicative of someone who does not know what they are doing who should not be running an e-mail server in the first place. It doesn’t cost a lot of money to setup an e-mail server properly.
Ø If you encounter a problem you would normally whitelist, search out the real problem and inform of the administrators of the domain with the problem about the issues.
Ø Ask the administrators with improperly setup e-mail servers and/or DNS servers to correct the problem on their end. There are several free and paid DNS testing tools available via searching the Internet which can assist you in troubleshooting those issues.
Ø Run REPORTS:
v Go into REPORTS è SPAM AND VIRUS REPORTS è GREYLISTING and set a date range to see how many e-mail servers never re-send because they are spammers.
v Reports can also be created on both a SERVER and DOMAIN LEVEL. You can also create custom reports and have them e-mailed on a regular schedule.
v Other reports are available as well. Experiment with what is already built into SmarterMail and see how well your server is doing and what resources your customers are using.
Once you have configured these settings, monitor your server for a while. You should see a huge improvement in the amount of spam you process immediately.
Will these settings completely eliminate spam? No. Even with these new antispam settings in place on your SmarterMail installation you may, occasionally, see some spam creep through and end up in user’s mail boxes.
You can help prevent this from happening by making certain you do not allow your users to override greylisting or spam settings. Doing so will both allow spam to start to come through again and will also cause you hours of support headaches and ill will with our customers and users.
Spammers make large amounts of money off the relatively small percentage of people who respond. In the case of identity theft, the result is often years of working to resolve unauthorized charges on credit cards, money stolen from bank accounts, and ruined credit. As SmarterMail operators we have an obligation to protect our users from all kinds of spam.
Even with these new antispam settings in place on your SmarterMail installation you may, occasionally, see some spam creep through and end up in user’s mail boxes. Using these settings provides no guarantee that you will not have any spam.
Much of what you are likely to encounter is joe-jobbing, for which very little can be done except to ride out the storm.
You may also encounter spam from spammers who have setup e-mail servers which meet all of the requirements set forth by the IETF and are not trapped by these filters.
You can help prevent this from happening by making certain you do not allow your users to override greylisting or spam settings. Doing so will both allow spam to start to come through again and will also cause you hours of support headaches and ill will with our customers and users.
Finally, and I cannot impress this frequently enough, make certain you enforce SECURE passwords. Secure passwords are at least eight  characters in length, and require a combination of UPPER and lower case letters, numbers, and special characters. This will eliminate insecure passwords; eliminate the possibility of your users from using the names of family members, pets, and friends; and will also eliminate words which are in the dictionary. J: NEED HELP?
IT has changed significantly in the 40-plus years since IBM was kind enough to underwrite the classes I initially attended while in high school. It is no longer about plugging cables into boards on accounting machines or writing code with a 16K limitation on available memory. We no longer enter data via 80 column punched cards and read the results off of printed paper, and we don’t have to wait hours or days to see a result.
The best thing about working in IT is the fact that our field is constantly changing – and constantly challenging.
The SmartPhones we now carry around with us have more than 100,000 times the computing power of the computers sent up in the original Mercury and Gemini space programs and 10,000 times the computing power of early mainframes.
Even for an experienced IT tech: someone who has come up through the ranks, answered the calls on the help desk, can troubleshoot PCs, Macs and printers, in his or her sleep, giving tech support via a hands-free cell phone call while driving down a busy expressway; setting up an e-mail server, even an e-mail server with the reliability and integrity of SmarterMail, can be a daunting endeavor.
The devil is always in the detail! The detail required to properly setup modern IT has so many different aspects to it that locating something that is “not quite right” can completely disable the proper operation of many different aspects of a network but improper configurations are especially significant where e-mail is concerned.
A forgotten HOST entry, selecting the wrong IP address, forgetting to map an MX record to a HOST NAME, not mapping DNS to the DNS servers setup when a domain name was purchased, wrangling with DNS for e-mail and IIS when having to maintain the integrity of DNS for Active Directory, failing to setup IN-ARPA – all of these have a potential to disable any e-mail server’s ability to send and receive e-mail properly.
SmarterMail users are exceptionally fortunate to have an incredible community of users who participate in the forums provided at http://forums.smartertools.com/forumdisplay.php/14-SmarterMail.
If the forums cannot provide everything you need, then the SmarterTools Knowledge Base is available for further research at: http://portal.smartertools.com/KB/browse.aspx
Remember, SmarterMail gives two free support tickets with the purchase of each product. Those tickets can be used to open support cases with SmarterMail, and, if your trouble turns out to be a bug, the cost of the ticket is refunded back into your account. This is a HUGE benefit of using SmarterMail over some of the other products on the market.
Finally, if you are just setting up a new SmarterMail installation, you can always request support from one of the members of the forum. Simply click on the member’s screen name and select the option to send a private message.
The Bulk Email module for DotNetNuke has a feature known as Bounce Email Monitoring, and it is probably a good idea to understand what it does and how it does it so we can explain how best to configure it.
Sending a Bulk Email Message
When an email message is generated using the DotNetNuke Bulk Email Module, a list of all the email addresses that you have selected from multiple sources is generated into a database.
The lists that you select can include.
Custom Lists that you import
Microsoft CRM Marketing Lists
Imported contacts from email programs
Custom typed email address
Once the list is complied, email addresses are removed.
Email addresses on the unsubscribed list
Email addresses on the bounce email list (that meet the requirements set)
Then the email messages are sent out and ticked off as being sent.
You can see that bounced email addresses will only be removed if they are on the bounced email list, and have bounced to a count matched the settings configured.
How the Bounce Email List is Generated and Counted
Periodically, the module will use the setting for the POP 3 account to look for email messages that it can add as a bounce. To do this, it will download all messages in the mailbox and look using some complex searching tools for email messages that appear to have bounced back from a failed send attempt.
Unfortunately email servers report bounce messages in different ways, so the code that reads the email messages and looks for bounce backs is long and complex. For this reason, the process of finding bounce messages should be kept to a minimum to reduce the load on the server.
The best way to reduce load is to minimise the number of mail messages that the process needs to check.
The best way to do this is three fold.
Send email from a unique email address that suggests no normal communication should run through that account. firstname.lastname@example.org is my suggestion. That way the only email messages in that mailbox should only ever be bounced messages.
Delete processes messages. The module can do this for you, but if the mailbox is a normal account, then ensure it is basically kept empty.
Manually delete messages that are not bounce messages. If you intent to use a general account, then you should keep it as free as possible from general communications.
What happens if you don’t do this?
The process of downloading thousands of email messages, checking them all and processing them all can take hours. It will put a huge load on both the web server and your email server. It will increase your data transfer costs both on your web and email server.
So follow the suggestions and the result should be clean and fast.
Outlook hangs caused by PayPal messages template fault
In just the last few days, I have started experiencing some issues with Outlook when opening messages sent from PayPal.
This is happening with the recent versions of Outlook, including Outlook 2010 and Outlook 2007.
Some of the indications of the problem include.
Outlook taking longer than normal to open.
Outlook with “Reading Pane” on
Outlook Stops Responding when clicking on an email from PayPal.
If you wait a long time, it will come good, and even show the email message.
If you are impatient and cancel out of outlook, your reading pane is gone when you next open it.
It appears that the cause of this is some malformed tracking cookies being sent from PayPal.
While it could be argued that Outlook should handle this invalid link much better than it does… We all know that Microsoft is responsible for Outlook, so really we should not expect too much in the way of “graceful error handling”. (After 20+ years of Windows system events, they still don’t have an online library of error codes and meanings.)
At the bottom of the message, there is a hidden tracking image. Instead of this image pointing to a web server, it is pointing to a non-existing network share. As it is pointing to a network share and not to a web server, Outlook’s “Internet picture blocking” functionality doesn’t kick in and tries to retrieve the content.
So what to do what to do?
First, I know for a fact that PayPal is aware of this issue, and while it is literally a 10 min fix for the right person, we know that finding the right person probably means contacting the dev team out of India that they hired last month, and asking them to fix their crap!
Oh I have been doing this too long!
Really… what to do!
Nothing… If you are patient when opening email messages from PayPal while this issue happens, then they will open.
Delete all recent messages from PayPal permanently form both your inbox and deleted items.
Turn off the reading pane in Outlook.
Turn your Outlook into plain text preview
Redirect the invalid call using a modification to hosts
Start Notepad as an administrator.
You can do this by right clicking on the Notepad shortcut in the Start Menu and choosing “Run as administrator”. If you don’t see this option, hold SHIFT while right clicking on it.
Choose File-> Open… and open the following file; C:\Windows\System32\drivers\etc\hosts
Add the following line at the bottom. 127.0.0.1 102.112.2o7.net
Save the file and close Notepad.
4. Save the file.
This will basically route 2o7.net request back to your computer, which will reject it, allowing you to read your emails quickly and in peace once again.
This fix will work on 32/64 bit versions of both Vista and Win 7
If you still have a problem
In Microsoft Windows, use the command ipconfig /flushdns to flush the DNS resolver cache. Open the command prompt and type the following: C:>ipconfig /flushdns
Windows IP Configuration
Successfully flushed the DNS Resolver Cache.
Corporate solution for all computer clients at once
If you are in a corporate network, your system administrators can fix this for everyone at once by adding a Forward Lookup Zone (Primary Zone) for the 102.112.2o7.net domain. Then add an A host record without a name and have it resolve to 127.0.0.1.
After PayPal fix the issue.
The invalid link when fixed will not fix messages already sent with the issue. So unless you permanently delete message with the problem, you will see the trouble each time outlook references them for reading. This is because the reference is totally invalid, not just temporarily down.
You need to enable “Authentication” in your configured email account settings. There are many client email programs, probably the most common is Outlook.
When you configure an new POP3 email account you normally end up with something that looks like this:
If you click on More Settings / Outgoing Server
and just tick the option to use the same settings as the incoming mail server.
This is all that is needed to enable outbound SMTP authentication.
SMTP Servers (or email servers) are setup to need stop people using them for sending email messages. As strange as that sounds, if they were not setup this way, then anyone could SPAM the world using that email server.
To prevent users from abusing an Open Relay Mail Server, the administrators say that anyone wanting to send email messages from that server to any other server, will need a users name and pass. Almost always this is the same user and pass as the one needed to download your mail from that server.
This this need for user and pass is referred to as “Authentication” and is necessary on almost all servers, other than internet service providers who give you an internet connection. In that instance they authenticate you from your internet connection.
Why Can You Send to Your Own Domain?
Because Email Servers by nature will received email messages to addresses they host. This is part of the process necessary for email messages to be sent and received.
DNN Websites have the ability to configure in the host settings an SMTP server. When a DNN email is generated from the DNN website, it will attempt to send mail through this SMTP server.
In order that your DNN website can successfully send the email, the SMTP server must allow the email message to be received. Typically this is done in one of four ways.
The SMTP server is configured for Open Relay (This should NEVER be done unless you have an external firewall blocking all external SMTP connections. Otherwise your mail server will become a spam server within hours)
SMTP Authentication – Typically SMTP servers are configured to allow users with a valid username and password to authenticate themselves. Once they have been authenticated, they can communicate email messages through the SMTP server. This is the same way most ISP’s work their mail servers. The idea is that only users who are customers of the ISP will allow email to be sent from their SMTP servers.
Selective Open Relay. The administrator of the SMTP server can also allow Open Relay (same as 1 above) from selective IP addresses. Any communication from an IP address that is configured to allow open relay will be accepted by the SMTP server.
Local Host – If your website has it’s own SMTP server configured, typically it will allow email message to be sent form it’s self.
To correctly configure your DNN SMTP settings, you need to understand what method of communication has been configured in the SMTP server you are trying to set DNN to access.
Here is the process you would configure from above.
Enter the IP address or valid domain name for the SMTP server, nothing more to do if open relay is allowed. (Still not recommended)
Enter the IP address or valid domain name for the SMTP server, and the valid user name and password as would be used to communicate with the SMTP server. This is where you get to use the user name and password setting in DNN.
Ensure that the SMTP administrator has allowed the IP address your DNN website uses to have open relay status. Then just enter the IP address or domain name of the SMTP server in your DNN host settings.
Configure your DNN host settings to have “localhost” in the DNN SMTP server settings are.
Problems. There can be some issues that get confusing with the different methods.
Open relay mail servers will be attacked by spammers very quickly. They are always on the lookout for mail servers that they can abuse. It is never recommended to have your mail server on the internet and in open relay. Additionally your mail server will be blacklisted by other mail servers if found to be in open relay.
SMTP Authentication can still be restricted to certain IP addresses. Many ISP’s will allow you only to use their mail servers while you are a client of their AND connecting to their mail server from an IP address they own. So thing will work in your Email applications while you are connecting to the internet via their dialup or high speed connection, but as soon as you move away from a connection provided by them, you will not be allows to connect to their servers, let alone Authenticate.
Even if your ISP has allowed relay from the address that your mail server is run form, there may be a firewall or block on the normal port that the SMTP servers are typically configured to use. Port 25. If a firewall exists between your web server and the mail server, it must be configured to allow traffic over port 25.
You may have web server configured with an SMTP server on the same system. Yet have it be blocked over port 25 for outbound communications. Some ISP’s block port 25 to curb the flow of virus email messages. You need to be sure that your ISP that provides connection to the internet for your web and SMTP server is not blocking port 25.
How to get really confused. Often mail servers will allow you to send email messages to email addresses on that SMTP server, even though they do not allow you to send mail out. So if you have a web application configured to send email to yourself, and the SMTP settings you use in the DNN host settings are for the SMTP server that runs the same email address you will have success. Yet when you change the email address in the web application, you can no longer send email, and the web application appears to fail. This is still an SMTP configuration error on your website. You will need to find a method above to solve the issue.
7. Work out what code error is given when you try to connect from your mail server using Telnet. Follow these instructions. http://support.microsoft.com/kb/153119 but use the IP address and port 25 of the AOL mail server from step 6 above.
We are in the process of automating email problem report resolution. This is a mid-term project, and is being implemented in stages on a queue-by-queue basis. (Ex: Each unique error code type represents a different queue, as do feedback loop and whitelist requests. http://postmaster.aol.com/Postmaster.Errors.php ) The last couple of months were spent migrating our sundry ticketing systems onto one common platform — essentially readying a back-end for the front-end logic flow that you will interface with. We are excited to finally be addressing the part of this project that will offer, in most cases, immediate resolution to your issues. We are starting with router-level queues, the first of which will be RTR:BB errors. I will post on our progress as we push the code into production, along with what ticket submitters should expect with the automated process specific to the queue addressed. If you are seeing problems with the queues in transition, please comment on that particular blog post, and we’ll take a look. Meanwhile, our Postmaster staff will continue handling every ticket we receive. Thanks for your patience and support during this transition!
This was my comment.
1. Good that you are improving things. Sucks that your process is so stupid in the first place. An example of how frigging annoying I am finding things. We at: http://www.interactivewebs.com have been forced by a chapter 11 of an upstream provider to move all our servers to a new IP range. First thing we did was to setup RDNS and check mail reputation (on all the major Black Lists, and senderbase.org). What we found was that the IP range has been abused. So we set about cleaning that up. Naturally we checked AOL, and found that the IP was "undisclosed" reputation. Helpful Right… NOT! But it does not show AOL was listing it. So we move and fire up services. THEN and only then do we find out that AOL does have the address on a BL and mail cannot be delivered. How about tools that work, and a process that works to allow proper checking/de-listing. The ironic part of dealing with your 1990 process, is that it really does not work as well as other systems. AOL users get more spam than many other reputable spam systems. There is even free spam software services that do better. So why stick with such a lame process, when the end result is HEAPS of false positives?
We have discovered a rather annoying email problem this week. Because of a closure of a data centre we have used for over 10 years, we have been forced to pickup our servers and move them over to a new data centre. As annoying and as much work as this is, we have found one particular issue with the change of our primary email servers over to a new IP.
In recent years, there has been a new emergence of spam email fighting systems. Cisco is using it’s power of basically routing almost every bit of data on the internet to directly monitor IP addresses real time. They call this senderbase.org and is part of their IronPort spam scanning service.
We have had our email servers running for years with a “Good” reputation on this service.
However when we move the IP to a new block, we have found that almost instantly, the IronPort services rank us as “poor” due to the fact that they monitor days / weeks / months of average email sent from the address. When we instantly move to a new address that last month did no email, and start blasting email galore through one IP. Bang we are canned.
In the past this has not been a big issue. But in Australia, our primary telco has recently been pushing an email spam service that relies heavily on this service. So we are finding that loads of Australian businesses are blocking our email services. The solution has been to relay through some other email services, but that is time consuming and fiddly, as we still have to leave the majority of email running through the new IP so that it develops a “good” reputation on the IronPort services.
Wouldn’t it be nice if the support people at IronPort answered emails for support to move the reputation of an old IP address over to a news one!
– Update- Since we wrote this. We have been in contact with the senderbase support people who have ranked us a “Good”. It took 3 email messages and 7 days, but they did finally assist.
As it turns out, this ranking is one of the most important aspects of running a valid email server. It is a shame they do not have a more transparent method of making the requests for review. We still cannot work out exactly what the cause of the poor ranking was. There is the possibility that it way by association with the network owner who would appear to deserve a ranking of poor.
NDR or Non Delivery Reports are potentially a great way of telling a user that they made a typo with an email address and that the email could not be delivered. In a 1999 world, this would be fine.
However we are in a world now where email servers are flooded with spam, and lots of it, replying to every junk email that is hitting all the imaginary email addresses on your server (support@, admin@ help@ etc) is not a good idea, and it causes what is known as backscatter. To avoid this back scatter of invalid email delivery from your server it is recommended that you turn off your Non Delivery Reports NDR.
To do this in Exchange 2003 you need to perform the folloing:
1. Open Exchange System Manager
2. Expand Global Setting and Click on Internet Message Formats
3. In the right hand pane, double click the “Default” name or whatever domain you have configured.
4. Click on the Advanced Tab and uncheck the option for Allow non-delivery reports