Mark as Not Junk

July 10, 2006 9:24 AM

Any tips for keeping email I send out of the recipients' spam folders?

I have my own domain name, and my home machine uses qmail, with the domain's web host's SMTP server as a smarthost. This setup has worked beautifully for quite a few years, just recently a number of messages I send seem to be getting tagged as junk by the recipients -- Apple's Mail client in particular seems to have it in for me.

The home machine is on a cable connection with a dynamic IP address (which never actually changes), and that seems to be at the root of the problem. SpamAssassin complains in particular about RCVD_IN_NJABL_DUL, RCVD_IN_WHOIS_INVALID. I have a valid SPF record but I wonder what else I can do to make my outgoing mail seem less spammy.

posted by Eater to computers & internet (12 comments total)

If you're smarthosting outbound's to the webhost's SMTP server, then I *think* the IP address of *your* server being dynamic ought only to matter if it's *your own webhost* who's bouncing the mail.

The recipient server can't *see* your IP address, since you don't connect to it.

Are you *sure* smarthosting is working as you expect? (You've checked the logs to see that everything going out is connecting to the smarthost?

If the recipient's mailer is reaching back into Received: headers to look for dynamic IP addresses on mail forwarders to declare something spammy, then I submit that's the recipient's problem, and you shouldn't enable them, you should send them lots of mail which loses *them* money if they miss it, and let the proper person fix the problem. :-)
posted by baylink at 9:29 AM on July 10, 2006

Mailservers on consumer DSL and cable modem connctions are a major source of spam. Your best bet is to use a mailserver at a reputable ISP for your outgoing mail. If you have to have your own mailserver in the loop for outgoing mail, you can probably configure it to forward outgoing mail through the ISP mailserver and mask it's own involvement.

Both of those spam assasin hits look like they are byproducts of your network & hosting arrangement. I'm not sure there is any way to address them directly, and even if you can, there are probably other rules that will cause a big hit against your messages, like realtime blacklists, and reverse DNS.
posted by Good Brain at 9:34 AM on July 10, 2006

sorry, I'm a bonehead, I missed the part about the smarthost, which means most of my post is useless.
posted by Good Brain at 9:37 AM on July 10, 2006

Get a report from Pivotal Veracity, Return Path or some other email deliverability vendor. There's at least 2 or 3 other companies that do this.
posted by GuyZero at 9:44 AM on July 10, 2006

Are you *sure* smarthosting is working as you expect? (You've checked the logs to see that everything going out is connecting to the smarthost?

Yes, everything's routed through my web host. The first Received: header though shows my own miserable dynamic IP.

The "deliverability vendors" mostly seem to use their reports as tools to sell their own services. I don't want to spend $400 to register as Sender Score Certified™.
posted by Eater at 9:59 AM on July 10, 2006

Any tips for keeping email I send out of the recipients' spam folders?

I guess the answer to that question is a question: if there were a foolproof way to avoid spam blockers, don't you think the spammers would have found it and started using it, leading to the spam blockers plugging the hole?
posted by Steven C. Den Beste at 10:32 AM on July 10, 2006

Some of the reports, like the ones I see from Pivotal Veracity, are pretty useful by themselves.

It may be your IP that's the issue, it may be the email contents. There are few clear-cut answers is the murky waters of email deliverability.
posted by GuyZero at 10:51 AM on July 10, 2006

If you can afford to spend an extra $20 a month on a virtual server, you could set up a postfix relay on that static IP, have it strip out the Recieved line that matches your local MTA (using the header_checks config in main.cf), and relay through that rather than your web hosting provider.
posted by cmonkey at 11:11 AM on July 10, 2006

Having spent quite a bit of time lately researching anti-spam controls for a not-yet-started mail "cleansing" service, I'm pretty confident about the problem.

Your hunch was right: your server's on a dynamic IP. Dynamic IPs are the source of a very large amount of spam. The relevant SpamAssassin rules have scores that are just enough to put you over the standard 5.0 threshold, from the look of it.

Your SPF record isn't helping much, because the default score for SPF_PASS in SpamAssassin is only -0.001.

Honestly, your best hope of avoiding these tests is to send your mail through a host that isn't on a dynamic IP block. Get a $10/month server and configure your mail client to use that.

If you want, send an email to the address in my profile, and I'll take a deeper look at the headers and SA rules that get triggered.
posted by CrayDrygu at 3:55 PM on July 10, 2006

@Cray: note that we've established that he's smarthosting outbound mail, and his it's the mail from *that* server (presumably on a static IP at his hosting company) that's getting spam-flagged.
posted by baylink at 7:53 PM on July 11, 2006

@baylink = I knew that. There's nothing about my post I'd like to change.

His mail is not originating from the smarthost. It's originating from his local relay server, which is on a dynamic IP address. The TCP/IP connection to the destination server will be coming from a static IP, but SpamAssassin doesn't know nor care about this. It's going to look into the Received: headers, and see that the originating MTA is on an IP listed in the NJABL DUL.

Of course, I'm not 100% certain of this, because there's all manner of configurations (and misconfigurations) that could affect this. And I haven't gotten an email from the OP, so I can't check out the headers or SA rules triggered for myself.

Regardless, I think that having his email client either use his ISP's mail server, or talk to the smarthost itself, are the best options for avoiding anti-UCE measures.
posted by CrayDrygu at 10:06 PM on July 11, 2006

Ah. SA *does* actually look at the Received headers for this. (I'd speculated, negatively, in my first reply, and your comment wasn't clear on that -- and *I'm* not an SA mechanic, either.)

Then yeah, that is his problem, and the only real way to deal with it will be either to get a static address, or teach the smarthost to lie (rewriting the first Received header), which is unlikely in the extreme.
posted by baylink at 9:52 AM on July 12, 2006