Continue reading »]]> My last post contained two (non-existent) email addresses in my baldric domain in the extract from my postfix logs. As I said in the post, I had edited the log entry specifically to mask real details. Yesterday, only four days after that post, I received spam email attempts at those addresses.

As I have said in the past, if you don’t want spam, don’t publish your email address.

Continue reading »]]> In January of this year I wrote about t-mobile’s apparent policy of actively looking for and blocking any TLS-secured SMTP sessions over their network. At the time I believed this to be a cockup rather than a deliberate policy. I still prefer to believe that, but the episode left a rather sour taste in my mouth. So this month I took the opportunity presented by the end of my contract to shift to another provider. Of course, in doing so I gained a nice shiny new ‘phone which meant that I could spend a fun few hours setting it up the way I wanted it and nailing it down as much as possible so that it didn’t leak all my data to google. This is unnecessarily difficult, and much harder than it should be (and I know that people like Peter H will simply tell me that I shouldn’t be using an android ‘phone in the first place). But that is not the point of this post.

Like most people these days, I use my ‘phone to pick up email. The standard email client on my last ‘phone was pretty uninspiring so I used K-9 mail in its place. K-9 is a pretty good application, but it has a silly little bug in it which is still not sorted properly. This bug manifests itself in a rather odd, and unpredictable way – K-9 seems to “forget” the X509 certificate used to protect the authentication process if that certificate is self-signed, or otherwise not verifiable by an external CA. The cure, such as it is, is to simply refresh the certificate by reloading the account settings and accepting the cert when K-9 warns you that “TrustAnchor found but validation failed”. The length of time between accepting the cert and K-9 “forgetting” it again seemed random to me, so I got into the habit of refreshing my account settings whenever I noticed that I hadn’t received any mail for a while. Annoying, but not ultimately a deal breaker for using what was otherwise a pretty good application.

So, the first application I looked at on my new mobile was, of course, email. The default mail client on this new phone looks a lot slicker than the old one on my previous phone, but then it is a much newer ‘phone, from a different manufacturer and the android version is much newer too, so no real surprise there. The setup seemed to have no problem with my self signed certs so I thought I might stay with the default to see if it would solve my annoying little problem with K-9.

Unfortunately not.

Whilst I had no problem with incoming mail over my IMAPS connection, all attempts to send mail failed. On checking my server logs I found the following (real details changed or obfuscated):

Mar 20 20:45:57 pipe postfix/smtpd[7594]: NOQUEUE: reject: RCPT from home.baldric.net[12.34.56.78]: 504 5.5.2 <localhost>: Helo command rejected: need fully-qualified hostname; from=<null@baldric.net> to=<noone@baldric.net> proto=ESMTP helo=<localhost>

Aha! My postfix configuration is set up to reject hosts which do not have valid hostnames or do not announce themselves with fully qualified domain names (i.e. names of the form “host.domain”). Now since I use SASL authentication in my postfix configuration the fix is relatively easy; just ensure that the stanza “permit_sasl_authenticated” appears in both “smtpd_sender_restrictions” and “smtpd_helo_restrictions” before “reject_non_fqdn_hostname” – thusly:

smtpd_helo_required = yes
smtpd_helo_restrictions = permit_sasl_authenticated, permit_mynetworks, reject_non_fqdn_hostname, reject_invalid_hostname
smtpd_sender_restrictions = permit_sasl_authenticated, permit_mynetworks, reject_non_fqdn_sender, reject_unknown_sender_domain

(In fact, this episode highlighted an error in my postfx configuration because my helo restriction was inadequate. By now checking the authentication before the helo restriction kicks in I am still well protected, but mail from valid authenticated users is permitted.)

I am in that (very) small minority of people who run their own mail servers and are able to change server side configurations. But, and this is a big but. I should not have to change the server side configuration to accommodate a broken client and the vast majority of people will not be able to do so anyway. Almost all well set up mail servers will reject mail where the client connection announces itself in the helo exchange as “localhost”. That is normally an indication of a spammer, indeed spamassassin will allocate a high score to any mail which is so flagged. This means that there will be a huge, and growing, number of people who cannot send mail from their android ‘phones.

If this is the default android mail behaviour, then google need to fix it now. Meanwhile, K-9 is looking attractive again.

Continue reading »]]> Today I received two (make that four now – must sort out my spam filters) phishing emails from a source new to me. Each email purported to come from “linkedin” and each invited me to login to respond to “invitations from your work colleague”. Since a) I have never been a member of linkedin, and b) am retired, the invitations immediately looked suspect, but the return address looked real at first sight. That is, until I looked more closely. The actual address used was linkedln.com (with a second letter “l”) rather than the correct linkedin.com.

Nice try.

