I figured this out for the iPhone, but the same basic idea works just fine on a regular mail client as well. This is, admittedly, pretty convoluted, but I've been using it for a while, and it seems to work pretty well:

a) Sign up for a gmail account for each iPhone user who uses email. Go to http://www.gmail.com, hit "Sign up for Gmail", fill out all the assorted answers.
b) On each iPhone, set up smtp.gmail.com as the Outgoing mailserver address. You'll also have to plug in "myusername@gmail.com" (where "myusername" is, well, your gmail user name), and your password in the User Name and Password fields.
c) Click the "Advanced" button in the Mail preferences on each iPhone, scroll down to "Outgoing Settings", and toggle "Use SSL" to On, and make sure that "Authentication" is set to "Password".
d) Go to your Gmail account on gmail.com, click Settings, then Accounts, then add your existing Cox email account to the "Send as" option. It will send a confirmation email to your regular, Cox email account. Click the link in the email you receive to confirm the request. Then log out of gmail, log back in again, go back to Settings, Accounts, and set the Cox.com email account as the default.

That's it. Like I said, convoluted, but now emails on the iPhone will be sent through the gmail smtp server, yet look like they're coming from your Cox account. Better yet, this seems to work whether you're connected to Cox via the Airport network, or connected via Edge when you're on the road.

...but some things now work that didn't before. I've added some slightly more helpful contact information, as well as a spectacularly brief bio page. Please feel free to peruse these incremental improvements and ponder them as you wind your way around the scenic byways of the internet. Thankyou.

Hey, I'm fooling around with the site. Hopefully I won't break it too badly...

I'm usually hesitant to write about specific problems that I encounter (and hopefully fix) for clients, but this one has been eating away at me, and now that I've solved the puzzle, I feel like committing the process to the printed page. Well, not exactly printed, as these are the internets, but you get the idea.

I have a client with three retail stores in three cities, who wanted to talk to each other via video iChat. All are using the same ISP, the same iMac, and the same OS. Two of the stores can see each other just fine, one cannot.

All three are using AIM accounts in iChat, so my first thought was that it might be a specific problem with the hardware at the one store. I've seen a lot of occasions where a flaky router or modem can mess up high-bandwidth services like chat, and this was kind of borne out when looking at the cable modem in the store, which was a sort of huge, valve-laden, 1950's Soviet looking job. Also, it seemed prone to randomly losing its connection and resetting itself. Pretty good idea to change that out, I thought, so after making a pretty thorough backup of all the relevant settings, I had Cox come in and replace it with something new and shiny, and all was well.

For about a week.

Then we had a brownout, and the problem came back. The modem tested good, so the next logical step was to look at the router. I like to use a MacBook Pro as a test machine for this kind of thing; I have it locked down nice and clean with no bizarre and funky hacks, so that I have something known-good I can plug in and test with. Lo and behold, even with the router out of the equation, video Chat didn't work. Curiously, it made a connection, then immediately died. "Sounds like packet-shaping," thought I. "I'll call Cox."

The folks at Cox were - and I hate to say this about any IT phone support because it sets unrealistic expectations - polite, well-informed, and helpful. I had them check out the line, and all seemed well. After a modem reset, I was suddenly able to do video chat to other machines running .Mac accounts, but not to AIM accounts. Aha!

Na-ha.

My idea that the problem was .Mac specific foundered on the point that the other two stores - using AIM, were able to video chat without any trouble at all. Bother. I started using some tools to look into what was happening when making these connections, then I stumbled onto something very interesting; IP traffic outbound just... disappeared. Not all the time, mind, but about half the time pings just timed out, and traceroute just kind of sat there accusingly, conspicuously not tracing anything at all. Back on the phone, the friendly folks at Cox affected disbelief, then grudging acceptance after I sent them logs, and vowed to "look into it."

"Looking into" turned out to be sending a tech around to poke the modem with a stick, check that the connection was live, then shrug his shoulders and leave. Tres helpful. After a couple of weeks of wheedling, wrangling, and fighting, I got Cox to reset the routing table for that gateway, and went back to step one. This time, using AIM accounts foundered, but .Mac worked great guns. Gotta love that Session Initialization Protocol, and its ability to play nice with NAT and UPnP.

The thing is, that this is one of those problems where you need to deal with one obfuscation before targeting another; while I was bang on track initially with the AIM/.Mac problem, it was all going to be pretty moot unless Cox rearranged their plumbing to illuminate the problem and thus accommodate the fix. Usually, problems are pretty clear cut, but this was a case of not being able to diagnose Cholera until I'd got the Leprosy under control. Next time I'm holding out for a simple case of Scrofula. Or a disconnected patch cable.