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!"

Comments

Relay through ISP

[crow]

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).

Re:Relay through ISP

[Saganaga]

I second this recommendation. This is exactly what I do for my home email server (on Roadrunner cable) and my church's email server (on Onvoy DSL). Both email servers are using QMail.

The only possible negative I see to relaying through your ISP's SMTP server is that it introduces another possible point of failure, but that seems to be an acceptable tradeoff.

Re:Relay through ISP

[jc42]

It won't work. Around here, we get cable service through rcn.com, and my wife and I have email accounts with them. I don't use it much except for testing, but she uses it a lot. She uses her Mac Mail program, and it is configured to relay through smtp.rcn.com. Some weeks back, she found that email to aol.com addresses were bouncing. I found the raw source message, and it contained an explicit statement that all messages from rcn.com addresses were being rejected as spam.

AOL has done this in the past, of course, and they proudly announce how many spam messages they have rejected. Some have suggested that they should reject all email, and then they'd have a 100% successful rejection of spam. But I digress. ;-)

Anyway, the dummies that reject email based on things like dynamic IP addresses often reject all messages from an ISP. So it doesn't matter whether the email comes from your machine or the ISP's relay.

Use SmartHost

[FattMattP]

What can I do?

Easy. You just need to configure your MTA to relay your outgoing mail through your ISPs SMTP server. In Sendmail this would look like the following in sendmail.mc

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.

Re:Use SmartHost

[pbrammer]

I second this motion. Cox even started blocking outbound port 25 traffic, so this is the only way my servers can send mail to the outside world. Works great.

Postfix can be setup similarly in the postfix/transport file:

my.domain :
.my.domain :
* smtp:outbound-relay.isp.domain

The null entries for my.domain are so that internal mail doesn't go to outbound-relay.isp.domain.

Phil

Learning the hard way, eh?

[darksmurf]

You being on the DUL is a good thing. It means less spam from your entire netblock.

This is where you learn to relay your outgoing mail through your upstream provider. You should of course continue to be the MX for your domain for all other purposes.

I know other people have mentioned this, but seriously... No cable or DSL clients should be pretending to be a full-on mail hub. Just use the smtp resources of your upstream provider.

Use MailHop Outbound from DynDNS.org

[dpilot]

For a small (volume-dependent) fee DynDNS.org will relay outbound mail for you with the 'MailHop Outbound' service. They will also relay inbound mail to your server (on a high port, if need be because of your ISP) with 'MailHop Relay'.

At this point, you'd probably want your DNS hosted through them, as well. On the plus side, this would give your domain a complete and consistent appearance, IP-wise. I believe at this point, you may even be able to add SPF records to your DNS entry as well. (Though I'm not sure if they do the correct thing outbound for SPF.)

The whole shebang would probably still come to less than $100/yr.

Why not host your website on a cheap host?

[Chibi Merrow]

For instance, FuitadNET offers a $5/mo package that includes DNS hosting, 3GB of Web Space, 25GB of bandwidth, and 100 e-mail addresses. You'll get better uptime than with a cable modem and shouldn't have to worry about MAPS or ORDB or whatever.

Re:Only corps should be free to run their own mail

[SuiteSisterMary]

He's not blacklisted. He's accurately listed as being a residential dynamic-assigned user.

The fact that some other mail servers choose not to accept his mail, based on that fact, has nothing to do with his ISP.