Jan-Piet Mens

Out of curiousity, and with MaxMind's help, I've been tracking which countries send me spam.

The top of the list is headed by Russia with 14% of 6118 messages, followed by the US with 9%. Then comes a batch that MaxMind's GeoLite Country list doesn't know of, followed by Turkey, Ukraine and China.

The breakdown of the top twenty is as follows (in number of messages):

871 RU
581 US
314 --
293 TR
242 UA
207 CN
198 BR
193 ES
184 DE
183 LT
164 AR
160 IT
147 PL
139 GB
131 NL
124 FR
119 CO
116 TH
111 PE
103 RO

This correlates quite nicely with what I recently saw.

Early yesterday, I detected that our outgoing BATV signatures weren't correctly being verified upon being returned to us, and some Exim debugging confirmed that:

13:06:15 15374 prvscheck: received hash is b745ee
13:06:15 15374 prvscheck:      own hash is b745ee
13:06:15 15374 prvscheck: signature expired, $pvrs_result unset

Unfortunately I had to disable BATV until that was fixed.

Tom Kistner quickly found the error, which as I'd supposed was a miscalculation in the date. He writes:

Not your fault. An off-by-one error in the expiry date calculation. This happens every
1000 days only. Next occurence would be early in 2011.

which is great, because I don't have to hurry to apply the patch.

And without the patch? Today everything works as expected:

07:45:37 32621 prvscheck: received hash is 5f859e
07:45:37 32621 prvscheck:      own hash is 5f859e
07:45:37 32621 prvscheck: success, $pvrs_result set to 1

Now tell me: do you get that kind of support with your multi-million Euro/Dollar enterprise agreement from your wiz-bang company? No. You don't. That kind of support, you get only with Open Source.

I got an out of office message to a message I sent last night:

Our email server has been out of whack. If you've sent me an email in the past few days, and I haven't responded, please either resend it, or call me at xxxxxxx to confirm receipt.

Oh, yes: they do use Exchange.

E-mail administrators (real ones) make sure e-mail messages are accepted by a mail exchanger only if its intended recipients really exist. If a recipient doesn't exist, the Mail Transfer Agent (MTA) should inform the sending MTA during the SMTP transaction and refuse to accept the message.

There are thousands of incorrectly configured MTA on the Internet that accept a message first, to then find out that it is undeliverable. They then create a Non-Delivery Report (NDR) that is sent to the envelope sender of the original message.

Now consider a spammer who sends out millions of messages with a faked sender address. Consider further, that the faked address is your address (e.g. you@example.net). Who, would you say, is going to get all the Non-Delivery Reports sent to her mailbox? Right: you.

A method to overcome this is for you to modify outgoing envelope addresses, giving them some sort of random value that expires over time. Doing so means that a legitimate NDR can be delivered within, say, a week, but no longer after that (the address expires and if it is used, your e-mail server just refuses to accept the bounce).

All this is called Bounce Address Tag Validation (BATV). In simple terms, what it does is to transform your envelope sender (you@example.net) to something like prvs=you/0192884@example.net. Note the magic key, generally an SHA hash of a date and a magic key you define. When a legitimate bounce returns, your mail server converts that back to you@example.net if, and only if, the key and the date can be decoded.

I've postponed implementing BATV for far too long; work-load was such that I just didn't get around doing it. Because of a huge load of backscatter we've been getting, I've implemented BATV on our Exim gateways. It isn't difficult to do, and this will give you a good idea of what to do. One comment however: depending on your setup, you'll want to place the batv_redirect router as high up as possible in your Exim routers list, to ensure that routers have a translated version of the recipient's e-mail address.

And how well does it work? Well, in our environment, we caught over 2000 fake bounces in the first few hours. Pretty good, I'd say.

I've stopped using Apple's Mail.app (Mail.app yok) on the Mac, and I'm back to using Thunderbird. Thunderbird properly supports IMAP IDLE, correctly identifies the number of unread messages in folders, and just works better than Mail.app, for me. It also supports Growl, which I enjoy using.

Mail.app is more beautiful, but I can live with that.

Glancing over the subjects in a spam folder used to be entertaining at times; I got the odd grin on my face once in a while.

The situation has changed for me, though: look at this morning's catch:

How the hell am I supposed to get a laugh out of that? Would you guys please revert to some language I can read? I'm not willing to start learning your lingo.

Dear Wanadoo/Orange, I have a request:

The next time you decide to alter conditions of service to your paying customers, I would greatly appreciate if you informed my father (one of your paying customers in France) about your intentions. I don't expect you to do so very long in advance, but a couple of days forewarning would be great.

Case in point is the denial of service on TCP port 25 (SMTP) for outgoing connections, which you have cut off for most targets. You have also disabled outgoing connections on TCP port 465 (SMTP over SSL) and TCP port 587 (mail submission). That isn't a grave issue, as you provide mail submission on your network for authenticated clients, but you could have informed your customer before knocking the service down.

It cost me the better part of several hours to get his systems up and running again. Not necessarily because he or I are too daft, but rather because diagnosis and repair at a distance approximating six hundred kilometers is a major pain in the ass.

Thank you for your understanding.

Do you like this skyline?

Actually it is a graph of mail server usage…