While this series of articles is Mac-specific and Mail-specific, most of the tips offered can be used with other e-mail clients on other platforms. It is all about productivity. I know people who have no such scheme and are burdened by the guilt (or just stress) of hundreds (or more) unread or "undealtwith" e-mails in their inbox.

As the waiter in the 1971 television advertisement for Alka-Seltzer urges his customer, "Try it, you'll like it." Unlike the customer, trying these suggestions should lessen the need for an antacid.

See

• Turn down the volume on your e-mail
• The fast way to file your e-mail
• Clean out old e-mail messages

Short version: using e-mail 'stetionery' is evil. Don't do it.

In my posting Leopard: The Good Stuff I say

One feature Mail could have done without: stationery. Stationery is terrificfor hand-written mail. All it does is add an image attachment that may or may not be seen as a "background" to the e-mail. (Many times it will not show upit depends on the e-mail client. The user will then click on the attachment to see it and it will make them wonder why you send them a fabric swatch.)

I have repeatedly suggested against it every time someone has mentioned it in the Apple discussion forums. I've written, "As I've stated before on these forums, just because it looks good in your e-mail client does not mean that it will display correctly in someone else's. Sometimes the 'stationery' will be transmitted as an attachment. The recipient will get your e-mail and an attachment. They will have to click on the attachment to see it. And they will see the 'stationery' only. It would be like sending a postal letter with the words written on a plain white sheet of paper, and sending along with it a nice piece of colored stationery."

A friend sent me e-mail the other day. He "signed his name" at the bottom with a GIF image of his handwritten name, "Joe." It, was, of course, an attachment. It showed up fine in e-mail, but when I forwarded the message, I forwarded his plain text e-mail plus the attachment with his name.

Someone else consistently sends me e-mail with a fancy signature image, containing her company logo. Every time I reply—and include the e-mail—the fancy signature is sent along. She replies, and now there are two copies if it, and so on.

You, the sender, have no control over what the recipients' e-mail client can and cannot view. Sticking to plain text e-mail means that you can communicate with the greatest number of people. If you must have fancy fonts, and colorful backgrounds, send it in a PDF.

Plain text is best.

Use Rich Text if you must.

But, don't use stationery (unless it is in hard-copy, postal mail).

I just need to figure out how to code this up:

IF

• The From: address is all in capital letters
• The word "widow" is in the message body
  and either
  • The Subject is "greetings in the name of the lord!"
    or
  • The Subject: is in Hebrew (this won't work for everyone, I know)

Apparently, in it's never-ending battle to thwart spam, Comcast (apparently) recently started to require that connecting e-mail servers have a valid PTR record so Comcast's email servers can do a PTR (pointer) record lookup. This allows a look-up on your IP address to see if the IP address and the value returned—it should be the computer's domain namematch.

Now, I am not sure of a different way to do it, but Comcast chose a way that many choose. They returned it in a bounced error message.

Providentially, I knew this was coming. For some reason, I checked the mail queue on the server. This is what I saw.

242C7AFEC0D2 9406 Thu Jun 19 12:25:40
listname@example.org (connect to mx1.comcast.net[76.96.62.116]: server refused to talk to me:
554 IMTA08.westchester.pa.mail.comcast.net comcast 66.242.23.142 Comcast requires that all mail servers must have a PTR record with a valid Reverse DNS entry. Currently your mail server does not fill that requirement. For more information, refer to:
http://www.comcast.net/help/faq/index.jsp?faq=SecurityMail_Policy18784)
alpha@comcast.net
charlie3@comcast.net
delta4@comcast.net
echo5@comcast.net
foxtrot6@comcast.net
gold7@comcast.net
hotel8@comcast.net

Later, one of the errors was returned to the list owner (me).

<delta4@comcast.net>: delivery temporarily suspended: connect to mx2.comcast.net[76.96.30.116]: server refused to talk to me: 554 IMTA01.emeryville.ca.mail.comcast.net comcast 66.242.23.142 Comcast requires that all mail servers must have a PTR record with a valid Reverse DNS entry. Currently your mail server does not fill that requirement. For more information, refer to: http://www.comcast.net/help/faq/index.jsp?faq=SecurityMail_Policy18784

Now, I am fairly Internet, DNS, and SMTP e-mail clueful. What would (what do) the average person do with this error message? They should go to the indicated URL. It suggests going to your email administrator. Many people stop right there, eyes glazed over.

The funny thing in this case? Although the server was not in a Comcast address space, the server domain is a customer of Comcast. I'm thinking the error message could have been clearer.

The headline said Lilly's $1 Billion E-Mailstrom. Katherine Eban opened with, "A secret memo meant for a colleague lands in a Times reporter's in-box."

The short version is that typing in a recipient's last name first expanded in the sender's email client (it could have been any email client) to a Times reporter with the same last name instead of the sender's co-counsel. That should never happen. But, it happens all the time. It usually has benign results.

Why, just the other day I sent a short email message to a friend, I'll call him Andy Jones. I typed in his email address from memory: ajones@example.com. Except that wasn't his address. I did not get a reply, I knew he usually replied quickly, and I saw by his IM screen name that he was on and active. So, I looked up his email address to be sure. I had left out a letter. He used his middle name: abjones@example.com. Bummer. But, no harm done. It was short, nothing-secret-about-it kind of note. But, this story and my example, reminded me of something from a past company.

Up in the UNIX support group at Digital Equipment Corporation (DEC), in the olden days, everyone there used the same VAX computer, decvax. It was a major UUCP gateway (look it up—it's part of your history!). On this central computer, there was a mail aliases file. Usually, such a file is used for mailing list support. For example, ultrix-engineers might expand to the email addresses of the entire group of software engineers. That's a good use for distribution lists. One day a product manager sent a note out to internal folks about what she was working on, DECWindows. She sent it to what she thought was internal folks... not even a distribution list. She sent email to—and I am making up these names now: joe, mary, ken, tom, and jane.

The next day, she got a note from Ken Thompson at Bell Labs saying, basically, I don't think this was meant for me. See the developer she wanted to send to, Ken Smith, used his initials for his mailbox, kts. The mailbox "ken" ... well you see where it went to. It could have been worse. In that same file there was a mailbox "bill" which went to Bill Shannon and "joy" that did not go to Joy Dormat, but rather to Bill Joy. Shannon, formerly an employee of DEC UEG and Joy, formerly at UC Berkeley—which expains the "why?" of their emails being in the DEC aliases file—both had moved to Sun Microsystems, a major DEC competitor.

Now, that wasn't the same problem as what happened to Lilly. Back then, email clients did not auto-complete addresses. It is a worse problem today. One types and the email client fills in a name, we hit and go on to typing the next name, and so on. It is a problem with some technical solutions, but solutions that we mostly ignore because "it just won't happen to us, and even if it did, what could happen?" There are solutions out there. I bet that Ely Lilly's outside law firm gets an email firewall.

(In the past, I've written about, lectured about, and reviewed products, and recommended policies, that mitigate risks like this. It really is old stuff, that has already been managed. We just don't bother. See my Secure E-mail Collection.)