Category Archives: Tech

Technical things that might help someone someday.

Testing postfix header_checks with postmap -q

This post makes some assumptions, for example that you use Postfix, Ubuntu, and regexp format for your header_checks, etc. but I find that testing new rules isn’t all that well documented and I always forget how to do this.

Testing header checks with postmap -q:

For a single line:

postmap -q "From: my spammer" regexp:/etc/postfix/header_checks

If you match a “REJECT” line you should get “REJECT” as a response. If you get nothing, your rule isn’t working. You can make the switch -vq (has to be in that order) to get verbose logging, but I don’t find that really helpful. It either works or it doesn’t and you’re not going to get any special regexp help from postmap.

If you’ve saved spam message headers to a file (ex: /tmp/spam.txt), do this:

postmap -q - regexp:/etc/postfix/header_checks < /tmp/spam.txt

That second dash is important or it won't work.

Jawbone / myTalk Password Breach

Today I received an email from Jawbone explaining that their myTalk customer password list had been stolen by hackers. They say passwords were encrypted, but they do not say how they were encrypted. If they used pig latin to encrypt, then I should immediately go about ensuring that the password I used on the myTalk web site is not used anywhere else. But if they used bcrypt or scrypt with a high work factor and a random salt, I would be somewhat less concerned about this. Not that I wouldn’t check it, but I might do so after lunch, as opposed to, say, right now.

Of course they don’t say what encryption method was used for the passwords, which leads me to believe it leans toward the pig latin side of things, as they don’t feel confident in reassuring their customers that hackers will have to work very hard to obtain the plaintext passwords.

I was going to write to Jawbone and ask them what encryption method they used, but I bet they would first think I’m the guy that stole their data (most of their employees probably don’t even know that most modern encryption methods contain a header of sorts that says what algorithm was used, so the hackers already have this information and us customers do not!), and second they wouldn’t respond anyway, or there would be some line about proprietary information, security concerns, blah blah blah. Jawbone, you should know that once the data leaves your control – encrypted or not – it is no longer proprietary. Your customers have a right to know their relative risk and you should have given us that knowledge right away.

We are a China based imaging professionals / Rick photo editing spam!

After years of putting up with Rick and his digital photo editing services crap I think I have finally figured out a way to block these messages.

Here’s the deal. You run a mail server, and you get spam every single day from Rick offering digital photo editing services. You put “We are a china based imaging professionals” into your spam blocker/body_checks and THE MESSAGES KEEP COMING. You can’t figure out why they are still coming. Your rules are working. You forward yourself one of Rick’s messages and it is blocked. Yet they keep coming from China.

The answer is in the mail log:

Jan 19 19:23:37 dallas postfix/cleanup[21010]: 774CC582A5: info: header Subject: =?GB2312?B?RGlnaXRhbCBQaG90byBFZGl0aW5nIFNlcg==?=??=?GB2312?B?dmljZXM
gLSBQaG90byBDdXRvdXQgLSBQaA==?=??=?GB2312?B?b3RvIFJldG91Y2hpbmc=?= from[]; from=XXXX to=XXXX

I have Postfix report message subject lines in the log because it makes troubleshooting mail problems easier. Look at the Subject: header of this message. It begins with “=?GB2313?B?…” if you take that whole string and put it into Google you get no hits. But if you truncate to just the part I quoted above, you get some very interesting results. GB2312 is the character encoding for Chinese simplified. So Rick figured out that if he encodes his emails using that character encoding but such that the decoded email appears in US English ASCII characters (A-Z|a-z|0-9) then we’ll all get to read about his photo editing services in a language we understand.

Solutions vary – blocking this encoding string in the headers is what I’ll be doing (along with some other encoding strings). There are other articles on this topic once you know what to search for, with various strategies depending on your needs and your email system.

In my case I’m just adding this line to my header_checks:

/^Subject: .*?GB2312?B?.*/ REJECT # No chinese encoding please.

Happy spam-blocking!

Edit: One thing to note. I had a rule set up in Postfix that printed the email subject line in the logs (it’s my mail server, I can do what I want):

/^subject:/ INFO

