Posts Tagged ‘email’

Досвидания камрад?

Tuesday, February 14th, 2012

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.

t-mobile resets its policy?

Thursday, January 12th, 2012

As I have mentioned in other posts here, I run my own mail server on one of my VMs. I do this for a variety of reasons, but the main one is that I like to control my own network destiny. Back in October last year I noticed an interesting change in my mail experience with my HTC mobile (actually my wife first noticed it and blamed me, assuming that I had “twiddled with something” as she put it). Heaven forfend.

My mail setup is postfix/dovecot with SASL authentication and TLS protecting the mail authentication exchange. My X509 certs are self generated (and so not signed by any CA). I pick up mail over IMAPS (when mobile) and POP3S (at home – for perverse reasons of history I like to actually download mail to my main desktop over POP3 and archive it to two separate NAS backups). I send via the standard SMTP port 25 but require authentication and protect the exchange with TLS.

My mail had been working fine ever since I set it up some years ago, but as I said, back in October my wife complained that she could no longer send email from her HTC mobile (we both use t-mobile as the network provider). She was at work at the time so away from my home network. Both our phones are setup to use use wifi for connectivity where it is available (as it is at home of course). When my wife complained I checked my phone and it could send and receive without problem. But when I switched wifi off, thus forcing the data connection though the mobile network, I got the same problem as my wife reported. On checking my mail server logs I read this:

postfix/smtpd[28089]: connect from unknown[149.254.186.120]
postfix/smtpd[28089]: warning: network_biopair_interop: error reading 11 bytes from the network: Connection reset by peer
postfix/smtpd[28089]: SSL_accept error from unknown[149.254.186.120]:-1
postfix/smtpd[28089]: lost connection after STARTTLS from unknown[149.254.186.120]
postfix/smtpd[28089]: disconnect from unknown[149.254.186.120]

(the ip address is one of t-mobile’s servers on their “TMUK-WBR-N2″ network)

Everything I could find about that sort of message suggested that the client was tearing down the connection because there was something wrong with the TLS handshake and it was not trusted. Checking earlier logs, I found that t-mobile’s address had apparently changed (to the address above) recently. So I assumed that some recent network change following the Orange/T-mobile merger had been badly managed and all would be well again as soon as the problem was spotted. Wrong. It persisted. So I had to investigate further. As part of my investigation of the error, I tried moving mail from port 25 to 587 (submission) because that sometimes gets around the problem of ISPs blocking, or otherwise interfering, with outbound connections from their networks to port 25, No deal. In fact it looked as if t-mobile were blocking all connections to port 587 (I assumed a whitelisting policy block, or again, a cockup).

So, the scenario was: mail works when connecting over wifi and using my domestic ISP’s network, but doesn’t when using t-mobile’s 3G network. Symptoms point to a lack of trust in the TLS handshake. Tentative conclusion? There is an SSL/TLS proxy somewhere in the mobile operator’s chain. That proxy sucessfully negotiates with our phones, but when it gets my self certified X509 cert from the server. it can’t authenticate it and decides that the connection is untrusted so tears it down. My server sees this as the client (my phone) tearing down the connection. [As it turns out, this conclusion was completely wrong, but hey].

I said in an email at the time to a friend whose advice I was seeking, “I suspect cockup rather than outright conspiracy, but if my telco is dumb enough to stick a MITM ssl proxy in my mail chain, they really ought to have thought about handling self signed certs a little better. Otherwise it sort of gives the game away.”

In response, he very sensibly suggested that I should run a sniffer on the server and check what was going on. At that time, I was busy doing something else so I didn’t. And because the problem was intermittent (and my wife stopped complaining) I never got around to properly investigating further. (I should explain that I rarely send mail from my mobile nowadays. I just read mail there and wait until I get home to a decent keyboard and can reply to whatever needs handling from there. My wife just gave up bothering to try).

I should have persisted because of course I wasn’t the only one to experience this problem.

