Mailfromdnsverify, nomailfromdnsverify Channel Options

From Messaging Server Technical Reference Wiki
Jump to: navigation, search

Verify that the domain on the MAIL FROM: line is in the DNS (mailfromdnsverify, nomailfromdnsverify)

Setting mailfromdnsverify on an incoming TCP/IP channel causes the MTA to verify that an entry in the DNS exists for the domain used on the SMTP MAIL FROM: command, and to reject the message if no such entry exists. nomailfromdnsverify is the default, and means that no such check is performed.

Note that performing DNS checks on the return address domain may result in rejecting some desired valid messages (for instance, from legitimate sites that simply have not yet registered their domain name, or at times of bad information in the DNS); it is contrary to the spirit of being generous in what you accept and getting the e-mail through, expressed in RFC 1123, Requirements for Internet Hosts. However, some sites may desire to perform such checks in cases where junk e-mail (SPAM) is being sent with forged e-mail addresses from non-existant domains.

The introduction of DNS wildcard entries in the COM and ORG top level domains which occurred in September 2003 severely limited the effectiveness of the mailfromdnsverify channel option. (The wildcards have subsequently been removed, however, such practices could resume at any time.) As of the 6.1 release of the Messaging Server MTA, mailfromdnsverify code has been modified to address this. When the DNS returns one or more A records (which would normally be considered a "success" and the message would be allowed in), their values are compared against the domain literals specified by the MTA option blocked_mail_from_ips. If a match is found, then the domain is considered to be invalid.

With mailfromdnsverify on, as of Messaging Server 6.0 and later the MTA attempts an MX lookup on the domain of the MAIL FROM: command. As of MS 6.1 and later, if that MX lookup returns no data (no MX record exists) then the MTA moves on to attempting a gethostbyname call. That is, a success at the MX record lookup stage allows the message in; errors other than simply no such MX record (e.g., a nameserver "server failed" error) at this MX record lookup stage will result in a temporary rejection with error

450 4.1.8 invalid/host-not-in-DNS return address not allowed

while (with MS 6.1 or later) a no such MX record found case moves onward to checking the result of a gethostbyname call. (In iMS 5.2, only the gethostbyname was attempted; no explicit MX record lookup was performed.)

When the MTA does a gethostbyname call, if this DNS query results in an authoritative "host not found" response, then the message will be rejected with a permanent rejection

550 5.1.8 invalid/host-not-in-DNS return address not allowed

error message. A no data response, as would occur for the case of a name which has only a CNAME record in the DNS, is considered a successful response; the message will be allowed in. Any other error responses from the DNS will result in a temporary error

450 4.1.8 invalid/host-not-in-DNS return address not allowed

deferring the message: the MTA will not accept the message at the present time, but the sending side should try sending it again later (in case perhaps their DNS problem, whatever it was, gets fixed).

New in 8.0 is specialized handling for MX entries of the form:

nomail          IN MX 0     .

Such entries are intended to be an indication that host "nomail" does not operate a mail server. Support has been added so that mailfromdnsverify will treat such hosts as not being a valid source of mail. (Additionally, attempts to send to such a host will fail immediately after the MX lookup instead of attempting any sort of A record lookup.)

If the logging channel option has been enabled on an incoming channel, then rejections due to a mailfromdnsverify check on that channel will be logged to the mail.log* file as a "J" record.

See also: