QuoteReplyTopic: Check valid MX record on receive Posted: 18 November 2004 at 4:12pm

Ok, this did seem good and I am stopping a lot of spam but I am getting a lot of messages rejected from server like mil.gov and fema.gov; also just about every list server that I have user on are also getting mail bounced due to checking for valid MX record. I am being force to turn this option off.

Not all valid out going email servers will have valid MX records, while this check does knock out some spam, is it worth losing one valid email message for every 500 messages that are spam?

While technically per RFC2821 domains are not *required* to have an MX record, the RFC was written back in the days where spam was a non-issue. Nowdays things are different. Most administrators should be aware that a properly configured DNS should include one or more MX records for their email system, just like properly configured and legitimate server should have a reverse DNS entry.

It would appear surprising that fema.gov does not have an MX record. However that not their only problem. If you check their DNS, you will find that they have an A record for fema.gov, 166.112.200.200. The RFC states that if the MX records is not present, mails servers should use that instead. As of right now, there is no mail server listening on that IP address, it is not a valid mail server (or it's having technical problems at the moment).

To summarize, at this moment any email address in the form user@fema.gov is an invalid address, since the domain does not have a mail server. Please note that this may change if they are indeed having technical issues.

The other domain you mention, mil.gov, does not appear to have a DNS entry at all, so it too will not be able to receive email right now.

No, it does not and I agree with LogSat that it should not as the rfc does not state that a mail server *must* send to a A record if MX is not present ... only that it *should*. In my opinion, no MX is an omission from DNS and if you really have a mail server then you should insist that the DNS administrator puts an MX record in. A good argument for this is that most web sites can be hit with either http://www.domain.com or just simply domain.com ... using a "blank" A record. As a result of this, we always put in an MX record and if no mail server exists, then it is pointed to a server that simply nulls out all inbound mail. This way, none of our customers web servers are getting hit with mail attempts that should not go there.

I have recently modified my Sendmail server to *only* deliver to a valid MX record and not attempt to deliver to a simple A record.

As Dan correctly replied, no, we do not check for the A record. Thru research, we've seen that a large number of the spam that the MX record filter stops, is sent from domains that do have an A record. If we were to check for that, the filter would have let the email thru.

Please note that the A record for a domain will most likely be there if the domain in the email exists, so checking for that to be present would practically just mean that we'd be checking only to see if the domain exists or not. We want to do more, and verifying the actual presence of the MX record has proven to be very effective.

If valid domains without an MX record are found, we strongly urge administrators to notify the owners/admins of those domain to inform them that they should really get with the times and properly configure their DNS.

There is no RFC that states that an email server should not be an open relay, however as we often mention some RFCs are dinosaurs, and need to get a face lift. Anyone who will say "the RFC says I don't need to close my mail server relay" will quickly appear on internet blacklists, and his mail server exploited. The MX record presence issue is very similar. It does *not* have to be there, but most administrators know that they really should have one to avoid problems.

I thought the purpose of this was to block ONLY spam. New features that are designed to block valid email, seem like a flaw to me.

The problem here is the term subdomain (as so many other terms used on the Internet) is defined many different ways. For the purpose of DNS, though, a subdomain MUST contain at least one entry in it's own zone record or it is not a subdomain, it is merely a host record in a subdomain.

This means that if I define listserver.domain.net as a host record in domain.net DNS zone record AND even have it listed as an MX record in domain.net AND I can send and receive email to and from this legitimate list server, I still get rejected by Logsat! This is a common scenario and there are many valid and proper uses for sending and receiving email from a host in legitimate DNS zone.

So, if you use this feature you are GUARANTEED valid wanted email gets rejected in addition to invalid unwanted email.

If the "FROM" is something like reply@listserver.domain.net then listserver.domain.net should have an MX record to cover a valid return path and therefore no problem will exist. In this case, listserver.domain.net is, as you state a host BUT it is also a sub-domain so that the zone file might look like the following real example friom my dns server:

Every host that sends email must have a MX record ? Great, then you don't need SPF! I think if you're going to run a cryptic operation like that you would be better served by a product that does strictly user managed whitelisting only and rejects everything else. That's really where you are going with a feature like this. I know, I know, we can just turn the misguided feature off.

My problem is that I did not believe in a thousand years that this feature could have been implemented as such requiring every host to have an MX record. I figured that verifying the the sending domain INCLUDED an MX record was an intelligent way to filter some spam. That way if the domain had no MX record we could say there is a problem with the domain and justify not accepting the email. To turn this into a cryptic feature that requires every host to have an MX record is simply going to block lots of good email. Users beware!

NO ... not every *host* that sends email requires an MX record ... Every *domain* that email claims to have a return path to (ie the FROM address) needs to have an MX record otherwise, how can you mail back if there is no existing exchanger? If there is no mail exchanger, the why did the user *claim* to have a return address from a domain that can't be answered to?

SPF is totaly different. SPF maks sure that the domain the mail is claiming to be from is allowed to mail from the IP it came from.

The answer to your question is simple, an MX record is not required in order to receive email! MX records point to email for the domain. So, if SpamFiltered worked properly and checked the domain it would not cause the enourmous false positives that this feature causes.

No big deal, though, just another of many empty checkbox in the program representing illogical cryptic capability.

Up until a few years ago, administrators would not only have never imagined to have needed an MX record, but other things were also unthinkable. While no RFC states anything in merit, not complying with any of the following examples may also prevent them from sending/receiving emails:

Locking down the mail server to avoid being an open relay. Nowdays if you don't do this the admin will end up on blacklists and providers will rejecte emails from them.

Adding a reverse DNS entry to the mail server's IP. Many providers nowdays will refuse emails unless the PTR is present.

In the near future, many providers will reject emails unless domains have SPF records in the DNS.

There is nothing in the RFC that dictates administrators must implement the above. However spam has imposed new, unwritten rules. Having a properly configured mailserver will help in the overall fight against spam. One such unwritten rule that most administrators know about is that mail servers should, not MUST, have an MX record. In the past not having one was OK, just like a few years ago it was OK to have an open relay, or not having a reverse DNS record. Not today.

We are now giving administrators one more way to reject unwanted email by demanding that the senders have a properly configured MX record.

Most domains do have an MX record in place. All anti-spam software have an accuracy rate in detecting spam that is not 100%. Any filter will at some point block legitimate emails. The MX record filter is not any different. It too will block some legitimate email, just like the others. It is the administrator's choice to see if that percentage is acceptable or not.

I recently upgraded and have noticed a lot more false positives with this feature turned on. Rather than debate the merits of the feature, I have a question: What does the reject message look like? Does the capability exist to have invalid MX rejections bounce back with more than the generic server error message? Specifically, with a user-friendly writeup of what is discussed above? That might be helpful in alerting senders of false positives what must be done on their end to mitigate their problem. Odds are they probably do not even know about the problem. It'll give them something to take to their postmaster.

Do you mean false positives caused by (1) the legitimate sender not having configured his MX record properly, or (2) because the sender has a valid MX record, but SpamFilter still rejects the email?

In case of #2, if you please post or email the log entries relative to the reject we'll try to see what the problem is. In case of #1, the sender's administrators will probably want to think about correcting their configuration, as with time more and more antispam software is and will continue to use this feature.

Going back to your original question about the customization, yes, SpamFilter does already send a customizable error message explaining what the problem is. By default it's:

550 Your domain %Domain% does not have a valid MX DNS record. Disconnecting...

You can customize it (and many others) in the "Customized Items" tab under the settings tab.

#1 I would imagine. Not a false positive in the programmatic sense of the world so much as a user sense.

Thanks for the info on the error. I'll try to customize it so that it is hopefully more informative to the user and will prompt him to contact his sysadmin about configuring the MX record appropriately.

My thoughts only, but EVERY email/DNS administrator should consider publishing correct RDNS, MX, SPF so as to aid in reducing or eliminating the meriad of ways (what ever you wish to call them) spammers use to exploit the Internet to send SPAM and viruses.

What I see is that spammers are better at setting up DNS than most administrators are. Please take Roberto, Dan's and the RFC's excellent advice and setup DNS as recommended and help other administrators who are less informed as to why they should do the same.

I do help other adiministrators and it really helps to keep your users happy by eliminating spam and near zero false positiives.

I trapped an email in the quarantine from my in-laws who use Cox Hi-Speed, with the invalid MX record error in the log. This is curious, as Cox is of course a major national provider. Is this evidence of a #2 error as described above?

cox.net does indeed have a correctly configured MX record, the email should not have been rejected for that casue.We did have a bug in one of the latest pre-release builds of SpamFilter, where a socket error could cause the MX record test to fail. This was fixed in build 2.7.1.531. What verison of SpamFilter are you using?

I have been using the MX filter with great success. I had a few people get false positives but those few are now whitelisted per their personal spamfilter web interface. The MX filter is blocks about 1000 pieces of spam every two days. This is a great feature!

Here are my stats for the first half of today. Invalid MX is way down on the list but still ... 2000 messages. Also, often, during "Spam Attacks", the invalid MX test is the only thing that blocks them so it bumps up to as high a 30%

I sent in a message to the sales address about obtaining a license for a home-based server like mine but haven't heard back. Was that received? My quarantine didn't show any replies either, but I don't quarantine everything. Just curious.

We had to stop using SORBS. They adopted a policy of charging for being de-listed and as a result most folks don't bother. I had a bitter argument with them on several IP's that were blocked. I feel the list (which used to be fantastic) is now very problematic and we saw a huge upsurge in false positives.

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot delete your posts in this forumYou cannot edit your posts in this forumYou cannot create polls in this forumYou cannot vote in polls in this forum