Back in November, a member of the t-mobile discussion forum called “dpg” posted a message complaining that he could not connect to port 587 over t-mobile’s 3G network. In response, a member of the t-mobile forum team suggested that dpg might reconfigure his email so that it was relayed via t-mobile’s own SMTP server. Not unreasonably, dpg didn’t think this was an acceptable response – not least because he would then have to send his email in clear. He then posted again saying that “the TLS handshake fails when the mail client receives a TCP packet with the reset (RST) flag set.” (This is a bad thing (TM). Further, he posted again saying that he had set up his own mail server and repeated earlier tests so that he could see both ends of the connection. At the client side he posted mail from his laptop tethered to his phone which was connected to the t-mobile 3G network. By running sniffers at both ends of the connection he was able to prove to his own satisfaction that something in the t-mobile network was sending a RST and tearing down any connection when a STARTTLS was seen. Again, in a later post in response to one from another poster who apparently manages several mail servers and had been looking at the same issue for a client, dpg says:

“I must say I’m not too pleased to discover that T-Mobile may be snooping all traffic to check for SMTP messages. I have demonstrated that they may be doing this by running a SMTP server on a non-standard port and finding that they still sent TCP reset packets during TLS negotiation – so they must be examining all packets and not just those destined for TCP ports 25 and 587.

I’m also not that keen on T-Mobile spoofing/forging TCP resets. This is the sort of tactic resorted to by the Great Firewall of China (http://www.lightbluetouchpaper.org/2006/06/27/ignoring-the-great-firewall-of-china/) and also by Comcast back in 2007 (https://www.eff.org/wp/packet-forgery-isps-report-comcast-affair) until the US FCC told them to stop (http://hraunfoss.fcc.gov/edocs_public/attachmatch/FCC-08-183A1.pdf).”

Then 9 days ago, dpg posted this message:

“I finally got to the bottom of this. I was contacted by T-Mobile technical support today and was told that they are now actively looking for and blocking any TLS-secured SMTP sessions. So, it is a deliberate policy after all, despite what the support staff have been saying on here, twitter and on 150. They told me it is something they have been rolling out over the last three months – which explains why it was intermittent and dependent on IP address and APN to begin with.

So, the only options for sending email over T-Mobile’s network are:
- unencrypted but authenticated SMTP (usually on port 25)
- SSL-encrypted SMTP (usually on port 465)
- unauthenticated and unencrypted email to smtp.t-email.co.uk

TLS-encrypted SMTP sessions are always blocked whether or not they are on the default port of 587.”

(As an aside, there is, of course, another alternative. You can ditch t-mobile as your provider and pick one which doesn’t use DPI to screw your connections. You pays your money….)

Following this, a new poster called “mickeyc” said this:

“I’ve been experiencing this exact same problem. I run my own mail server which has SSL on port 465 and also uses TLS on port 587. I used wireshark to confirm that the RST packets are being spoofed. This is the exact same technology used by “The Great Firewall of China”. I have two t-mobile sims. One is about a year old and doesn’t experience this problem (yet), one is a few weeks old and does.”

He went to say that he had also experienced problems with his OpenVPN connections and would be blogging about the problem (damned bloggers get everywhere) and sure enough, Mike Cardwell did so at grepular.com. That blog post is worth reading because it has an interesting set of comments and responses from Mike appended.

Mike’s post seems to have been picked up by a few others (El Reg has one, and as Mike himself has pointed out, boingboing.net has a particularly OTT post which seems to say that he is accusing t-mobile of something he clearly isn’t.

Finally, two days ago, dpg posted this:

“I’m pleased to report that T-Mobile is no longer blocking TLS-secured email on port 587. As a follow-up to an email exchange over the Christmas period I was contacted today to say that, contrary to what I had been told previously, it was never a deliberate policy to block TLS-secured outgoing email. There was a problem with some equipment after all, which was resolved yesterday.”

I tried again myself today. Initially, I got the same old symptoms (“lost connection after STARTTLS”) then I rebooted my ‘phone and lo and behold I could send email.

Like Mike, I tend to the cockup over conspiracy theory, it’s more likely for one thing. IANAL, but it seems to me that it would be in breach of RIPA part I, Unlawful Interception, for the telco to intercept my SMTP traffic in the way it seems to have been doing. That is not likely to be a deliberate act by a major UK mobile network provider.

But I’ll still keep an eye on things.

bah, humbug

Saturday, December 24th, 2011

At this time of year it is traditional to receive christmas cards from people with whom you may have only infrequent, if any, contact on a normal daily basis. If you are in a relationship, these cards will often be addressed to you as a couple or family, and be signed on behalf of other couples or families. In my case, on opening such cards I often then end up shouting out something like, “Darling, who the hell are Sarah and Jimmy?” and “Did we send them a card?” (as if it mattered.)

In my view, this problem has become exacerbated by the rise of the e-card (an email substitute for those too idle, or too penny pinching, to even go to the trouble of sending actual cards through the real postal system). Maybe I’m becoming more reactionary in my old age (it happens) but e-cards are, in my view, even worse than e-books.

Strange as it may sound, most people I know use their christmas cards as decorative features by hanging them on string around doorways, or placing them on the mantle over the fireplace alongside the christmas tree. What am I supposed to do with a bloody flash animation of a kitten playing with a bauble?

Worse, these e-cards do not usually even come direct from the sender’s (known) email address but via the commercial creator’s website. This means that the email runs the risk of being treated as spam and thus not reaching the intended destination. Or, again, in my case, if they do actually reach their destination and I see an email from some unknown sender with the message “Sarah and Jimmy have sent you the attached e-card in support of save the vegetarian whales. Click here to see it”, it goes straight into the deleted pile unopened.

Hah! Take that! You aren’t going to socially engineer me into installing your damned trojan.

Merry Christmas.

that looks like a scam to me

Monday, October 10th, 2011

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”.

who are you going to call

Monday, July 18th, 2011

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.

irony is not dead

Tuesday, March 29th, 2011

Installing counterize to analyse trivia’s logs has been instructive. I now know that some of my most visited pages are consistently those of a “how-to” nature (in particular, those about postfix, dovecot and, strangely, reflashing the old BT home hub). In many ways this is satisfying since one of the objectives of this blog is to document solutions to problems I have encountered personally.

But counterize provides much more than this. For example, I now know that of my visitors, 46.09% use firefox, followed by 27.24% using IE, with safari trailing in third place on 8.75%. Further, the top browser by version is IE 6.0 (now there’s a surprise…) at 13.14% and the most used OS is windows XP at 42.65% (sad, but you can’t argue with the stats).

However, what really intrigues me is the referer analysis. Some are fairly obvious given the content viewed. For example one of the top referers is a page on the-scream.co.uk which points to my articles on the home hub. Others are less so. One that caught my eye today is a referer from a website which sells a tool to spy on mobile phones. That site has a privacy policy (!) which says the following:

Privacy Policy

This privacy policy applies to the use of http://www.spybubble.com

We highly value your privacy and make this policy easily available throughout our site to assist you in understanding the handling of information in the course of using this site.

As Terry Wogan would say, “is it me?”

from russia with love

Sunday, March 27th, 2011

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.

damn, I think I got hit by a 419er

Sunday, January 23rd, 2011

I am normally pretty careful about my on-line security and privacy. I take a lot of care to ensure that my home network is nailed down tightly and all the clients and servers on it are also nailed down as well as I know how. I don’t use software which is susceptible to the majority of the malware out there; my browser is nailed down as tightly as I can get it whilst still allowing it to be useful (roll on HTML5, I hate flash, but it is so damned useful); I do some, very specific, browsing (such as on-line banking) from within a VM and do not use that browser or machine for anything except that specific activity; I routinely bin cookies and flash LSOs (in fact I find it better to disallow all LSOs in the first place); this blog does not include any email addresses harvestable by ‘bots; my email client is a niche (i.e. minority) product and is configured only to allow text (no HTML or embedded images or webbugs); I use tor when I want to be as anonymous as possible; my local DNS server blocks access to a whole range of addresses I don’t like; and I never respond to unsolicited email.

But I got phished. Damn.

Here’s what happened.

I advertised an unwanted mobile phone on gumtree. I chose gumtree in preference to ebay because a) adverts are free, and b) gumtree allows you to target the advertising to a specific location. I like this idea because it means you can say “I’ve got a doohickey for sale in South London. Come and see it and pay cash if you want it”. My ad gave details of the item for sale and, as is recommended, I chose to have responses emailed to me. Here I made mistake number one – I used my normal email address rather than a disposable one. To be fair, gumtree don’t expose any of your private details, they just forward any responses to the address you give. Here’s where I made mistake number two, I responded to queries about the ad from the address given to gumtree. Damn. Idiot. So stupid.

So why do I think the responses weren’t kosher? Well there were a number of giveaways. Firstly the requests were for information already in the ad (“how much do you want?”); secondly, there were a suspiciously high number of “spilling misteaks” in the emails; thirdly, the correspondent wanted me to mail the ‘phone to a location outside the UK (“Thanks for your quick respond actually i will love to buy the Ad for my Daughter who is currently studying at British international college (BIC) in West Africa so am willing to pay you additional £48.76 for the shipping via Express Air Mail.” (sic)); fourthly, the respondents all seemed desperately keen for me to accept paypal as the preferred payment option. I’m normally quicker on the uptake than this, but sadly it took me four or five emails to realise that there was a pattern here and that the people after the phone seemed to be following a script and were completely ignoring my responses. Here’s a sample:

Someone calling him or her self “Janet Mason”:

“Hello Seller,
Can I know the condition of the item? I think you will accept PayPal. And I will pay the postage and packing cost for the item. If you can send me paypal payment request now and I will make the payment straight away without any delay. Hope to hear from you very soon.”

My response:

“Janet

As the ad say, the phone is in “as new condition”. This means what it says. The phone is completely clean and has no visible markings or scratches.”

“Janet’s” reply:

“Ok send me your paypal Payment request now so that I can make the payment now.”

My response:

“I’d like a bit more detail first please.

Where are you? (Full address and telephone mumber so that I can confirm that I am sending to “Janet Mason”.

Details of your confirmed paypal account (so that I know that Paypal have verifed you).

If you want to know why I am concerned please read the paypal guidance for sellers – particularly the bit about sending only to UK or US based addresses and getting signatures on receipt of goods.

I have received several requests to send the phone to “my daughter/son/nephew” or whatever in various Countries outside the EU. I am naturally suspicious.”

“Janet” then says:

“Hello, 
Am in London right now but due to the nature of my work here in London I will not be able to post the item to my Business Partner Daughter in Nigeria as a New Year Gift. But I will pay for the postage and packing cost via FedEX. Get back to me with your paypal payment request now so that I can make the payment now and get the item posted out tomorrow Morning.”

Correspondence ends…..

Now whilst I have not lost the ‘phone, I have verified a usable email address to a bunch of scammers. I expect my spam volume to that address to increase dramatically. Never mind though, I’m not alone in losing out to the bad guys, and at least I haven’t lost any passwords in the process.

Still, I’m pretty pissed off.

very, very, slow electrons

Tuesday, September 14th, 2010

I recently received an email from my old chum Chris Samuel. Chris emigrated to Australia several years ago, but we still correspond, if infrequently. In fact he sometimes comments here. But he is not good at email.

This is what I received:

On Thu, 19 Dec 2002 03:50:08 am you wrote:

> Have a very Merry Christmas and an exceptionally good New Year.

You too! ;-)

Yes, trying to catch up on some email, and yes I’m crap at it. ;-)

