Geek Foibles


Overcoming Mail.app’s lack of verbosity
April 21, 2009, 4:35 am
Filed under: Uncategorized

I’m generally a fan of Mail.app, the simple e-mail client that is a part of Mac OS X.  I find that simplicity in software is a virtue, as it usually results in small, reliable programs.  Mail.app is, for the most part, a good example of that.  It is easy to use, fast and is less prone to data corruption than alternatives like Entourage.

Sometimes its simplicity can be a liability, though.  This is especially true when trying to troubleshoot connection issues, as Mail.app will often not relay error messages from the server it’s communicating with.  For example, if you try sending an attachment that’s too big, the outgoing mail server that you try to send it through will tell Mail.app, “Hey, this is too big,” but Mail.app will only tell you that it couldn’t send the message.  It’s left up to you to try to figure out why.

In my case, a client was trying to forward an e-mail and its attachments that he’d received in Mail.app from his Gmail account.  I could watch the forward’s send progress in Mail.app’s activity window, but shortly after it got to 96%, Mail.app would simply report that it can’t send the message without any elaboration.

Mail.app SMTP error

Historically I would fire up tcpdump in Terminal in order to observe (“sniff”) the conversation between Mail.app and the server, thus seeing any error messages that pass between the two.  Servers are usually very explicit in their messages, so usually when you finally see the message you know right away what’s going wrong and how to fix it.  Trick is, tcpdump is only useful if you’re not using SSL or TLS to encrypt the connection to the server.  If you are, everything will be garbled and unintelligible.  Often I could simply turn off encryption temporarily and sniff the connection long enough to glean something useful, but services like Gmail will not work at all unless encryption is enabled.

After a bit of googling, I finally came across a post on Erik’s Lab that explained how to sniff any Mail.app communications, regardless of encryption.  Apparently there is a hook built into Mail.app that repeats a specified port’s traffic to the console.  So, if you launch Mail.app from Terminal using the following command (in our case sniffing port 25 to troubleshoot outgoing mail), you will see all the relevant data:

/Applications/Mail.app/Contents/MacOS/Mail -LogActivityOnPort 25

Leave Terminal open, since that’s where you’ll see the data appear.  I went ahead and sent the message again, and lo, after watching gobs of attachment data fly past, the following message appeared:

552-5.7.0 Our system detected an illegal attachment on your message. Please
552-5.7.0 visit http://mail.google.com/support/bin/answer.py?answer=6590 to
552 5.7.0 review our attachment guidelines.

I removed the attached ZIP file and then the e-mail sent without a problem.

Advertisements

2 Comments so far
Leave a comment

I got it to work by issuing this command:

/Applications/Mail.app/Contents/MacOS/Mail -LogSocketErrors YES -LogActivityOnHost your.mail.server -LogActivityOnPort “25,143,465,597,993”

I am also sniffing on every mail port I know, since I have 5 different accounts configured.

Comment by Martin

Similar voodoo findings (Snow Leopard) …

(1) Try “connection doctor” if only to see what ports it attempts to use. I found port 465 worked.

(2) If you get “554 Client Host Rejected: Access Denied” it is more likely to be an authentication glitch, not a blacklist as some imply.

Comment by MikeR




Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

w

Connecting to %s



%d bloggers like this: