On Sun, Nov 3, 2013 at 11:08 AM, Rich Kulawiec <rsk@gsp.org> wrote:
non-generic DNS/rDNS. ("non-generic" meaning something that looks like a host that should sending and receiving email. In other words, mailgw.example.net looks real. ip-137-12-16-164.example.com looks like a random host that's probably part of a botnet.)
This is a good idea, but you can use a generic hostname if you want. It's not a consensus that you need a non-generic hostname. There can be negative consequences for mail delivered to some recipients, because SpamAssassin and some other reasonably popular spamfilters, will use a regular expression based on a sending mail server's rDNS name to decide that "ip-137-12-16-14.example.com" is not a bonafide mail server, based on the hostname alone; this can increase the probability that legitimate mail you send will be miscategorized as spam, if you do choose to use a generic hostname for a mail server. http://svn.apache.org/repos/asf/spamassassin/branches/jm_bug_3852_two_level_... There are many ad-hoc rules that spam filters will subject messages and sending mail servers to, that are not part of the formal requirements for sending MTAs. Make sure that you HELO/EHLO as the same host -- unless there's
some good reason not to. There probably isn't.
The RFC contains a MUST NOT in regards to verifying the HELO name matches. So, the HELO can use any hostname --- as long as the hostname forward resolves to something; it should resolve to the IP address of one of your mail servers. Some mail servers provide service for many domains, and have many DNS names that could be placed in a HELO. The general rule here is: Look at what is common, what is the simplest and most likely way for mail server operators to present themselves. You don't want your mail server to look any different to the outside world, either in operation, naming, or forward and reverse DNS configuration, HELO messages, etc, from a majority of other legitimate mail servers.
SPF is worthless crap: don't bother. Use a real MTA, e.g., postfix
I do not believe that is the consensus of the community -- or the working groups behind the SPF-related RFCs. There are many mail servers and spam filters that will enforce SPF policies; there are also a number that will synthesize an "implicit" policy of Soft (or hard) Fail for any sending IP, except the MX or base A name IP, if you do not publish explicit SPF records. I have a spam filter that penalizes messages from domains with no SPF published, or not matching a high-granularity allow condition by scoring them as more likely to be spam; greylisting may be caused by a soft fail, and of course, messages will be rejected on a hard fail. If you are serious about running an outgoing mail server; I do not believe you have the luxury of completely ignoring SPF, DKIM / domainkeys / sender-id, and other established or emerging community standards. After all, they can be used as a tool to help reject some spam. e.g. spoofed @usps.com messages
Don't use a quarantine, it's a horrible idea. (Ask RSA how that worked
Message quarantines are great; they are helpful for mitigating the false positives of overly-agressive filters. A combination of quarantine and reject policies can be useful, for border cases. Especially, if there are some users that "want" spammy messages, which are actually HTML bulk-sent newsletters of some sort or another. out for them.) Make sure you don't backscatter. Make sure you don't
use SMTP "callouts", which are just as abusive as spam. Make sure you
Implemented appropriately; an SMTP callout (or "SMTP connect" verification) to the connecting IP is a great way to help resolve the suspiciousness level of the sending mail server. SMTP connect verification is a good thing to be using, when the sending server is using an envelope From domain, that has not yet bothered to publish the proper SPF records to verify them. There are bad broken SMTP callout implementations that should be avoided, and there are rather useful ones.
have working "postmaster" and "abuse" addresses. Make sure your MTA doesn't emit or respond to return-receipts. Read your logs (again).
Of course, read receipt requests should be suppressed when dealing with internet hosts. Having a working postmaster address is a requirement. Using the name abuse@ for the abuse contact is not required, and it is likely to be targetted by spammers. Working abuse and technical contacts should be published in the IP address and domain name WHOIS databases for the mail server's primary domain, and all envelope from domains that can be originated on that mail server. ---rsk
-- -JH