This line appeared first in my header_checks file, but since only one rule can fire per email header line, after I added this to the top of my header_checks, Rick’s email started getting through again. Sure enough, testing one of his headers with:

postmap -q 'Subject: =?GB2312?B?' regexp:/etc/postfix/header_checks

resulted in:


instead of:


because only the rule that writes the subject to the log was being run. So I moved that rule to the bottom of header_checks. Now the messages with Chinese encoding are blocked (REJECT) and if any mail does get through, the subject line is written to the logs.

SPF records and Payflow Link

EDIT – Update January 3, 2013: There was a bug in my previous SPF record below, that included “ip4:”. That should have read “ip4:”. Unfortunately the initial incorrect record allowed half the Internet to pass SPF tests, so it would be better to use the corrected version or edit this list to suit your tastes. The SPF record below has been corrected to reflect this change.


If you use Payflow Link and you’ve recently implemented an SPF record with a hard-fail (“-all”), you and your customers may periodically stop receiving transaction confirmation messages from Paypal’s servers.

Your mail logs will hopefully show an error like:

2011-10-22 17:09:12 [] F=<REDACTED EMAIL> rejected RCPT <REDACTED EMAIL>: SPF: is not allowed to send mail from REDACTED DOMAIN

So the question is, what IP address or block should you add to your SPF record to allow PayPal’s servers to send mail on your behalf? PayPal has a range of IP addresses of course; their transaction servers are different from the email servers (apparently).

The correct answer is here, in PayPal’s list of “IP Addresses for PayPal servers”:

