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.

Dan S.

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.

- Matt

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! 

-Matt

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.

#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.

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?

Here are the relevant headers, modified to remove personal info:

Received: from [my in-laws username] ([70.186.195.204]) by eastrmmtao05.cox.net
          (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP
          id <20060226204937.OAJY3108.eastrmmtao05.cox.net@[my in-laws username]>
          for <[mywife's username] @ mydomain>; Sun, 26 Feb 2006 15:49:37 -0500
Message-ID: <002901c63b17$5395f160$ccc3ba46@[my inlaws]>
From: "[My In-laws]" <[my inlaws]@cox.net>

2.7.1.515

That was the version available to me being a non-paying individual user.  Woe is me I guess until the next generally available release I suppose.

Finding a lot of these false positives in the meantime.  *sigh*

Thanks for your help. 

here's another.  Not sure if it's a 1 or a 2.

02/27/06 17:54:07:073 -- (1296) Connection from: 63.174.99.34  -  Originating country : United States
02/27/06 17:54:07:511 -- (1296) Resolving 63.174.99.34 - Error resolving IP address (Socket Error # 10054 Connection reset by peer.)
02/27/06 17:54:07:620 -- (1296) - Invalid MX record - Socket Error # 10054 Connection reset by peer.
02/27/06 17:54:07:620 -- (1296) 63.174.99.34 - Mail from: [valid user]@tmalist.com To: [me] will be rejected
02/27/06 17:54:07:776 -- (1296) EMail from [valid user]@tmalist.com to [me]  was received and quarantined. Size: 6 KB, 6144 bytes
02/27/06 17:54:07:807 -- (956) Time to add Msg to Bayes corpus:0
02/27/06 17:54:07:823 -- (1296) Blacklist cache - Added 63.174.99.34 to limbo
02/27/06 17:54:07:823 -- (1296) Disconnect

COMMENT ON SORBS:

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.