Overcoming MAPS Reverse-Lookup Oppression?
ArghBlarg asks: "Imagine the following scenario: you're the volunteer admin for a small, non-profit site for a few local artists and musicians. You run your web site and SMTP server out of your laundry room, via cable broadband. The broadband provider doesn't mind, as you only get a few hits a day; you keep your system secure and were only rooted once, over 4 years ago (hey, it happens). Your site has never, ever (to your knowledge) relayed spam. On the whole you've been an exemplary netizen. One day, some email you send bounces because your ISP's entire netblock has been placed on the MAPS DUL. True, your server's IP isn't technically static (though it hasn't changed in 12 months); because your domain is embedded within the broadband provider's larger IP block, reverse lookups don't give your domain name, rather that of the provider (with a huge number prefixed as the hostname). Hence you're considered a rogue SMTP node and blocked by MAPS. I've emailed MAPS but they won't agree to whitelist me. I have a proper MX record for my SMTP server, under my domain name. What can I do? Is there any way to make my legitimate domain take precedence in reverse-lookups, so I don't show up as being part of a spam-friendly network?"
"Please don't bother suggesting that I ask my provider to give me a static IP outside the affected block -- they won't, not without upgrading to a MUCH more expensive package which gives me no benefit for a small-traffic server like this.
What have you done to get your domain, running on a pseudo-static IP, out from under the thumb of the spam block lists? While I wholeheartedly support the efforts of the MAPS people and others like them to stamp out the vermin that are spammers, our domain has become collateral damage in the war!"
What have you done to get your domain, running on a pseudo-static IP, out from under the thumb of the spam block lists? While I wholeheartedly support the efforts of the MAPS people and others like them to stamp out the vermin that are spammers, our domain has become collateral damage in the war!"
You should configure your SMTP server to relay all mail through the ISP's SMTP server. Then people will receive the mail from the ISP, not from you, and presumably they won't be blacklisting the official SMTP server for the ISP (or else you have a bigger problem).
define(`SMART_HOST',`smtp.myisp.com')dnl
of course it'll be different if you're using another MTA. MAPS DUL (dialup up list) is doing what it's supposed to do. It's listing dynamic address ranges such as cable modems, DSL lines, and dialup numbers. A lot of spam can come from these so people choose to use them to block email that isn't coming from the ISPs mail servers.
Prevent email address forgery. Publish SPF records for y
I had to waste alot of time with ORBS because my company's upstream provider had a larger netblock that we were a part of blacklisted. The people I emailed were quite obnoxious and rude, despite the fact that our servers were secure and never relayed a thing.
And for what? I still see a ton of spam, despite the fact that my ISP uses MAPS.
Conformity is the jailer of freedom and enemy of growth. -JFK
... that only large businesses should be allowed to run mail servers that can send e-mail.
Glad to see so many people here who are interested in maintaining a free system.
-Rusty
You never know...
The first is that this method of "spam prevention" provides pretty much no spam prevention whatsoever. Insofar as it provides any protection, it's from a small minority of unsecured open relays present in older operating systems, which happens to be an extremely specific bug and a very easy issue to deal with.
The second is that this method makes configurationless email impossible. You HAVE to configure your MTA to point at a specific smarthost. You HAVE to change this if you use a different ISP. And if you regularly use more than one ISP, then you have to reconfigure every time you connect.
The third is that the "small minority" argument is bogus to begin with. Point at any activity on the Internet and you can claim it's a small minority. Slashdot, for instance, regularly causes problems for websites by linking to them. Only a "small minority" read Slashdot. Therefore it is legitimate to block Slashdot. You can work on it to any degree. The World Wide Web would never have gotten off the ground if the "small minority" people had decided to block it as a bandwidth waster from the beginning.
The fourth is that hacks like this undermine the integrity of the email infrastructure. By frequently imposing arbitrary rules, you guarantee the failure of legitimate email. You force system administrators and end users to frequently make minor and unnecessary changes to the configuration of their systems.
The fifth is that better anti-spam systems exist, but ISPs lack the will and desire to operate them. Blacklists are an easy way out, their proven ineffectiveness is testament to the stubborness and power-tripping of the groups that operate and subscribe to them. We have more spam on our systems now than ever before.
Yes, SMTP email wasn't designed to cope with the spam phenominem, but this isn't helping. Solutions need to be sane, they need to block spam or spammers, and not block on an arbitrary "well, a spammer might use this" basis. There's been far too much support for things that do not work, it's time to switch to things that do.
Oh, and I'm an expert. I do know what I'm talking about. I operate my own SMTP servers, wouldn't touch an ISP that doesn't let me, and thanks to that pretty much never receive spam (perhaps once per organization I've done business with at most.) We could eliminate spam tomorrow if ISPs had the guts to implement the systems needed. Unfortunately, they don't.
You are not alone. This is not normal. None of this is normal.
It's not just open relays, it's also all those machines that have been taken over by trojans with built-in SMTP engines.