SpamCop RBL is Blocking Several Facebook Mail Servers

If you are using the SpamCop realtime block list as part of your anti-spam measures, be warned that they appear to be blocking several legitimate Facebook mail servers.

I’ve seen them blocking the following Facebook mail server IPs:

  • 69.63.178.169
  • 69.63.178.172
  • 69.63.178.175

Presumably there’s a whole block of IPs that SpamCop is blocking. Since I like to get e-mail from Facebook, I have currently disabled my SpamCop RBL check. You may want to do the same.

Please Stop Using Yahoo Mail

Yahoo mail servers have been consistently delaying or rejecting e-mails for over a year. You can read about it here:

http://www.ahfx.net/weblog.php?article=107

Or just Google for “4.16.50″.

The short of it is that even with a low volume personal mail server, with the correct spf records, without running an open relay, without being blacklisted by ANY blacklist site/service, Yahoo still won’t deliver e-mail from you. And they aren’t responsive about addressing the problem.

So please, if you use Yahoo mail, switch to GMail. You’ll like it more, and more importantly, you’ll actually get e-mail people are trying to send you.

10MinuteMail Performance Improvement

After having a clearly better approach to mail delivery pointed out to me by a friend yesterday, I pushed a new version of 10MinuteMail out last night. End users shouldn’t notice anything different, but behind the scenes the mail acceptance and delivery is MUCH higher performing. There should be less incoming mail delays, slow pages, and less domain changing. Inactive e-mail addresses will return a bounce notice now, as they probably should have done from the start.

I apologize for the delivery issues yesterday, before I made the change, the amount of incoming junk was really slamming on the server. Hopefully that’s a thing of the past now.

10MinuteMail Updates

I just pushed a new version of 10MinuteMail. Here are the notable updates:

  1. Removed the Ad-Aware links and text. No one was clicking on them anyhow.
  2. Added some translation fixes.
  3. Implemented AJAX based (RichFaces) refreshing of the list of e-mails in your inbox.
  4. Added smtp client throttling (in Postfix) to limit the number of messages accepted from a single source within 60 seconds. This seems to have already fixed the negative impact of high volume spammers on the function of the site.
  5. Removed the “Get Another E-Mail” feature. While this was a user request, I discovered that it was being abused by spammers.
  6. Added a Forward feature to allow you to forward a received e-mail to your home account for storage.

Enjoy! If you have any issues with the AJAX refreshes, let me know, but I think it should work better now.

How to cleanout your postfix queues by sender

This post is mostly to help me remember how to do this, if the situation arises again.

I just had a lot of mail backup on my server. The 10MinuteMail inbox was over 300 MB (usually it kept below a megabyte), Postfix’s active queue was maxed out at 20,003 entries (why the 3, I don’t know), and the incoming queue was another 20,000+. Basically everything was all backed up. I’m not 100% sure how this condition gets started. I’ve seen it a few times on my old server when super high volumes of incoming mail deliveries combined with other sites I hope serving up high bandwidth to end users. This is the first time it’s happened on the new server. It may be time to change out the domain that the 10MinuteMail e-mail addresses are using.

Regardless, using qshape I was able to identify a handful of from addresses (presumably either spammers or a cyclic bounce issue) which accounted for over 8,000 of the mail in the active queue. By using the following command I was able to purge out just those messages from the queue:

mailq|awk ' /^[0-9A-F][0-9A-F]*.*error.mag2.com$/ {print $1}'|tr -d '*'| xargs -rn1 postsuper -d

Where error.mag2.com is the domain, or from address you wish to delete. This works pretty well. I may whip up a bash script to handle this in the future.

For reference, the worst offenders are:

  1. magerr.combzmail.jp
  2. prjapanmail.jp
  3. error.mag2.com
  4. accessmail.jp
  5. mayld.net

Why so many from Japan? I have no idea….