Since there are so many IP ranges here, my SPF record was getting too long. So I used the include: directive and created an SPF record for a subdomain (

“v=spf1 ip4: ip4: ip4: ip4: ip4: ip4: ip4: -all”

And then in my main domain SPF record, I added “include:”. This allows me to easily make edits to the PayPal portion of the SPF record and keeps it separate from my main SPF record. PayPal makes IP address changes on average perhaps twice a year, so if you use PayFlow to send transaction receipts to your customers on your behalf and you maintain SPF records for your domain, this is something you will encounter.

At the bottom of PayPal’s post, there is an option to subscribe to the answer so you can be alerted when it changes. Unfortunately they do not show a changelog; they just update the answer, so every time they change it you have to go through and compare every IP range with your SPF record, but at least you can be alerted when there is a change.

Previously, I had looked back through some transactions and (since a recent IP address update) all of them seem to be from 66.211.x.x, so my ham-fisted approach was to add:


to my SPF record, to allow –

Android sends read receipts automatically

I was surprised recently when someone responded to a read-receipt showing when I had read one of their messages. Like many others, I turned off Outlook’s option to send read receipts automatically many years ago. Since I had just changed Exchange 2010 mail providers, I assumed that I had missed this option and simply needed to re-check it on my two computers that use Outlook.

I was wrong. After checking both Outlook installations, the option never to send read receipts was still selected. Turns out my Android phone (running Gingerbread) sent the read receipt, and there’s no option to turn this off in the default mail client.

I never send read receipts because I do customer-facing email and I don’t necessarily want customers to know when I am reading emails, particularly if I want to take some time to craft a well-written response to their inquiry. They could misinterpret the delay as lack of attention to their issue, when in fact just the opposite may be true.

I ran some tests on this, and things don’t appear as bad as they seem. Android’s mail client does not appear to send the read receipt the moment you read the message – it actually sends it along with your reply, and it appears (with my limited testing) that the read receipt actually shows the “read” time to be the same as the reply time, not the actual read time. In other words, I sent myself an email at 3:01pm, read it on my Android phone at 3:02pm, and replied using my Android phone at 3:09pm. The read receipt that came back to the originating email address showed that the message was read at 3:09pm instead of 3:02pm (the latter being the first time I actually opened and read the message).

Even so, I don’t like mail clients sending anything without my approval. For some corporate Exchange users, you might be able to have your Exchange administrator block read receipts, but it is probably a server-wide setting, so don’t be surprised if you encounter some organizational push-back, or at least a lengthy discussion about it first.

In my case, I happen to route all my mail through a primary server that runs Exim first, before passing it along to my main Exchange server and a backup server. So I added the following line to my /etc/exim.conf:

headers_remove = Disposition-Notification-To : Return-Receipt-To

I added that line to my “virtual_aliases_nostar:” director, right below the first line (“driver = redirect”).

Then don’t forget to restart Exim.

I know this isn’t the very best place for it, because it doesn’t work 100% yet, but it’s a start. What happens is that senders still get delivery reports, but read receipts are no longer sent by my Android phone even when I reply. Looking at the message headers, the Disposition-Notification-To: header and Return-Receipt-To: header are no longer present in messages I receive when the line above is present in my exim.conf file. Ideally the line would be placed in a location that would immediately strip those header lines and prevent both delivery reports and read receipts, but as I mentioned I don’t mind someone knowing that their message made it to my server OK.

Since my server is running cPanel, I’ve done the ultimate evil by editing exim.conf directly in the shell; I will need to figure out how to get this line into the cPanel configuration editor and I’ll post back when I do so.


in cPanel, you can copy /etc/cpanel_exim_system_filter to a new file (I called mine /etc/MYDOMAIN_exim_system_filter where MYDOMAIN is my actual main domain name), then add the following to that file:

headers remove "Disposition-Notification-To"
headers remove "Return-Receipt-To"

This will remove the headers and not be overwritten with cPanel updates (if you leave the default cPanel filters file in place it does overwrite, so be sure to work on a copy).

FVS338 dialup backup fails

If your Netgear FVS338 dialup backup is failing, you might have a firmware problem. Sometime after firmware 3.0.2-21 (and not fixed as of 3.0.7-24), the dialup interface connects and grabs an IP address – it even allows ping, traceroute, and DNS lookups from the FVS338 web interface – but it will not route any traffic from the LAN to the WAN. Your client machines will be able to perform lookups, but no other traffic will route, so the dialup backup is useless.

The solution is to downgrade to an earlier firmware, which you can do from here. Click “Downloads”, then click “Show All Versions” and select an earlier firmware. I can confirm that dialup backup mode works as of 3.0.2-21; if you try a later one and it works, let me know via comment.

Munin and High Loads

Munin, while a great monitoring tool, can be a little bit of a CPU hog. I had installed it awhile back and looked at the graphs just for fun now and then (I’m lucky, my servers are humming along pretty smoothly), but I started noticing load averages were measurably higher than they were before I was using Munin.

You can’t just stop the munin-node service in some cases; if munin-node graphs are generated by a cron job, you have to stop the cron job too. I had an older CentOS server that required removal of the cron job for the munin user, but on a newer Ubuntu server all I had to do was stop the munin-node service the munin cron jobs had squirreled themselves away inside /etc/cron.d/munin and /etc/cron.d/munin-node.

See if you can guess what time the munin-node was stopped:

I decided to just run without Munin for awhile; I’ll turn it back on someday if I need it to diagnose something specific, but I don’t see a compelling reason to run it 24×7 just chewing CPU cycles.

Motorola Xoom USB Dock

I took the stock Motorola Xoom dock (the cheaper one, not the speaker dock) and modded it to provide a USB link to the PC. The mod does not destroy the dock, but it does render the audio-out jack unusable until the mod is reverted. I don’t care about audio-out on my dock, but I do care about being able to drop the Xoom in the dock and have it connected to my PC so I can transfer files easily. Here are the steps and photos. Continue reading Motorola Xoom USB Dock

Google Hacking Me

Update: they haven’t done this in awhile now – maybe they stopped this behavior (October 2011).

(original post follows)

I know this is probably under the radar for most people, but Google, who says “do no evil” tries to hack web sites on a regular basis. Last night, Googlebot (more specifically the host “”) tried to send a made-up QUERY_STRING variable to one of my web site programs. (For those who don’t know, the QUERY_STRING is the stuff starting with a “?” in a long url; it is a way of passing information to a program, similar to submitting a web form). Googlebot tried to send a completely made-up “action” parameter in an effort to see how my script would respond.

Of course since I know what I’m doing, my script kicked Googlebot off and did not reveal anything, but it still ticks me off that a company who says “do no evil” goes poking around in what can only be a nefarious manner, since there is no legitimate reason to pass random parameters to web scripts.