Communicado update: A change of tactic

The work to make Communicado’s life as difficult as possible continues and it does seem like we’re having some success.

When I started this project, Communicado registered all their domains through DAILY mostly using faked registrant data and hiding behind the privileges granted to individual private registrants.  I established a dialog with Nominet about this and it seems Nominet did take action to the point of suspending some of these domains.   Communicado then suddenly switched to using ENOM for registering their domains, I don’t know and have no way of knowing if they were booted off by DAILY or just decided to switch.  Either way, it made no difference, I could easily find the domains they were registering via Nominet’s PRSS tool.

As of Monday 16th, they have changed tactics again.  They have apparently abandoned the .co.uk namespace (I’m sure they’ll be missed) and have gone back to using a variety of .com, .net and .org domains.  Some seen in use today are:

actionallegiance.com
andronol.com
baotao.org
bigrockconsultants.com
coolpress.net
europacastno.com
greenroses.org
hourlycreative.com
pidchas.com

They’re easy enough to spot in the logs, but I don’t currently have a good way of searching the whois for these TLDs. Suggestions for such a tool (non-free is fine) are welcome.

Maintaining this list and the RBL service is taking time and money.  I will absolutely never be charging anyone for the list and the RBL will be free and open access for as long as it is sustainable to do so.  In addition to the ways you can help mentioned in previous posts, a more direct way you can help is to donate a little money, preferably in the form of Bitcoin to 1F9Y1Gd3Pmmchxa7uGFd3zBQY9zVuX78Jd.

More news when I have it, you can follow @Excommunicado for more frequent updates.

An update on Communicado

It has been a busy few weeks since I first blogged about Communicado, here are some of the highlights of what has been going on.

  • Communicado are still registering somewhere between 40 and 60 new domains a week.  The blacklist is being regularly updated and currently has 5364 domains listed.
  • Communicado appear to have switched registrars from DAILY to ENOM as of yesterday.  Makes no difference to picking up their domains.
  • Nominet has been investigating and tell me that some of Communicado’s domains have been suspended and they are in the process of suspending more.
  • Please follow @Excommunicado for news and announcements on Twitter.  Low volume, only on topic.
  • The existing text file download will continue to be updated but, by popular demand, I have set up a DNS RBL containing their domains.  As of the time of writing it is open access, that may change if it becomes too busy.  Using it is easy:
martin@olga:~$ host malimanosa.co.uk.excommunicado.co.uk
malimanosa.co.uk.excommunicado.co.uk has address 127.0.0.2
martin@olga:~$ host flobbletob.co.uk.excommunicado.co.uk 
Host flobbletob.excommunicado.co.uk not found: 3(NXDOMAIN)

If anyone wants to provide working configuration examples for SpamAssassin (or other similar tools), I will cheerfully link to them or post them here.

More news when I have it, have a Communicado-free afternoon!

Cooperative Energy and password security

As a protest vote against the Big 6 energy companies, I recently switched supplier to Cooperative Energy.   Switching is painless, fill your details in online, click the button and off you go.   They do of course want a password from you and I used LastPass to generate a unique one for me and memorise it.

Some time later, I went to login in to the customer portal just to see what I could do and was quite surprised to find my password didn’t work.  I mentally shrugged and clicked on the Forgotten Password link and waited for the usual password reset email to arrive.  I got this instead:

Dear Customer

The information you requested is…
eg!3fP^P*hVFs

If you have any questions please contact our customer service team

(This is, of course, not my actual password, this is just an example that I’ll treat the same way as the Coop did.)

Here we have two immediate problems.  The first is, of course, they have sent me my password in plain text in an email.  We all know that’s a bad idea.  Secondly, what they have sent is not actually my password.  My password looks like this:

eg!3fpp*hvfs

See what they did?  For whatever reason the caret has been removed and all the letters have be converted to lower case thus making my password less secure.    I sighed and went to change my password online and found I couldn’t.   If I want to change my password then I have to go talk to a human to do so.   This leads to problem three, which is that people generally pick stupid passwords and reuse them.   I’m sure Coop Energy only employ wonderful honest people, but giving them an email address and a stupid password is only ever going to end badly for someone eventually.

I’ve spoken to Coop Energy’s customer service team and they acknowledge the problems I’ve found.   Let’s hope, for the sake of a safer and more secure internet, they sort them out.

Unethical email marketing from ComShop / digitcom.co.uk

Just a few minutes ago I received an unsolicited commercial email from ComShop / DigitCom. It was a multipart text/html email and I have reposted the HTML part verbatim here.

I don’t recall ever having bought anything from these guys, but I buy a lot of stuff online, so I gave them the benefit of the doubt and clicked on the unsubscribe link at the bottom of the page.  That’s when I started to get a little suspicious, the URL I was being sent to contained no information that could identify me to the site.  The unsubscribe link points here and, just on the offchance it disappears, I’ve also put it here (the image does not display).  Look at the source, it’s just static HTML.

In other words, their unsubscribe link does nothing at all, whilst claiming you have been unsubscribed.  That’s breathtakingly deceitful.

Enjoy the publicity guys.

Email: Managing users’ expectations

That email has established itself as a universal communication medium is a credit to all those who contributed to the standards that define its implementation.

Truly, only “www.” is a more familiar as an Internet medium for information exchange and, even then, HTTP is routinely dumbed down to “it’s on my Facebook” and other similar paradigms.   This is not a criticism, it’s a tribute to the Internet’s ongoing integration into our everyday lives.

People seem desperately confused about email.  It’s an aged beast and it suffers from having been reinvented and redefined over a long period of time to meet the demands of a succession of users with different expectation levels.

