"Why isn't some email getting through"?
* Reverse DNS Lookups, or "Why isn't some email getting through"?
On July 24th CITES upgraded the campus email relays to sendmail 8.14 and implemented the following checks of inbound email:
require_rdns - requires that the remote server have a properly registered reverse DNS entry block_bad_ehlo - validates the name of the remote server badmx - prevents connections from remote servers with bad MX records
The first check assumes that that other systems are properly DNS registered to have matching PTR and A records. A large portion of spam/virus email originates, or is relayed through, systems that are not properly DNS registered. Since the sendmail upgrade to the campus email relays, we have seen a significant drop in connections (about 1
million/day) from improperly configured senders, a reduction in the size of "stuck email" queues (about 80%), and a reduced load on CITES Spam Control (about 50%).
However, some legitimate sites do not conform to current standards
(http://www.ietf.org/rfc/rfc1912.txt) and lack reverse DNS entries, preventing delivery of some legitimate email to campus users. You may have users you support who will seek your help on this, so we have provided a page to which you can refer the remote site's email
The page explains the change made to our email relays, why we made the change, and how the remote email administrator can determine if his/her site isn't properly registered.