Michael,

RFC2821:
"consolidates, updates and clarifies, but doesn't add new or change existing functionality"
to other RFCs, in particular RFC 974 which determines how email is delivered. This RFC974 was created in 1986, long before spam became a problem.

This said, the MX filter does just that, checks to see if a sender has a valid MX record in their DNS. If it's not there, the email will be rejected. SpamFilter allows you to enable or disable this filter, leaving admins a choice of how much filtering to perform.

Please note that all legitimate domains "should" have valid MX records. If an administrator chooses not to have an MX record, he must understand that even though it is not mandatory, nowdays many antispam applications will reject emails from their domain.

Also, technically that section of the RFC spcifies how email should be *sent* (to the MX, if no MX present, to the A RR). However SpamFilter is *not* sending email, it is simply receiving email. Upon receipt, it checks the remote sender's domain for the MX records. There is no RFC that defines this, or that says that a *receiver* must/must not perform these checks. So we're actually not in violation of 2821 in regards to this...

I tend to agree with Desperado and Logsat.

The RFC is outdated

In my opinion in this day of spam no company no matter how small or how large, whether a mailing list is legitimate or not, in fact no matter what the reason.
If you want your information to be delivered then there are three things you need to have, and while currently it is an option I think the legitimate mail server owners community should view it a must have.

1: Proper Reverse DNS for the mail server
2: Proper MX record for the mail server
3: Proper SPF record for the mail server

I have people send mail from government agencies to my spamfilter that do not have either an mx record or reverse dns. Simply put, that's bunk. Rejected.
If you want to send mail it should be setup properly to identify the mail server.
If you are too lazy to do it, then you are too lazy to care if your mail gets bounced.
If it can not be identified as the domain mail server then it is spam.

I just reject it flat out, if the sender calls and complains I tell them for a small fee we can come down and setup their mail server properly because who ever they hired to do it does not know how.
It's all about protected your end users and allowing the ignorance of someone’s poorly configured mail server to send mail to your end users is NOT protecting them.
If more people rejected incorrectly configured mail servers from sending mail then they would soon be required to configure their system properly.
Senders need to be taught that if the message is important enough to send then it is important enough to configure your system properly.

I do not accept phone calls from hidden phone numbers or postage mail without a return address so I am not going to accept e-mail from an unknown source either otherwise how is the sender accountable?