John Cleary has noticed a fairly rare but annoying bug in the way that Mail.app handles From: email addresses.

As he points out:

In Mail.app (the standard mail client on OS X), if the person sending an email to you hasn’t specified a ‘from name’ in their email client (or webmail), the email will show up as being from their raw email address even if their name and email address is in your Address Book. Additionally, if the person has specified a ‘from name’ different from their real name (i.e. a nickname or screen name) then that will show up in the from column.

So you get odd things like this:

Obviously this is visually annoying and sometimes less than informative.

It also throws a spanner in the works when sorting emails by name.

John suggests that the solution is easy:

The Mail User Interface needs the ability to choose either to use Address Book names when there is no supplied ‘from name’ or to always use Address Book names regardless of supplied from name, matching instead on the email address.

It makes you wonder why is hasn’t been fixed.

Related posts

• Using Mail.app as a document archive
• The puzzle of extra returns in Mail.app replies
• Ten ways to make Mail.app better
• Security flaw with scripts in Mail.app
• Script to archive mail.app messages by month

Although my own experience of the 10.4.7 update and Mail.app has been completely trouble-free, not everyone has been so lucky. MacUser carries a good summary of some general problems.

MacInTouch has a collection of readers’ reports about problems following the recent update. Almost all of them mention Mail. The posters either have problems or are just disillusioned like this one:

It’s been how many years now, that Mail has been out? How many updates to the OS, and still, *still* Apple has not fixed the problem that Mail has wrt long URIs: It breaks them in such a way that only Mail seems to be able to handle. Users of other Mail software are unable to click on the resulting links.

With the 10.4.7 update, they’ve certainly addressed some bugs in Mail, but this is STILL not one of them. I think the argument can be made that it’s more serious than some of the ones they have fixed.

I’ve reported this bug several times to Apple, as have my colleagues, but maybe we need a more public rant.

I don’t think that Apple will “fix” this problem. The “delsp=yes” flag that triggers this behaviour (read more about it in an earlier Hawk Wings post) is well-documented in the RFC standard.

Apple (I imagine) doesn’t think this is a bug in Mail.app. It’s the rest of the world that lags behind, and we Mail users must wait for other email clients to catch up.

We just have to take the taunts of our non-Mail-using buddies on the nose, or use one workaround or another in the meantime.

Related posts

• Work-around for Outlook attachment problems
• The puzzle of extra returns in Mail.app replies
• Ten ways to make Mail.app better
• Security flaw with scripts in Mail.app
• Savaging Mail’s sending silliness

On the Apple Discussion Boards, Steve Jones notes that Mail.app has the annoying habit of adding an extra return to paragraphs quoted in a reply.

It doesn’t happen all the time, and it seems to happen whether the reply is in plain text or rich text format.

I’ve noticed this myself and have shared the concern of another poster in the same thread:

I hope my original messages aren’t being displayed to the recipient like this, ’cause it’d really make me look like an idiot!

This is possibly not the most pressing issue facing a user of Mail.app, but it does nag away in the back of my mind.

Why is it so? Can anything be done to fix it?

Related posts

• Why Mail.app quotes the way it does
• TextSoap 4.5.2
• TextExpander bargain today on MacZOT!
• Textexpander 1.4: Flexible delimiters, old logo
• Ten ways to make Mail.app better

Hawk Wings reader Leonardo Burci emailed today to tell me something about Address Book and Mail.app that I didn’t know.

He writes:

Create a Group in Address Book. Add people containing valid e-mail addresses plus a person without an e-mail address or with an invalid e-mail address.

Create a new email. Choose your Group as recipient. Send. You get an error saying something like “mail could not be sent using server xyz, etc”. It doesn’t tell you the real reason why the email couldn’t be sent. It should.

Problem: a Group in the Address Book might consist of people and companies with and without e-mail addresses. This group might be used for sending letters, faxes and e-mail. Mail.app should handle such a recipient list intelligently.

Solution: Mail.app should inform the user about missing and invalid e-mail addresses and should give the user a choice whether to send the mail to the recipients with correct e-mail addresses or not. If you do send, it should give the user a list of people and companies that have no or invalid e-mail addresses and that were therefore excluded.

He’s right. This is not the behaviour of an Operating System that “just works”.

Related posts

• Zimbra iSync beta released
• Work-around for current .Mac time-out annoyance
• What to do after deleting Mail.app by mistake
• Weekly Update
• Weekly Roundup

The writer at gnegg posts a long and pained description of his experience with Mail.app’s IMAP implementation.

Although he likes lots of things about Mail, he also notes some well-known IMAP frustrations, and then adds,

Even worse: Mail.app does not send an IMAP move command to move the messages to the trash (or just mark them as deleted). It actually manually copies the messages over! Message by Message. From the local copy to the server. Then it deletes them. And then begins the awful “Writing Changes to disk”, completely killing the performance of my MacBook.

His conclusion — “Mail.app is perfect for reading and writing your daily mail. It fails miserably at all mail administration jobs” — sees him using Mail for reading and writing, but keeping a copy of Thunderbird for all the mail admin tasks that he wants to perform.

Related posts

• Using Mail.app as a Yojimbo substitute
• Two great Mail.app tips
• Thunderbird, Growl and Getting Things Done
• Thunderbird IMAP bugs
• Threading in Thunderbird and Mail

In recent days two big hitters have aired their grievances about Mail.app.

Pierre Igot (read his “Talking Mail.app” interview) at Betalogue describes the odd way in which Mail handles format=flowed text.

If you place your cursor at the beginning of a line of quoted text and hit return, Mail actually inserts two returns. Pierre says:

I don’t care what the reason for this is. The reality is that it is purely and simply wrong. There is no excuse for inserting two return characters where the user only meant to insert one.

What’s more, he says,

there are still many “smaller” bugs such as this one that have not been fixed. And, frankly, there is no sign of them getting fixed any time soon. At this point, bug reports about such “minor” flaws simply remain unanswered.

Rui Carmo (read his “Talking Mail.app” interview) at Tao of Mac also unloads on Mail in a big way in a recent post.

Rui prefaces a long list of over twenty bugs in Mail.app with a plea:

Apple, this is not a MUA. It’s a shambles…. In fact, I’m willing to bet a lot of people will tend to agree… especially those who use Mail.app professionally, against big e-mail archives or to keep track of mailing-lists other than the local knitting club.

Related posts

• The puzzle of extra returns in Mail.app replies
• Ten ways to make Mail.app better
• Security flaw with scripts in Mail.app
• Savaging Mail’s sending silliness
• More post-10.4.7 Mail pains