I ran a "test for open relays" tester against my SMTP Relay server and it reported that my system may be an open relay or is doing "Bad Things™". But I've checked and double-checked the configuration of my mail server and this simply shouldn't be so. What am I doing wrong ? Is my mail server broken ? How do I fix it ?
This is the Frequently Given Answer to that question. (You can find similar answers on FAQTS and on the Mitel Networks SME Server developers' web site.)
This answer applies to many open relay testers, including the MAPS/abuse.net tester and the the "remmie" relay test. It applies to several MTS softwares, including qmail and The Internet Utilities for OS/2.
You are doing nothing wrong. No, your mail server is not broken. There is nothing to be fixed. It is the way that the relay test detects whether or not an SMTP server is open to relay that is broken.
The tester assumes that an SMTP server is an open relay if the test mail is accepted. But in fact an SMTP Relay server is an open relay only if the test mails are delivered to the final target. Logically, an MTS is only an open relay if mail can actually be relayed through it.
The tester also assumes various things about mail addressing that are not universally true. Specifically, it assumes that various "addressing hacks", such as the "percent hack", "bang paths", and "hidden @s", are universally implemented. But they are not.
As far as an MTS that strictly conforms to Internet standards is concerned, the percent ('%') and exclamation mark ('!') characters are no different to any other characters. The Internet standards do not define such characters to be special. An MTS that is strictly RFC 822 compliant will treat those characters the same as it treats any other non-special character.
The tester expects mailbox names containing "percent hacks" and "bang paths" to be source routed addresses, with the MTS rewriting them by stripping off the original domain parts and substituting the domains "hidden" within the local parts, and then relaying messages on to elsewhere. But in fact, to a strictly compliant MTS, such mailbox names in fact simply denote rather strangely named, and unlikely to exist, local mailboxes. No rewriting or relaying is involved.
Examples:
The MAPS/abuse.net relay tester attempts to send mail to <securitytest%abuse.net@[your-ip-address]>, <securitytest%abuse.net@your-domain>, <"securitytest%abuse.net">, <abuse.net!securitytest@[your-ip-address]>, <abuse.net!securitytest@your-domain>, and <abuse.net!securitytest>, expecting that <securitytest@abuse.net>, will receive the mail if it is accepted.
The "remmie" relay tester attempts to send mail to <target-user%target-domain@[your-ip-address]>, to <target-user%target-domain@your-hostname>, and to <target-user%target-domain>, expecting that <target-user@target-domain> will receive the mail if it is accepted.
If you have very bizarre ideas about user naming, you may well have local users named securitytest%abuse.net, "securitytest%abuse.net", abuse.net!securitytest, and target-user%target-domain on your system. In that case, the test mail sent by the tester will be delivered locally. Otherwise it will be bounced (by your local delivery agent) as undeliverable. In neither case, however, will your system relay the mail anywhere else. So it cannot possibly be categorised as an open relay, whichever of the two actions it performs.
Similarly, as far as an MTS that strictly conforms to Internet standards is concerned, a quoted '@' character in the local part of a mailbox name is not special in any way. An MTS that is strictly RFC 822 compliant will treat that character the same as it treats any other quoted special character in a local part.
The tester expects mailbox names containing quoted '@'s in their local parts to be effectively source routed, with the MTS rewriting them by stripping off the original domain parts and splitting the local part into a new local part and domain part at the quoted '@' (e.g. Transmuting "a@b"@c into a@b.) But in fact, to a strictly compliant MTS, such mailbox names in fact simply denote rather strangely named, and unlikely to exist, local mailboxes. No rewriting or relaying is involved.
Examples:
The MAPS/abuse.net relay tester attempts to send mail to <"securitytest@abuse.net"@[your-ip-address]> and <"securitytest@abuse.net">, expecting that <securitytest@abuse.net>, will receive the mail if it is accepted.
The "remmie" relay tester attempts to send mail to <"target-user@target-domain"@your-hostname>, expecting that <target-user@target-domain> will receive the mail if it is accepted.
If you have rather bizarre ideas about user naming, you may well have local users named "securitytest@abuse.net", and "target-user@target-domain" on your system. In that case, the test mail sent by the tester will be delivered locally. Otherwise it will be bounced (by your local delivery agent) as undeliverable. In neither case, however, will your system relay the mail anywhere else. So it cannot possibly be categorised as an open relay, whichever of the two actions it performs.
To put it simply: The relay testers are deficient, inasmuch as they fail to take into account that there might exist MTAs that strictly conform to the Internet standards and don't support all of these various historical (and largely useless) addressing bodges; and that on such systems the act of accepting a message that is addressed to a mailbox with such a bodge in it is not necessarily the same as being an open relay.
To be frank, in the case of the "remmie" relay test the poor quality of the test result page should have tipped you off to the quality of the tester as a whole. The output from the test isn't even converted to correct HTML. ('<' and '>' in mailbox names are not converted into "<" and ">" as they should be, resulting in a results page full of invalid HTML that web browsers will simply not display as intended.) The inability of the tester's author to get something basic like that right should leads you to suspect that he/she might not have got the actual tests right, also.