DH DNS/Mail beauty spots


#1

I checked the DNS of my domains hosted at DH using http://www.dnsreport.com/tools/dnsreport.ch?domain=%s, where %s should be replaced by your domain name.

Some small problems came up:

  1. QUOTE: "Mail server host name in greeting WARNING: One or more of your mailservers is claiming to be a host other than what it really is (the SMTP greeting should be a 3-digit code, followed by a space or a dash, then the host name). This probably won’t cause any harm, but is a technical violation of RFC821 4.3 (and RFC2821 4.3.1). Note that the hostname given in the SMTP greeting should have an A record pointing back to the same server.

mx2.randy.mail.dreamhost.com claims to be host lynch.dreamhost.com [but that host is at 205.196.210.18, not 66.33.205.123].
mx1.randy.mail.dreamhost.com claims to be host decker.dreamhost.com [but that host is at 205.196.210.17, not 66.33.205.122]."

  1. QUOTE: “SPF record [see spf.pobox.com] Your domain does not have an SPF record. This means that spammers can easily send out E-mail that looks like it came from your domain, which can make your domain look bad (if the recipient thinks you really sent it), and can cost you money (when people complain to you, rather than the spammer). You may want to add an SPF record ASAP, as 01 Oct 2004 was the target date for domains to have SPF records in place (Hotmail, for example, started checking SPF records on 01 Oct 2004).”

Changing (1) would probably involve significant effort and isn’t worth the trouble.

SPF records (2) are another story: couldn’t the addition/maintenance of SPF records (they go in the TXT record of a domain’s DNS) for domain with DNS hosted at DH be entirely automated? I grant that SPF record checking is still a voluntary thing (most sane domain MX servers wouldn’t reject incoming mail because the sender domain has no SPF records), but it might reject a few percent more of spam.

Another possibility for reducing inbound spam at DH is to use the Postfix features to reject mail at the SMTP setup stage by DNS lookups, enforcing server black-lists, etc.: my ISP does this for each domain hosted, and the domain admin contact receives a daily report of rejects, e.g. items like this QUOTE

Jun 2 19:10:26 ns postfix/smtpd[4697]: NOQUEUE: reject: RCPT from unknown[218.191.74.175]: 554 Service unavailable; Client host [218.191.74.175] blocked using list.dsbl.org; http://dsbl.org/listing?218.191.74.175; from=TerriPosey@dentalism.com to=luser@example.com proto=SMTP helo=<66.11.168.199>

May 31 08:15:21 ns postfix/smtpd[29439]: NOQUEUE: reject: RCPT from unknown[220.80.179.142]: 566 <66.11.168.199>: Helo command rejected: Forged helo name - this looks like spam; from=PROSEGQARVSEGD@animail.net to=luser@example.com proto=SMTP helo=<66.11.168.199>

May 29 13:24:28 ns postfix/smtpd[8510]: NOQUEUE: reject: RCPT from bxf177.neoplus.adsl.tpnet.pl[83.29.255.177]: 551 <bxf177.neoplus.adsl.tpnet.pl[83.29.255.177]>: Client host rejected: use your ISPs SMTP server - no direct SMTP connections allowed; from=ShaynPlatt894@unet.com to=luser@example.com proto=SMTP helo=<unet.com>

END QUOTE

which help identify any false positive identification of servers spamming luser@example.com. If legitimate mail is being rejected, and the problem can’t be resolved by the sender, the customer can instruct the sender to send mail to a special non-checked subdomain address, e.g. luser@non-spam.example.com.

In my two-year experience of this Postfix configuration, roughly 90% of spam gets rejected, and 1/200 legitimate emails are mistakenly rejected: it really does perform well!

Insert Real Name
insertrealname AT DELETEyahoo.ca


#2

SPF records (2) are another story: couldn’t the addition/maintenance of SPF records (they go in the TXT record of a domain’s DNS) for domain with DNS hosted at DH be entirely automated?

Something to keep in mind is that, unless DH provides the facility to add your own hosts to your SPF record, you’ll be forced to send your mail through DH’s non-SSL SMTP service.

it might reject a few percent more of spam

SPF has almost nothing to do with spam prevention. It’s meant to prevent forgery but it’s trivial for spammers to get around (by simply not forging domains that have SPF records). DH implementing SPF for hosted domains won’t prevent you getting spam or forged e-mail. Their SpamAssassin installation already checks for SPF records on incoming mail.

If SPF is ever implemented, I’d like to throw my vote into making it strictly opt-in, not the default. The marginal benefits, IMO, are not worth the problems it causes.


If you want useful replies, ask smart questions.


#3

Oops, obviously I hadn’t thought of all the implications…

Thanks for the reply.

Insert Real Name
insertrealname AT DELETEyahoo.ca


#4

I’ll delurk again for this one…

I know that at least some of the code for panel-based SPF implementation is done; it’s a project that I was part of when I was working at DH. I don’t know if they have plans to implement it still, but it’s definitely something that was under consideration. Any such implementation would include a way to add custom records, include records from another domain name, etc., in addition to generating the correct SPF records based on services configured in the panel. It does seem that SPF adoption seems to be slowing a lot; still hard to tell whether it’s going to be a “success”.

In terms of the mail server hostname in greeting thing… dnsreport is awfully pedantic. I read through the applicable RFCs a while back, and I’m not sure that this is actually a violation… in any event, because of the way things are setup (with the mxN.xxx.dreamhost.com being a virtual IP), machines will always send their actual hostname as the HELO string. In any event, the server isn’t really claiming to be a host it really isn’t - it’s just claiming to be a server which isn’t directly named as the object of the MX record. I guess it’s subject to interpretation, but I have /never/ heard of this causing any actual problems for anyone.

DH does do some blocking of mail based on blocklists, however they are pretty conservative, blocking open proxies and some really bad spammers. cbl.abuseat.org is the main one that’s used, as well as an internal blocklist I created, and which appears to still be in use on at least some machines. I don’t know if they will continue to maintain it. The Spamhaus SBL might be a good choice, but there is some occasional collateral damage with that one (however, the Spamhaus folks do a good job of keeping on top of stuff and removing stale entries).

Implementing per-domain or per-user blocklists causes a lot of problems (both social and technical). Messages that are rejected are rejected with a hard (5xx) error code, though there’s currently no way to get a report of mail that was rejected. A system like the one you describe in your message is a little kludgy (basically just grepping through the logs), and wouldn’t really work well in such a large scale environment.

There are some other Postfix checks to block mail based on obvious spam signs (trying to send mail with HELO of the mail server’s IP or hostname, etc.). So some of what you’re describing is already happening “behind the scenes”.

Rejecting 90% of spam requires settings that are way too conservative for a large and heterogenous user base (IMHO). I think last I checked, probably 40-60% of mail was being blocked (outright) as spam.

I know it’s a pain to look through the archives, but a lot of this stuff (almost all of it) has actually been discussed, and addressed, in the past.


#5

OK, thanks for such an informative answer.

Insert Real Name
insertrealname AT DELETEyahoo.ca