Stepping back a bit, SMTP  as a protocol was originally designed to be incredibly tolerant of all kinds of problems.  It had to be.  Shonky links, low bandwidth and infrequent network connectivity meant we needed a protocol that could deal with the idea that messages could be significantly delayed.  SMTP has a built in a mechanism for notifying when things aren’t going well, and makes a really good effort to tell a sender that things didn’t work out and the message didn’t make it. Then things changed.

Sending files over the Internet is sometimes hard.  I know!  Let’s extend email so it can transfer files.

Not everyone can type in 7 bit ASCII. I know! Let’s extend email so all character sets can be represented.

Sending messages in plain text isn’t always desirable. I know!  Let’s extend email so it can handle PGP/GPG mail.

Attachments are okay, but what if there were some way my image could appear in my email body. I know! Let’s extend the message format so it can do that.

Text is boring. I know! Let’s extend email so I can send HTML content.

 

You get the idea.   Email has evolved far beyond the original specification and still fails to meet users’ expectations.  And it should not, because they confuse email with instant messaging and with a reliable file transport mechanism.  If your users want messages to be delivered instantly, use an instant messaging system, not email.  If you want files transferred, use some kind of file transfer protocol.   Anyone training users to expect anything other than “it’ll almost certainly get there, probably today” out of email is creating a rod with which to beat themselves when deadlines tighten.  The right tool for the right job.

 

 

 

 

 

How to get less junk email

I am fairly frequently asked for tips on getting less junk email.  There’s quite a few things you can do that will cut the amount of junk you get, or at  least let you get an idea of where it came from.

 

  • Don’t have a catchall account, only ever accept mail for real mailboxes.
  • Use as few generic or role addresses as you can.  sales@, info@, help@ etc will all draw in unwanted junk.
  • Delete or disable legacy mailboxes, don’t alias them to another user’s mailbox.
  • Use different email aliases for different sites.  So I might have  martin-slashdot@ for Slashdot,  martin-elreg@ for The Register, martin-dominos@ for Dominos etc etc.   If mails arrives to these addresses, and it’s not from that specific organisation, then something has leaked when it shouldn’t have.
  • Once you’ve finished with a particular site, remove the alias.
  • Don’t be afraid to pick up the phone.  If you get email you didn’t want from a company, call them to get yourself removed. Where you’ve had no contact with a company before, tell them politely that they are breaking the law by sending you unsolicited email.
  • Understand the difference between spam and UCE.  With spam it is rarely worth your time tracking down the sender, UCE may well be.
  • Don’t click on unsubscribe links in spam messages.  Do click on unsubscribe links in UCE messages.  With the latter, if the unsubscribe isn’t instant (“It may take up to 10 days….”) then blacklist the sender.

 

And, of course, if junk mail really is a big problem for you, consider using a commercial anti-spam and anti-virus filtering service to get rid of it.  Obviously I would recommend antibodyMX, but there are plenty of other providers out there.

 

Recent Debian update breaks Squirrelmail / Avelsieve

I’ve not yet tracked down exactly when and where this crept in, but recently when logging in to my web mail, I’ve been seeing an error message like this:

Could not log on to timsieved daemon on your IMAP server localhost:4190.

I was puzzled because I’d not knowingly changed any configuration for either Dovecot or Squirrelmail and Dovecot’s sieved was still listening right where I expected it to be on port 2000.  After a little digging I found in /usr/share/squirrelmail/plugins/avelsieve/config/config.php this section:

/* ======================================================================== */
/* =================== ManageSieve Backend Options ======================== */
/* ======================================================================== */
/* Port where timsieved listens on the Cyrus IMAP server. Default is 2000. */

/** DEBIAN CHANGE: Despite upstream's intention Debian changed this default
*  distribution wide to 4190 which is thus default here.
*/
global $sieveport;
$sieveport = 4190;

Well duh, thanks.  Setting this value back to 2000 fixes the problem.  Though perhaps, at some point, Debian will ship a default Dovecot configuration with the sieved on port 4190.

Please stop over-engineering your antispam system

I’m obviously entirely partisan here, having a significant interest in an antispam and antivirus email filtering service called antibodyMX.  That aside, can I please ask you mail administrators to stop making make filtering decisions based on really, really, shonky premises?  Thanks.

Today I responded to a posting on a mailing list for the MTA that antibodyMX is based on.  The point of the the post isn’t really relevant here, save that the sender was seriously suggesting that the list adopt a standards-breaking policy, but I responded citing a technical issue and was surprised when my email to the original poster was rejected.

The reason it was rejected was that the original poster had decided that the presence of the word “adsl” in the DNS-resolved name of the connecting host was an indication of a spam-sending host.  This is an interesting idea, and for the non-technical reader, it’s best summarised as being bollocks.

The reasoning behind this idea isn’t, well, unreasonable.  Most Internet users these days are on some kind of ADSL connection and most use the cheapest ISP they can find. Most forward/reverse DNS entries for IPs in these ranges look like “adsl-1.2.3.4.SomeISP.net/1.2.3.4”. Many of these users have simply no idea about sensible security so thousands of these home PCs are spam zombies. Is it so bad to assume that mail traffic from such ranges is bound to be spam?

Back to my rejected email.  The regular expression rule the mail system owner had decided to use was badly flawed. It decided that my mail server called “olga.hinterlands.org” looked so much like the word “adsl” that rejecting mail from it (hey! all the right letters are there!) was the sensible thing to do.  Subsquent emails went along the lines of “so what if I do <this>?”  “No, that’s broken, too”  “And how about _this_?” “Sorry”.

This worries me for lots of reasons.  Firstly, a lot of perfectly legitimate email comes out of ADSL ranges.  Small companies use these all the time.  Secondly if you must enforce this sort of thing, (your server, your rules after all), at least bother to test your filtering is doing what you expect.   Test the damn thing and don’t make other email administrators have to deal with the fallout from your local policy.