> The better MTAs detect the too-common broken "MX ip.ad.re.ss" record > and interpret the intent of the error and try to deliver the IP, > rather than not deliver the mail at all, while logging an "invalid > MX record".
To my mind, this particular "forgiving" policy simply encourages less-than-attentive sysadmins.
No PTR for legits MTAs is a much bigger problem, and we're forced to tolerate (and thereby, encourage) that when deciding to accept mail, so tolerating screwed up MXs records when sending our legit mail is really no big deal.
An MTA that refuses to send our legit mail because "MX RDATA field is an IP" error is just stupid. but "my MX, my policies"
You can bet that plenty of other errors, particularly other DNS errors, will come along with this blatant misconfiguration
welcome to internet. My job is my mail system, NOT their DNS screwups.
don't even see any reason to log an "error" if the MTA best-guesses/normalizes the RR and delivers anyway; who ever takes action on that error?
I never have. logging isn't expensive, and is excellent evidence if a dialogue ever arises with the other end for any reason
Anyway, there are always sysadmin-specific (and site-specific) rulregarding whether a policy encourages the "education" of
partners/clients vs. just making our end look bad.
An mail admin who runs an MTA that has a policy that refuses to deliver his users' legit mail to a legit IP running a listening, legit mailserver just because the @recipient.domain has a broken MX record is an mail admin who will quickly be pummeled by his users and his management. I have better things to do.
Len
_____________________________________________________________________ http://IMGate.MEIway.com : free anti-spam gateway, runs on 1000's of sites
To Unsubscribe: http://www.ipswitch.com/support/mailing-lists.html List Archive: http://www.mail-archive.com/imail_forum%40list.ipswitch.com/ Knowledge Base/FAQ: http://www.ipswitch.com/support/IMail/