Continue reading »]]> From a peak of around 25,000 mail drops per month in the backscatter I was getting from the .ru domain to the non-existent address “info@baldric.net” I am now seeing virtually none. My logs show a distinct drop off from mid to late December last year to about 10-15 emails per day (when I had previously been seeing anywhere between 600 and 900 per day). Since then the trickle has slowed to a crawl. I now receive only a handful a week, with most days being completely clear.

I wonder where they have gone.

Continue reading »]]> The volume of spam backscatter I am receiving at the baldric.net domain currently runs at around 18-20,000 emails per month, nearly all of which is aimed at the info@ address I have mentioned before.

My mail server is currently configured to reject mail to non-existent users at the SMTP level with a permanent failure message like so: “550 5.1.1 : Recipient address rejected: User unknown in virtual mailbox table:” Rejecting mail at this stage, rather than accepting it only to bounce it later is the “correct thing to do”. This way the sending MTA gets a failure message in its logs and the mail it was attempting to send to me never leaves its queue. If the mail admin at the other end is in any way savvy, then he or she is given enough information to allow them to investigate and, perhaps, cure the problem. But of course that assumes two things: one she /is/ savvy; and two, she actually cares enough to do anything.

Now there is nothing I can do about the second problem, but if there is any way I can provide additional information which might help the hard pressed admin understand why they might have a problem, then that would aid them, me, and any of the likely hundreds or thousands of other people out there who will be receiving crud in response to mails they didn’t send.

One possible way forward might be to add some additional information to the SMTP rejection message – something along the lines of “hey, you might have a configuration problem here, please consider investigating”. Now I dislike re-inventing wheels (and I’m lazy) so I spent a short while searching for possible modifications to my own postfix configuration which would do the trick. Sure enough, I quickly discovered backscatterer.org and its suggested modification to main.cf (though note that it assumes that postfix is using the dbm database library – not all of them do, particularly on the default debian install). Hey, that looks cool, so if I modify my configuration slightly I will be able to run a lookup against backscatterer’s DNSRBL and in cases of a hit I will send an SMTP reject message that looks like this: “554 5.7.1 Service unavailable; Client host [217.77.96.18] blocked using ips.backscatterer.org; Sorry 217.77.96.18 is blacklisted at http://www.backscatterer.org/?ip=217.77.96.18;” instead of the much less informative message above. Now the sysadmin at mx2.infopac.ru (217.77.96.18) will get a much more useful log message. Won’t they?

But hold on a moment, where does backscatterer.org get its RBL? Can I trust it? And am I being fair on the sending domain if I block all mail coming from there based on the simple fact that they are listed in some third part RBL? That feels a little like SORBS to me. Turn the question around. Would I, as admin for the baldric.net domain (and a dozen others) be happy if mail from my domain to some servers were blocked because I had chosen to implement something like “sender callouts” (unlikely as that might be). Worse, backscatterer.org “offers” to de-list any server from its database if you pay them 85 euros (OK, so that will only be about threepence halfpenny in a few weeks time when the eurozone finally tanks, but it is still extortion, whatever the actual sum).

So I think I’ll stay away from backscatterer – it looks like a scam to me. I’ll just have to find another way of telling my Russian sysadmin friends that their servers are “misconfigured”.

Continue reading »]]> Like most email users I get my fair share of spam and other internet crud. Mostly I ignore it, but I received an intriguing email a couple of days ago which purported to be a mailer daemon “Delivery Status Notification” informing me of a failed delivery to some address I had not even heard of. Mostly this sort of junk results from backscatter from mailers responding to spammers spoofing your email address in the outgoing mail. I get a lot of this to the “info@baldric.net” address as I’ve mentioned below.

However, this particular email interested me because the message-id in the headers said it came from a machine calling itself mx1.rlogin.net. Now I own and control that domain and I know that I have no such machine. So I concluded that the machine at the address in question (which looks to be at the end of a commercial cable line) was either deliberately being used incorrectly by its owner, or (much more likely) had been compromised and was being used illegally to send spam mail designed to look like it came from my domain. Either way, I’m not overly happy about that so I decided to contact the ISP and let them know that they might have a customer with a problem.

The normal way to do this is to send email to the “abuse@domain.name” address which is usually listed in the whois record for the network owner. There is even an RFC which codifies this practice. However, on searching a variety of whois records I couldn’t find any obvious address to use. Worse, speculative email to “abuse@the-likeliest-relevant-domain” was simply returned as undeliverable. What to do?

Well as it happens I found a very helpful utility called abuseEmail which automates searches of whois records for likely addresses. Better yet, some helpful people at cyberabuse.org give a web based front end to the abusEmail php script so that you don’t have to run your own.

