.Mac Doesn't Trust You

Update: Here’s what transpired during the following week.

I am absolutely livid at Apple right now. For some reason, .Mac’s SMTP server has turned into a black hole.

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

Sending messages from Gmail or Google Apps (which is where this domain’s e-mail is hosted) works great – instant delivery anywhere.

But .Mac is absolutely dead in the water – none of my e-mails have gone through. And I’m not the only one complaining.

I’ve since filled out their support form, and will re-think my earlier decision of moving my photo gallery to .Mac.

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.

For most people, that would be the end of it and they would blame their ISP (oh, and by the way, I’ve been using Netcabo).

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.

But it doesn’t make any sense. After all, what is the point of having authenticated SMTP over SSL access if you do that?

And why nuke messages sent from .Mac webmail as well?

For completeness’ sake, I decided to do some old-school testing for documenting this further. I fired up a Terminal window, connected via Netcabo and did the following:

Macintosh:1015 rcarmo$ telnet smtp.mac.com 25

Trying 17.148.16.33…

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 delivery

QUIT

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 17.148.16.33…

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 delivery

QUIT

221 2.0.0 mac.com closing connection

The Netcabo test didn’t make it. The Vodafone test was delivered instantly.

After receiving the first follow-up contact from .Mac support, I did another batch of testing, with precisely the same results.

And by this time I was going nuts – I could understand everything that was happening via SMTP, but not being able to send e-mail via .Mac webmail to myself was extremely odd.

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 [17.250.248.179])
	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.

And, as it happens, I had logged in to .Mac webmail only seconds previously and sent a “test11” message from IP address 213.22.XXX.XXX (my Netcabo IP address) – which didn’t arrive.

So yes, .Mac is nuking e-mail from some ISPs.

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.