Phishing attacks getting better .. iTunes Receipts

So I get a call this morning from a family member who is freaking out over a six hundred dollar iTunes invoice. Fortunately I knew this person didn't have an iTunes account (they use mine), so I knew right away it was a fraud. On inspecting the invoice, there were so few errors it's chilling. If this had of been an invoice from the (Acme Widget Company) that I do have an account with .. it's possible it may have worked. 

This is particularly evil, since it's associated with the Zeus trojan that steals banking credentials

The quality of phishing emails have dramatically improved as the quality assurance by malware miscreants improves. 

iTunes phish

On closer inspection, there were three very subtle errors made on this iTunes phishing attack:

  1. No street address was shown.  iTunes receipts always have your street address listed and spamming dirt bags don't have that (we hope).
  2. Receipts (that I've paid attention to) come with an American style date format .. month / day / year.  Canadian or European formats are typically day / month / year or year / month / day.  This one is  day / month / year.
  3. Modern corporate invoicing systems don't include leading zeros. Also the quantity and dollar amounts don't add up.

Every web hyper-link in this invoice except for the Apple Store Support and the Apple Legal links point to a non-Apple site.  All the links in iTunes invoices point to Apple.  In this case, the infected domain was . This is particularly evil, since it's associated with the Zeus trojan that steals banking credentials. Bogus LinkedIn invites have also been confirmed to be coming from the Zeus botnet.

We still need to stay awake to the attacks by these malware miscreants, because they are getting better by the month.

IMAP mailstore migration .. again

So last weekend, I discovered that Spamhaus decided it would be a good idea to place all of the public IP addresses for Slicehost (my Linux VPS hoster) into their Spamhaus block list (SBL). This covered both my slice in Dallas and the one in St. Louis – meaning an impressive chunk of inbound mail to my domains was being trashed by the sending MTA and an even bigger chunk of my outbound mail was being outright rejected since the sending IP’s were on the SBL.  Slicehost worked hard to convince Spamhaus to recind the blocklist, so the Slicehost IP’s got moved over to the less-nasty-but-you’re-still-probably-a-spamming-dirtbag Policy Block list (PBL) assuming affected IP owners would request to be removed from that list.

Sample query to see if you’re on any Spamhaus block list:

It seems it’s time to relinquish the care and feeding of my own Postfix mail system and turn to a hosted solution.  This means I need to migrate about 5GB of IMAP store to another site (again).  Last time I did a wholesale migration, I used imapsync to make the transition painless. In the code example below, an SSL connection to the IMAPS server at is made with and the password stored in the plaintext file secret1. An SSL connection is made to the target system (which happens to be the server on which the imapsync tool is running, but could just as easily be another IMAPS server somewhere on a network accessible to the host where imapsync is running). The –delete and –expunge1 arguments will clean the successfully moved messages from IMAP store #1 .. so be sure you have your messages on the target successfully! Imapsync can be run iteratively to ensure you have got all the messages from your source.

/usr/bin/imapsync \
--host1 \
--ssl1 \
--authmech1 LOGIN \
--user1 --passfile1 secret1 \
--host2 --user2 --passfile2 secret2 \
--ssl2 \
--delete --expunge1 \

And one can use the


option to just test the process but not actually move any of the messages.

So that’s it – I’m about half way though migrating my current IMAP stores over to a hosted mail solution, so that I don’t need to keep up with the increasing level of care and feeding that running your own mail service requires.  Before I get too many darts about that .. I first started running my own personal MTA in 1995, adding spam and av filtering over time, and adding substantial redundancy (servers, sites, storage) so I could rely on it and fix things that broke as I had time rather than right when they broke (which was always at a bad time).  My new hosted solution takes over from two VPS servers running Postfix, Spamassassin, ClamAV, Greylisting with the IMAP store replicated across data centers in different states (15 minute rsyncs).  So soon, the (hopefully) last Allen Pomeroy owned and operated MTA can be turned off, while I get to work on fun stuff, rather than figuring out why my email is bouncing.  🙂

Update 2012/12/17:

Sometimes manual manipulation of your mailstore via IMAP is needed, so here’s how I deleted a large number of folders I had trashed and were being synced to my new system from the old.  Kinda clunky, since I didn’t get the scripted version to work (just used a copy/paste in an interactive bash session), but got the job done for now.

Connect to the IMAP server using SSL:
openssl s_client -crlf -connect


Log in with your email credentials:
0 login Password


List the folders you want to remove:
0 list "" "Trash.*"

That didn’t return the list I was expecting, so I listed all folders
0 list "" "*"

… and realized the source mail system adds “INBOX” on the front of the folder names, so then this command worked to list the folders to be deleted:
0 list "" "INBOX.Trash.*"

I copied the output and edited it to insert the folder name into a delete command:
0 delete "INBOX.Trash.Folder1"
0 delete "INBOX.Trash.Folder2"
0 delete "INBOX.Trash.Folder3"

0 OK Delete completed.
0 OK Delete completed.
0 OK Delete completed.

Finish off the session by logging out:
0 logout

* BYE Logging out
0 OK Logout completed.

Setup IMAPS on iPhone 3G with self-signed certificates

So setting up my shiny new iPhone 3G for IMAPS email was not entirely straight forward.  (-:  There are two complicating factors that I ran into.  For IMAP over SSL (IMAPS) connections to a mail server that is using a digital certificate that is signed by a well known certificate authority AND running on the default TCP port 993, no problems.  You may have a be a bit patient as the mail app on the iPhone accepts the certificate.  For less standard mail server implementations, read on …

I am using a server certificate that is in essence a self-signed certificate – it is signed by, however very few (if any) browsers and mobile devices trust or even know of  In this case, you will need to be patient while the iPhone mail app finally rejects the server certificate as untrusted.  The dialogue box will acknowledge the mail server certificate is invalid and will ask if you want to continue.  Accept the continue option and eventually (took about 5 minutes for my iPhone) the iPhone will accept the ‘invalid’ certificate.

Now, if you are using a mail server that has IMAPS running on a non-standard port (anything other than TCP 993), you must first establish the connection and have the iPhone accept the certificate over port 993.  Once the mail account is setup initially, then you can go change the port to something non-standard.

Once I get a chance I’ll post some screen shots.