Factotum: Documentation Handyman

All it took was a "fridge-sized" computer with tiny core memory allowing between 16 and 64 kilowords:

"The contents of the first email transmission have long since been forgotten; in a FAQ on his website, the sender, Ray Tomlinson (who sent the message between two computers located side-by-side) claims that the contents were 'entirely forgettable, and I have, therefore, forgotten them', and speculates that the message was most likely 'QWERTYUIOP' or something similar."

Read more on this first successful email transmission.

Reign over?

"Email has had a good run as king of communications. But its reign is over."

I hardly doubt it. I can see the move to a services approach, and an integration of those services. But much too early to claim outright demise.

Hacked Email

The Messaging Server community certainly knows how to deal with this:

• Settin Up a No Phishing Zone
• Protecting Against Spammers Who Compromise Messaging Server User Accounts
  

Plug pulled on Internet service provider, world sees 40-60 percent drop in email spam.

Ever at the forefront these days of innovative email services, Gmail does it again with its Mail Goggles. Now you can say goodbye to those regrettable emails that caused you nothing but grief, shame, and embarrassment.

And the survey is in: Spam in a landslide!

Mozilla Foundation to evolve Thunderbird.

This is just an observation, but along with implementing a zero inbox policy (which I've been using for a few weeks now myself), I tend to agree that a tough love email policy, limiting a message to at most a few sentences, just might provide a welcome boost to office productivity.

Inbox Zero. This guy's on to something big, er, small, er, zero. Been giving it a try since 7/25, and by George, it works. Watch the vid, feel the power.

There was an interesting conversation on the Info-iMS alias last week concerning "bounced email" that caught my eye. Ah, another learning opportunity! To recap, then, here is another installment of Comms 101, courtesy of our Comms experts.

The specific error sited was:

nsmail Illegal host/domain name found (Too many failures to this host during this run; skipping this host: No such host/domain)

The short reply as to what's going on is fairly intuitive: the remote domain in question failed to resolve to a legal result, meaning that almost certainly this is a DNS issue (and not a Messaging Server MTA issue). Note that "other mail" will continue to make it through to your system (expected behavior), so don't be mystified by that activity. In addition, the error message is communicating that the problem has happened multiple times during the current operation (run) of the channel. The message bouncing is thus occurring because of an underlying DNS problem. To troubleshoot this problem, you would need to enable debugging (such as on LOG_CONNECTION) to determine the specific issue. Very likely, such a problem is transitory in nature but it is clearly not an MTA issue. Of final note: fancy configuration workarounds to such a situation are typically more work than troubleshooting and fixing the real problem.

The full detail on this thread can be found here:

http://lists.balius.com/pipermail/info-ims-archive/2007-April/027757.html

I like it when I can say, here's some new information for you. As I mentioned yesterday, we were close to getting out a cool article (and it's actually the script that is cool) for generating an automatic email to your Calendar Server users, containing that day's appointments and tasks. Have at it:

Receiving a Daily Summary of Sun Java System Calendar Server Events and Tasks by Email

Thanks to Mike d. for contributing this info.

As I wrote about in this previous blog entry, I've been working in conjunction with one of our Calendar Server gurus to document how to provide your Calendar Server users with a daily summary of their Calendar Server events and tasks, emailed to their inbox or mobile device each weekday morning. I've got the article on our internal staging site, and it should be pushed out this week to BigAdmin.

While were at it, for more fun with Calendar Server, see this post by a new Sun employee (formerly with SeeBeyond) and his positive experiences with Thunderbird and the Lightning extension that is part of the Sunbird Mozilla project, to access his Calendar Server data from w/i Thunderbird.

So you want every sent email from every employee to carry a company disclaimer message. Whether because of increased awareness of confidentially, legality, or fashion, appending disclaimer messages to out-going mail is here with us.

But before asking how to do this with the Sun Java System Messaging Server MTA, step back and ask if you really need to do this. Start by reading the following:

http://www.goldmark.org/jeff/stupid-disclaimers
http://www.goldmark.org/jeff/stupid-disclaimers/apply.html

Here's perhaps the money quote:

"In the end, I think, although I am vastly ignorant of the law here, that adding disclaimers only makes you more vulnerable. This is because without disclaimers reasonable conventions and existing law apply. But once you add the disclaimer you had better get it exactly right and on exactly the right messages, and you sacrifice reasonable convention."

Okay, let's say that in spite of this advice, you want to proceed full steam ahead anyways and get every outgoing message from the MTA to bear this disclaimer stamp. Our experts advise the following:

1. First, be aware that there is no way to fully implement this at the server level. The only proper way to do disclaimers is to have a policy requiring users to insert them in their mail clients.
2. The next best approach is to write a conversion channel to add the disclaimer. The conversion channel can be used to perform arbitrary processing on each message on per body part basis. In this case, you want the processing to be that of appending a disclaimer. You end up modifying the MTA configuration files so that all your mail passes through this conversion channel. At a minimum you'd want to construct one conversion to account for text/plain message body and one to account for html. You'll need to add more if the actual messages being sent have some other sort of MIME structure unique to your deployment.

For more information, see the following:

http://docs.sun.com/app/docs/doc/819-2650/6n4u4dtr3?a=view

Some Troubleshooting Advice

If you configure the MTA as described above, and run into problems where the disclaimer is not appearing, you should begin by looking at your conversions file, and get a master_debug conversion channel debug log file. (The tcp_local_slave.log-* file, and the mappings file, are just about getting the message to the conversion channel. The appending of the disclaimer would be done by the conversion channel, so you need to see what the conversion channel itself is doing.)

Interesting predictions for 2007 on mobile email and backup/restore from Synchronica CEO Carsten Brinkschulte:

http://synchronica.cmail1.com/.aspx/e/136380/83252935/