cheers,
Chris

Way to go Chris – nearly eight years late, but you made it. :-)

email address images

Monday, May 3rd, 2010

Adding valid email addresses to web sites is almost always a bad idea these days. Automated ‘bots routinely scan web servers and harvest email addresses for sale to spammers and scammers. And in some cases, email addresses harvested from commercial web sites can be used in targetted social engineering attacks. So, posting your email address to a website in a way which is useful to human being, but not to a ‘bot has to be a “good thing” (TM). One way of doing so is to use an image of an address rather than text itself. Of course this has the disadvantage that the address will not be immediately usable by client email software (unless, of course you defeat the object of the exercise by adding an html “mailto” tag to the image) but it should be no big deal for someone who wants to contact you to write the address down.

There are a number of web sites which offer a (free) service which allows you to plug in an email address and then download an image generated from that address. However, I can’t get over the suspicion that this would be an ideal way to actually harvest valid email addresses, moreover addresses which you could be pretty certain the users did not want exposed to spammers. Call me paranoid, but I prefer to control my own privacy.

There are also a number of web sites (and blog entries) describing how to use netpbm tools to create an image from text – one of the better ones (despite its idiosyncratic look) is at robsworld. But in fact it is pretty easy to do this in gimp. Take a look at the address below:

This was created as follows:

open gimp and create a new file with a 640×480 template (actually any template will do);
select the text tool and choose a suitable font size, colour etc;
enter the text of the address in the new file;
select image -> autocrop image;
select layer -> Transparency -> Colour to Alpha;
select from white (the background colour) to alpha;
select save-as and use the file extension .png – you will be prompted to export as png.

Now add the image to your web site.