Update: Here’s what transpired during the following week.
In a nutshell, all the e-mail I sent this weekend through .Mac has vanished and never reached its intended destination.
I first noticed something was amiss yesterday when e-mailing portions of my last post from my iPod Touch. They failed to arrive to my inbox immediately, but I assumed it was just a blip and picked them up from .Mac’s
Sent Items folder anyway.
Today, I checked again. They’re still not there.
In the meantime, I also started noticing that I wasn’t getting any replies to a slew of e-mails I had sent earlier.
Some of those were sent as far back as Wednesday and the recipients are folk on the move, so I’m not really expecting prompt replies… But there was one e-mail on Thursday that I found odd not to have a reply to by now.
Anyway, I’ve been doing a number of tests, and they’re all failing:
- Sending e-mail from .Mac to my Gmail account
- Sending e-mail from .Mac to my local ISP account
- Sending e-mail from .Mac to itself
- Sending e-mail to a small mailing-list
I did this three times (for a total of twelve tests) by:
- Using .Mac’s standard SMTP port (25) with SSL (their default configuration)
- Using .Mac’s alternate SMTP port (587) with SSL (which is what I use)
- Using the .Mac webmail UI
After all, if they can’t manage to keep their e-mail running reliably, I’m certainly not going to place any trust on any of their other services.
In the meantime, make sure to check your own .Mac e-mail – twice.
Update: The Plot Thickens
I was going nuts with this, and after triple-checking my settings on both my iPod Touch and my MacBook to make sure that I was indeed using authentication and SSL over port 587 (and yes, I used Connection Doctor as well), I decided to test it again via my Vodafone HSUPA connection.
Guess what? The e-mail went through. Same output on Connection Doctor. Same everything (port 25, port 587, and webmail). Different ISP.
The thing is (and I know most people won’t get this), the tests I did should have worked regardless of ISP.
Because, after all, I was using authenticated and encrypted SMTP to talk to the .Mac servers. They know who I am. I paid for the service. I authenticate every time I want to send a message, for chrissakes!
The only reason for this not working right now (as far as I can figure out) is that some idiot configured the .Mac anti-spam software to nuke anything being sent by Netcabo customers, regardless of means of access.
And why nuke messages sent from .Mac webmail as well?
Hitting The Metal
Macintosh:1015 rcarmo$ telnet smtp.mac.com 25 Trying 126.96.36.199... Connected to smtp.mac.com. Escape character is '^]'. 220 smtp.mac.com ESMTP Service HELO idiots 250 mac.com Hello a213-22-XXX-XXX.cpe.netcabo.pt [213.22.XXX.XXX, pleased to meet you MAIL FROM: [email protected] 250 2.1.0 [email protected].. Sender ok RCPT TO: [email protected] 250 2.1.5 [email protected].. Recipient ok DATA 354 Enter mail, end with "." on a line by itself test . 250 2.0.0 m29DFhpM016633 Message accepted for deliveryQUIT 221 2.0.0 mac.com closing connection
And then I repeated that again, via my HSUPA connection:
Macintosh:1015 rcarmo$ telnet smtp.mac.com 25 Trying 188.8.131.52... Connected to smtp.mac.com. Escape character is '^]'. 220 smtp.mac.com ESMTP Service HELO idiots.again 250 mac.com Hello XXX.XXX.54.77.rev.vodafone.pt [77.54.XXX.XXX], pleased to meet you MAIL FROM: [email protected] 250 2.1.0 [email protected].. Sender ok RCPT TO: [email protected] 250 2.1.5 [email protected].. Recipient ok DATA 354 Enter mail, end with "." on a line by itself test . 250 2.0.0 m29DNEYV027775 Message accepted for deliveryQUIT 221 2.0.0 mac.com closing connection
The White Glove Test
After receiving the first follow-up contact from .Mac support, I did another batch of testing, with precisely the same results.
But it worked using my mobile connection, and I wanted to figure out why. When I started looking at the headers for a test message sent that way, I noticed a few things:
Return-path: <[email protected]> Received: from mac.com ([10.150.68.73]) by ms201.mac.com (Sun Java(tm) System Messaging Server 6.3-6.01 (built Dec 5 2007; 64bit)) with ESMTP id <[email protected]> for [email protected]; Sun, 09 Mar 2008 13:07:21 -0700 (PDT) Original-recipient: rfc822;[email protected] Received: from smtpoutw.mac.com (smtpoutw004-vlan1 [184.108.40.206]) by mac.com (Xserve/smtpin073/MantshX 4.0) with ESMTP id m29K7KjD023583 for <[email protected]>; Sun, 09 Mar 2008 13:07:20 -0700 (PDT) Received: from webmail034 (webmail034-s [10.13.128.34]) by smtpoutw.mac.com (Xserve/smtpoutw004/MantshX 4.0) with ESMTP id m29KAkoS019993 for <[email protected]>; Sun, 09 Mar 2008 13:10:47 -0700 (PDT) Date: Sun, 09 Mar 2008 13:07:18 -0700 From: Rui Carmo <[email protected]> To: [email protected] Message-id: <[email protected]> Subject: test12 via webmail (and mobile) MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7bit X-Originating-IP: 77.54.XXX.XXX Received: from [77.54.XXX.XXX] from webmail.mac.com with HTTP; Sun, 09 Mar 2008 13:07:18 -0700 X-Brightmail-Tracker: AAAAAgAAAUAAAAFQ X-Brightmail: Scanned
Notice that the .Mac SMTP server
smtpoutw.mac.com is passed my IP address on the mobile network via the
X-Originating-IP header – a neat trick that would enable it to filter based on source address regardless of whether I am sending e-mail via web or Mail.app.
But they are doing so in such a way that they are actually denying their own customers service – even when sending via authenticated and secure links or their own webmail.
Which means (in my eyes) that they don’t know how to manage an e-mail service – especially not such an exorbitantly priced one.