Continue reading »]]> A few weeks ago I installed pflogsumm on my mail server in order to automate my mail log scanning. For some time I had been conscious that my mailer had been rejecting a lot of mail with “user unknown” but I had never really investigated that in any depth. Running pflogsumm over the logs on a nightly basis makes analysis easy. It turns out that over 90% of all mail hitting my server is rejected because I have no user with the name given. Moreover, practically all of that rejected mail is for one user (info@baldric.net) and it all appears to come from mailers with .ru domain names.

By creating a temporary alias for the failing address to a real one I was able to capture some of the mail coming in. The example below is faintly amusing:

“From: postmaster@ruschermet.ru
To: info@baldric.net
Subject: Не удается доставить: лучший секс в Вашей жизни
Date: Sun, 27 Mar 2011 21:22:42 +0400

Не удалось выполнить доставку следующим получателям или лицам из следующих списков рассылки:

hr@ruschermet.ru
Адрес электронной почты получателя не найден в почтовой системе получателя. Microsoft Exchange не будет повторять попытку доставки сообщения. Проверьте адрес электронной почты и повторите отправку сообщения или передайте указанное ниже диагностическое сообщение администратору.

________________________________
Отправлено с помощью Microsoft Exchange Server 2007″

(Try running this through an on-line translation service such as babelfish).

Clearly, what I am getting is backscatter from failed spam deliveries in Russia where the spammer has used the non-existent “info” as a spoofed from address. Ho Hum.

Continue reading »]]> I own a bunch of different domains and run a mail service on all of them. In the past I have used a variety of different ways of providing mail, from simple pop/imap using dovecot and postfix, through to using the database driven mail service in egroupware.

Recently I have consolidated mail for several of my domains onto one of my VPSs. I don’t have a lot of mail users so at first I stuck with the simple approach available to all dovecot/postfix installations, i.e. – using dovecot as the local delivery mechanism and simply telling postfix to hand off incoming mail to dovecot. Dovecot then has to figure out where to deliver mail. I also used a simple password file for the dovecot password mechanism. This mechanism worked fine for a small number of users, but it rapidly becomes a pain if you have multiple users across multiple domains and you wish to allow those users to change their passwords remotely. The solution is to move user management to a MySQL backend and change the postfix and dovecot configurations to use that backend database.

Now to allow (virtual) users to change their mail passwords, most on-line documentation points to the sork password module for horde. But have you /seen/ horde? Sheesh, what a dog’s breakfast of overengineered complexity. I flatter myself that I can find may away around most sysadmin problems. but after most of a day one weekend trying to install and configure the entire horde suite just so that I could use the remote password changing facility I gave up in disgust and went searching for an easier mechanism. Sure enough I found just what I wanted in the shape of postfixadmin. This is a php application which provides a web based interface for managing mailboxes, virtual domains and aliases on a postfix mail server.

Postfixadmin is easy to install and has few dependencies (beyond the obvious php/postfix/mysql). There are even ubuntu/debian packages available for users of those distributions. I also found an excellent installation howto at rimuhosting which I can recommend.

I can now manage all my virtual domains, user mailboxes and aliases from one single point – and the users can manage their passwords and vacation messages from a simple web interface.

postfixadmin domain creation

Whilst I currently only provide pop3s/imaps mail access through dovecot, postfixadmin offers a squirrelmail plugin to integrate webmail should I wish to do that in future.

Simple, elegant and above all, usable. And it didn’t take all day to install either.

Continue reading »]]> I note from a recent register posting that that some gmail users are objecting to the fact that google’s mail service has failed yet again. El Reg even quotes one disgruntled user as saying:

“More than 30 hours without email…totally unacceptable. I’ll definitely have to reconsider my selection of gmail for my primary email account. It may be I have to pay for an account but hell will freeze over before I pay one penny to Google after this debacle.”

Umm, maybe it’s me, but I fail to understand how anyone can complain when a free service stops working. There is a good reason why people pay for services. Paying gives you the option of a contract with an SLA. If the service you are paying for includes storage of your data (as in the corporate data centre model) then your contract should include all the necessary clauses which will ensure that your data is stored securely, is reachable via resilient routes in case of telco failure, is backed up and/or mirrored to a separate site (to which service should fail over automatically in case of loss of the primary) etc. The contract should also ensure that you data remains yours if the hosting company fails, goes out of business or is taken over,

All of that costs money – lots of money in some cases.

Anyone who entrusts their email to a third party provider without ensuring that that they have a decent contractual relationship with that provider (though a paid contract) is, in my view, asking for trouble. Most email users nowadays are heavily dependent upon that medium for communication. I know I would have real difficulty coping without it. Outside of my work environment, I pay for my personal email service. And I am happy to do so. In fact, on some domains I own, I even run my own mail servers (with backups). That costs time and money, but it ensures that my email is available when I expect it to be.

So, google users, stop whining and think again. A proper email service will only cost you a few pounds – and there are plenty of other reasons for not using google’s email service (not least the fact that your email is scanned by google to enable them to target you with their adverts).