First, do no harmBefore concentrating your efforts on preventing inbound spam, it is worth spending some time looking at your own systems to minimise the possibility that messages coming from your system might be seen by others as spam or worse, might actually be spam. To do this, all you need to do is ask yourself one question.
What would I like to see in a well behaved MTA connecting to me to deliver email?
These comments refer to MTAs of all types, not just Domino.
1 - Have correct DNS.
It is very helpful when a connecting MTA has correct forward and reverse DNS. Many sites would like to use this as an initial check when an inbound MTA connects, but cannot do so due to the widespread absence of proper DNS for SMTP MTAs. If, like me, you would like to be able to turn on this feature, do your part. Have correct DNS for your own host.
2 - Do not send direct-to-MX from a dynamically assigned IP.
Some things to consider:
Where is MX for your domain? If, by virtue of your host being on a dynamically assigned connection, your inbound email is delivered to a host operated by some third party, should you be sending outbound email direct-to-MX? In my opinion, you should not. Many sites deny email from IP addresses known to be dynamically assigned. This does not mean that you are considered a spammer, but is simply a reflection of the fact that a very high proportion of the very worst spam now comes via dynamically assigned pools. You can avoid becoming a victim of this by simply telling your sending MTA to route outbound mail via your ISP's smarthost. This might even be the same host as is the nominated MX for your domain.
3 - Ensure your MTA is secure (not open to relay or other exploits).
By now you should know how to close your MTA to simple third party relay. Be aware that an increasing new type of abuse takes the form of brute force attacks against ESMTP hosts that permit SMTP AUTH. If you must permit authenticated users to relay, have a strong password policy - otherwise avoid this feature. Test your MTA against simply relay often. And review your logs to ensure that no abuse of your system is taking place.
4 - Ensure your MTA is well configured (RFC compliance)
- Have a working postmaster and abuse account.
- For MTAs not on dynamically assigned addresses, configure them to accept email addressed to their domain literal. Read this for details of how to do this on a Domino host.
- Accept Delivery Status Notifications (MAIL FROM:<>) - Domino does this by default and this cannot be overridden.
- Ensure your MTA preserves all headers, writes its own received header correctly (so it must know its own FQHN) and makes no changes to message content that might break MIME (save for proper virus protection reasons)
5 - Have up to date software.
If spam is an arms race, you need to deploy technology that is properly supported and has sufficient features to make it competitive in this race. Older software may also have known vulnerabilities and these will be exploited unless you update your software to remove them.
6 - If you send email in large volumes to lists of recipients, manage those lists correctly.
Use closed loop opt in. Have working opt out (using web forms or email "cookies", not just mailto: links).
This is by no means a comprehensive list. But start here and then you can turn your attention to fighting the bad guys knowing that you have done your best to be one of the good guys yourself. Like it or not, if you use email you are in the spam war. So know what side you are on and make it as clear to others as you can.
Category: email best practice
Technorati: email best practice
1. Chris Linfoot07/11/2003 08:41:07
Postscript - some very sound advice from Ed Falcon. Change the default SMTP greeting of your SMTP host. In Domino hosts, do it like so:
http://www.madjunk.com/86256B3B0013F681/unid/EFAN-5HSK7K!OpenDocument
We have our Domino MTAs set up this way. Not that I know of any current exploits against the version we use, but there is no point in disclosing irrelevant information during the SMTP handshake...
2. Joachim Haller29/06/2004 15:54:21
Returning to and reading this document once again I must say I like the simplicity of it because it signals the basic fact that in order to do a good job you must understand what you are doing and you must follow the basic principles of how things should be done. Nothing much has changed really.
I would like to add som personal coments on this topic for whatever it is worth. My comments are ment as general guidelines based on my personal experience.... nothing more.
So, when you work in a larger company or organization it is common that there are different groups within the IT department that handle different aspects of the topology. This has the benefit that each group can specialize and become experts on what they do. However it also opens up the possibilities for greyzones inbetween the different groups - it also opens up the possibility for misunderstanding
If you are an administrator of the companies mail system this puts you in the spot where you must understand the nature of the following components
- The Firewall
- The DNS
- The Router / Switches
- The Mail server
- The Clients
- The Subsystems
- The Firewall
When they tell you the SMTP server is firmly placed in the "DMZ-zone" that all sounds well but you need do know if the Firewall supports individual rules or if rules are shared amongs all hosts on the same DMZ (Interface). The later case is faster and easier to administrate due to less amounts of rules - the first case is "safer" but can also be more complicated and thus unsafe. Find out what other hosts the SMTP server is sharing network with and discuss what happens if any of the hosts on that DMZ becomes compromized. Also discuss the rules that should apply to the SMTP server, what ports should be opened, from where should it be accessed etc. If something goes wrong who can you contact and what is the service agreement. You can imagine how much more complicated this gets if you outsource the firewall...
- The DNS
Many times old records and other historical evidence remain present on the DNS servers causing all kind of funy answers. There are som great books on DNS basics and I suggest you familiarize yourselve with these. The DNS must be properly set up with records for MX, Name, PTR etc. Also there might be an internal and external DNS at your copany Make sure you understand the different tasks these perform. If your company has several external DNS servers make sure they are syncronized and that the records are propagated onto the Internet as expected. This can easily fail and you must constantly be on your guard and check these things. Also if your company has outsourced the DNS service some providers have odd limitations that could cause problems for you. Make sure they understand what you need and that you can communicate with them quickly - should something go wrong.
- The Routers / Switches
The last years we have seen a dramatic growth in "smart switches" and "intelligent routers" and so on. These components are highly capable of improving your network performance but they can also cause havoc within seconds. These devices can be used for load balancing, failover and much more. Make sure the network staff are updated on these devices and know how to operate them. Also if things go wrong you must be able to understand the topology and ready to troubbleshoot it. In any case you must be able to have dialogue with the group responsible.
- The Mail servers
Well, this is your line of business. Check the manual and visit the forums and trusted sites (like this one, thank you Chris !) to get the latest on how to configure, tweak and tune your SMTP environment. Make sure you understand all details of your own mail system. Lock down or minimize all known hazards for relay and SPAM. Combine your main SMTP software with add-on products that do file filtering, virus checking, black- and whitelisting, etc. Decide which function you use in which product.... you don't have to use everything just because it's there. And remember, whatever you use must also be maintained.
- The Clients
Notes is a proprietary system and allows you to control how the users utlilize the system. Naturally PocketPC, Palm Pilots and other handheld devices will be syncronized and thus opening a window of opportunity for Spamers and such. Also the Notes client must be protected for virus etc. Talk to the helpdesk or department that handles PC install etc. and make sure the client is locked down and protected. Recently we have seen how the generic clients such as web browers move in and open noew possibilities and problems for the users. If the users can use web-clients one must consider the fact that they now can access their mail (and other functions) from an unprotected PC anyware in the world. This puts a higher preassure on the admin staff to keep things clean and running.
- The Subsystens
There are other services that send mail within an organisation. This can be Oracle, MS SQL, SAP, Movex etc. If these systems should send mails through the companies SMTP system make sure you check out each system and assess the danger of the host should be compromized or if an alert system suddenly goes crazy. These types of systems usually reside on powerful boxes and of they go bad they can send large amounts of mails in a very short space of time. Discuss with the system owner how their SMTP service works and how they can prevent relay, spam etc.
I hope these thoughts can inspire someone.
All the best
/Jake
Unable to post a comment? Please read this for a possible explanation...
- 
