MAPS RSS and the toaster as an open relay

[davidcl]

(re-posted from the mailto:mail-toaster@simerson.net" target="_blank">mail-toaster@simerson.net mailing list).

MAPS RSS has apparently changed their listing criteria-- my toaster was placed on this blacklist recently.  I wanted to give a few notes about my experience:

1) In a default qmail install, mail to mailto:badaddress@virtualdomain.com" target="_blank">badaddress@virtualdomain.com is accepted and then bounced.  Therefore, by accepting this mail you are not an open relay.  However, MAPS RSS now lists servers which do this-- they require that these bad addresses be refused in the initial SMTP conversation.  The chkusr patch, an optional part of the toaster, solves this problem.  I had resisted installing the chkusr patch for years because I thought I had read somewhere that it is incompatible with catch-all accounts.  However, as long as the catch-alls are set up through vpopmail, this is not the case.  [if anyone has had any specific problems with chkusr and catch-all accounts, please let me know.]

2) If your local hostname is listed in "locals" instead of "virtualhosts", qmail appears to accept mail to mailto:baduser@server.name.com" target="_blank">baduser@server.name.com, even when chkusr is installed.  Is there a way around this?  (I solved it by making my local hostname into a virtual domain, and making sure this particular virtual did not have a catch-all.  However, I really prefer the local hostname to deliver using /etc/passwd accounts, so I'd like to change this back at some point if I can figure out how to reject bad users with a local domain.)

3) Also when the local hostname is listed in locals, and /var/qmail/controls/localiphost is blank, qmail accepts mail to baduser@[local.ip.address].  This also goes away when the local hostname is turned into a virtual, or when /var/qmail/controls/localiphost is set to the name of a virtual domain.

You can use the tester at http://www.abuse.net/relay.html" target="_blank">http://www.abuse.net/relay.html to check for #1 and #3.  I used to consider this tester to be useless with qmail. Because of the items mentioned above, it would always stop at some point and say "Hmmn, at first glance, host appeared to accept a message for relay.  THIS MAY OR MAY NOT MEAN THAT IT'S AN OPEN RELAY."  However, with chkusr and treating all domains as virtual, the abuse.net tester should report "All tests performed, no relays accepted."  There are two situations I know of that abuse.net will not find, either of which will result in your server being blacklisted if MAPS RSS decides to test it:

a) if your SMTP AUTH is misconfigured (as discussed in a previous post I made to this list) this will be discovered by MAPS RSS but not by abuse.net.
b) abuse.net does not test for item #2 above-- it does not check any mailto:baduser@server.name.com" target="_blank">baduser@server.name.com relay scenarios, only baduser@[local.ip.address] and mailto:baduser@name.com." target="_blank">baduser@name.com.

Finally, a few notes about dealing with MAPS:

Although this change in criteria is fairly major-- they are listing servers as open relays even if the mail is not relayed-- there does not appear to be any information on this anywhere on their site.  I couldn't find it in their technical FAQ, their relay securing instructions, or anywhere else.  The only indication of the policy is at the top of the "relay test result" page, where the following information appears:

"*This host accepted our relay test message, but does not appear to have returned it.*  It may yet return the relay test message to us, in which case the server is open to relay. It may never return the relay test message, which means it is probably not open to relay.  If this is the case, you should urge the developers of your mail software package to fix their software to correctly adhere to best current practices, i.e. don't accept mail you don't intend to deliver. See RFC 2505 <http://www.rfc-editor.org/rfc/rfc2505.txt" target="_blank">http://www.rfc-editor.org/rfc/rfc2505.txt>, among others."

It took me about seven readings of this page to understand that this means they will not remove a server from their list unless it doesn't accept mail it doesn't intend to deliver.

Also, when I first wrote to them to have my server removed from their list (before I understood the message) they apparently did not understand that I was the administrator of the server in question, instead referring me to an "end-user FAQ" page which told me to contact my ISP.  This was very maddening.

Finally, the only way to trigger a re-test of your server (that I could find) is to submit a remove request.  Since fixing this problem required me to make three different changes to my server, this meant that I submitted a second remove request before my server was completely fixed.  The second remove request triggered a re-test which revealed an additional problem.  However, I can't submit a third remove request until they process my second one, and I'm pretty damn sure they'll reject the second one based on the fact that the relay test failed.  This is annoying and time-consuming, to say the least.

I had previously had a very high opinion of MAPS-- my impression was that as the "commercial" blacklist operator their behavior was, in general, more professional then other blacklists on the net.  I have to say this incident has had a negative effect on my impression of them.  In order to be trusted, blacklist operators need to post clear, exact guidelines about their listing criteria, in my opinion.  It would also help if relay-testing RBLs provided a "please re-test" option that does not require intervention from a human (ORDB does this.)

[davidcl]

Okay, I've been de-listed by MAPS and I've received some more information from them.  It's now not clear to me whether their listing policy has changed-- they may still list only on actually relayed mail.  For some period of time in October, my SMTP AUTH was misconfigured and my server was open to SMTP AUTH relay (although I swear I fixed that back in August!)

However, if their policy hasn't changed it isn't clear to me why I wasn't de-listed the first time I requested it (when I fixed the SMTP AUTH problem).

I've written to them for clarification on this question.

Also, upon de-listing me they gave me an URL to use to re-test my server in the future.  Unfortunately, this URL (a) only lets me test the one server they listed and (b) does not appear to do the SMTP AUTH tests that got me listed in the first place!

I'll post more if I get a reply from them...

[davidcl]

I'm going to retract my statement that MAPS has changed their listing criteria for RSS-- according to them, their criteria is as follows:

"All listings on the RSS are for servers that relayed spam, and, accepted and delivered test messages from the RSS tester."

In the case of my server, the "relayed spam" was actually bounced spam, but the test messages were delivered due to an SMTP AUTH misconfiguration.

MAPS apparrently made a mistake when they rejected my first removal request.  (Unfortunately, I asked them to explain this part of their actions, and they chose not to answer that part of my e-mail).

In response to my question about on-demand testing, MAPS states: "You can test an IP address for SMTP relay by opening a telnet session from the IP you wish to test to relay-test.mail-abuse.org."  

This is good, but unfortunately this test has two significant limitations:  it does not do the SMTP AUTH testing (which their main tester does) and, like the abuse.net tester, it stops immediately if the server accepts a message.