Posts tagged ·

email

·...

Unethical email marketing from ComShop / digitcom.co.uk

no comments

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

no comments

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

no comments

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.

 

Please stop over-engineering your antispam system

2 comments

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.

Filesystem-based greylisting for Exim

no comments

I have written a filesystem-based greylisting engine for Exim. See here for details.

Automatic email archiving

no comments

If you’re on as many mailing lists as I am, you might find this to be handy.

HOWTO: Building a mail server with Exim, Dovecot and Squirrelmail

1 comment

It’s been a while since I’ve blogged, I find Twitter a bit easier to keep updating. In the fine tradition of itch-scratching, I recently rebuilt my own personal mail server based on a virtual private server from Bitfolk using Exim, Dovecot and Squirrelmail. You can find the HOWTO here, I hope you find it useful.