version 17, including all changes.
.
| Rev |
Author |
# |
Line |
| 15 |
DanielLawson |
1 |
Things that are more note worthy than SMTPBestPractices have been moved to [SMTPNotes] - AdrianKitto |
| |
|
2 |
|
| |
|
3 |
!!! [DNS] Issues |
| |
|
4 |
|
| |
|
5 |
Try not to put your mail server in what people might consider a "dynamic [IP]" range. It is reasonably common to drop mail coming from IP blocks that are known to be allocated to dynamic sessions such as dialup and DSL connections. If you have an MTA operating in these ranges, be prepared for a fair chunk of the Internet to drop mail from you instantly. |
| |
|
6 |
|
| |
|
7 |
Your <tt>MX</tt> ResourceRecord __MUST__ point to a [DNS] name which has an <tt>A</tt> or <tt>AAAA</tt> record. Do __NOT__ set an <tt>MX</tt> to point to an [IP] address! Do __NOT__ set it to point to a [DNS] name which is a <tt>CNAME</tt> either. For example, mail to <tt>foo@fishbowl.example.com</tt> will not work if <tt>fishbowl.example.com</tt> is a <tt>CNAME</tt> to some other machine. <tt>MX</tt>es must point to a name with an <tt>A</tt> or <tt>AAAA</tt> ResourceRecord. Not a <tt>CNAME</tt>, not anything else. |
| |
|
8 |
|
| |
|
9 |
Make sure that the reverse lookup of your outgoing mailserver exists, make sure has a matching forward record, and where possible, make sure that your <tt>HELO</tt> / <tt>EHLO</tt> name matches the reverse. Note, that this usually doesn't match the name of the domain you want to recieve mail for. |
| |
|
10 |
|
| |
|
11 |
Don't use an underscore "_" in your domain name for mail, in your <tt>HELO</tt> / <tt>EHLO</tt> or 250 server greeting. Mail will get dropped. |
| |
|
12 |
|
| |
|
13 |
Make sure you send mail from a domain that exists, and has at least an <tt>A</tt> or <tt>AAAA</tt> or an <tt>MX</tt> ResourceRecord. If you use an internal mail domain that doesn't actually exist, and mail from this internal domain somehow gets onto the InterNet, you will lose mail. |
| |
|
14 |
|
| |
|
15 |
Use http://dnsreport.com/ to verify that your [DNS] is in good healthy working order. |
| |
|
16 |
|
| |
|
17 |
Attempt to publish a [SPF] record for your domain. |
| |
|
18 |
|
| |
|
19 |
!!! Secondary <tt>MX</tt>s |
| |
|
20 |
|
| |
|
21 |
Secondary <tt>MX</tt>s have fallen out of favour in recent years as the InterNet is more reliable and there are techniques for keeping your primary up (such as load balancing [NAT]s). Having a secondary <tt>MX</tt> is good if your connectivity is unreliable but a pain otherwise. |
| |
|
22 |
|
| 16 |
DanielLawson |
23 |
Remember that not having a secondary <tt>MX</tt> doesn't mean you'll instantly lose mail if your primary is down! The sending MTA will queue the mail for some period (typically 4 hours the first time), then try again. It'll keep doing this for quite some time before finally giving up. The only downside here is that mail will be delayed. |
| 15 |
DanielLawson |
24 |
|
| 16 |
DanielLawson |
25 |
!! Spam and Secondary <tt>MX</tt>s |
| |
|
26 |
Be aware that spammers regularly send to secondary <tt>MX</tt>s directly to avoid aggressive [RBL] checks on the primary MailServer. This can be exploited by having a secondary <tt>MX</tt> that always returns a 400 series code (temporary failure), or is __stricter__ with its [RBL] checks. |
| |
|
27 |
|
| |
|
28 |
One suggested trick is to list your primary <tt>MX</tt> again as the highest number <tt>MX</tt>, so that spammers hit that one first. There is some evidence that spammers aren't actually grabbing the highest <tt>MX</tt> possible, but either blindly picking the second one, or sorting the MX list and removing dupes. Perhaps setting your primary as the first two <tt>MX</tt>s and then your secondary as the third might work. Your mileage may vary. |
| |
|
29 |
|
| |
|
30 |
!! Reliability and Secondary <tt>MX</tt>s |
| 15 |
DanielLawson |
31 |
Regularly check that your backup <tt>MX</tt> still correctly relays. You won't notice a backup <tt>MX</tt> rejecting mail until the first time your primary goes down and all your mail is immediately bounced rather than retried later. |
| |
|
32 |
|
| |
|
33 |
!!! Administrative mail accounts |
| |
|
34 |
|
| |
|
35 |
Make sure you have a <tt>postmaster@</tt> and <tt>abuse@</tt> [Email] addresses that have the least number of filters ([Spam], [Virus], etc) on them. People may try to send you mail to notify you that your machine is broken and explain how you can fix it, but if you treat all mail from their machine as invalid, you'll never hear about the problem. |
| 17 |
DanielLawson |
36 |
|
| |
|
37 |
!!! Pipelining |
| |
|
38 |
|
| |
|
39 |
Pipelining is often used to improve SMTP performance. It allows remote MTAs to keep sending data without waiting for your server response. Spammers can make use of this by sending their entire spam in just a handful of packets then disconnecting, rather than having to wait for the entire protocol negotiation. If you disable pipelining, and your MTA checks for protocol compliance, you may find your spam load drops significantly. |
| 15 |
DanielLawson |
40 |
|
| |
|
41 |
!!! Misc |
| |
|
42 |
|
| |
|
43 |
Try to run an [IDENT] server on your mail server. Several mail servers still try to check [IDENT] by default. If you don't have [IDENT] enabled, then make sure you don't just drop packets to the [IDENT] port, or you will cause other MailServer~s to wait for a time out before they let you send any [Email], slowing everything down. |
| |
|
44 |
|
| |
|
45 |
---- |
| |
|
46 |
CategoryBestPractices |
