Posted
by
Cliff
on Tuesday October 07, 2003 @10:40PM
from the your-mileage-may-vary dept.

Asprin asks: "One of the employees at work had a major headache because a very important email was undeliverable for more than 24 hours. Sure, he got an warning from our server about it, but only after an entire day had passed, and the email was no longer timely. Therefore, I shorted the message handling timeouts to send 'delivery delayed' warnings after 30 minutes and to cancel the message as undeliverable after four hours. Now, I don't expect any of the other mail administrators here to bless these timeouts because they're way too short. HOWEVER, the truth is that my users rely on email to be as reliable as telephone messages, and if it can't be delivered immediately, it is better to reject it outright and alert the user so that other communication channels can be exploited such as fax or Fed-Ex. Is anyone else doing this? Are there any non-obvious ramifications lurking? Pros? Cons? Comments? Should we all reduce these timeouts on our SMTP servers?"

I believe our mail server sends an alert 4 hours after an e-mail is non-deliverable, and retries at regular intervals for up to 4 days I believe. I think delivery is either every 1 hour, or every 4 hours. Not sure what the Sendmail defaults are.

That said, even if your e-mail server doesn't send you the outage, that doesn't mean the e-mail actually got there. It could have been received by a secondary MX, not the primary one that delivers it.

I'm sure everybody and their brother will mention that read receipts, and receive receipts are a good idea in this case (even those are reliable, but it's better then nothing). Oh, and that if the message was this important, at the very least a confirmation call. You might look like a character out of a Dilbert strip, but it sounds like confirmation would have been worth the embarrassment in this case.

That said, even if your e-mail server doesn't send you the outage, that doesn't mean the e-mail actually got there. It could have been received by a secondary MX, not the primary one that delivers it.

At two of the companies I've worked, there has been a stated policy that email was not "reliable" as a communications mechanism and that the IT department made no guarantees about the usefulness or capability of email or other IP-based data exchanges. As one of my managers put it, "There's no SLA for the Internet."

One of the problems with the Internet has been, rather ironically, its overwhelming success. When most of our emails get to their destinations within a matter of seconds or minutes, it begets an unrealistic expectation that it will always be that way, especially for those who do not understand the fractured and codependent nature of the Internet.

Your solution to the problem - letting the user know an email couldn't be delivered in a short period of time, while still trying to deliver for the full timeout period - is probably the best one in this situation.

When most of our emails get to their destinations within a matter of seconds or minutes, it begets an unrealistic expectation that it will always be that way, especially for those who do not understand the fractured and codependent nature of the Internet.

I would think that most of the women I've dated would understand this perfectly...

At two of the companies I've worked, there has been a stated policy that email was not "reliable" as a communications mechanism and that the IT department made no guarantees about the usefulness or capability of email or other IP-based data exchanges

I liken that to the sign you see at the dry cleaner that says "Not responsible for lost or damaged items"

Granted, the sign at the dry cleaner isn't true, and only meant as a deterent for lawsuits. However, wether the IT department puts up a sign that says

I find the best way to use email is to email the important information, then print out a copy and fax the copy, then call the recipient to find out if they received both the email and the fax.

Why an email AND a fax?

Surely it would be faster to send the email, then make the phone call, then send the fax only if the email failed. No further call is required because the fax protocol, unlike email, has confirmation built in.

Plus, both you and the recipient save paper and avoid the disposal hassle for se

While the protocol used for sending faxes has confirmation capabilities, the receipt only confirms a successful transmission and not that the fax has been printed correctly by the receiving fax machine...

I would only recommend setting up something to display a message after 30 minutes of trying, along with the 4 hour essage.

Once they get the 30min or 4 hour message, that should be sufficient for them to take action on their own. I would also suggest adding a message with a listing of possible reasons as to why the email is not going through. The last thing you want are users going to you about "why is it not going through, what did YOU screw up".

You can only do but so much. And email is not as reliable as other services. It's not regular mail, there's no certified letters.

How about carrier pigeon.... that doesn't sound good, too many points of failure:- needs to eat and could die of starvation (though they are air rats)- can be killed by too many things (and I thought a KILLALL command was bad)- could fly the other way.

Ok, how about smoke signals... wait, that won't work, too many points of failure:- windy days (you called but your message just seemed to drag, so I stopped looking)- looking in the wrong direction or not lo

I don't have the queuewarn set to something like 30 mins because I have a feeling my users would complain to me if they got warning messages every 30 mins.

Agreed, but I would really like get the first warning after a very short interval. I don't run my own SMTP daemon -- is it possible to send a first warning after 30 minutes and not every thirty minutes?

Agreed, but I would really like get the first warning after a very short interval. I don't run my own SMTP daemon -- is it possible to send a first warning after 30 minutes and not every thirty minutes?

I don't think this is something you can do with sendmail. I think you can only specify an interval, not whether you want just one warning or a warning every interval. Anybody have any clues?

I suppose an alternative would be to warn after 30 mins and then discard the message if not delivered after 59 mins.

> When I was a kid, I used to think that a 2400 modem was really fast.

2400? Let me tell you somethin' sonny, you ain't never had it rough.2400 *is* mighty fast, or was back in the day at any rate. [mutterssomething about that new-fangled UUCP network and snotty children]

You obviously haven't been around long. Some people on the net remember when email was slower than the postal service. 2 weeks to send a normal message was a common thing. It was free to the sender though, because someone else paid the long distance telephone bills (this is pre-breakup so the monopoly charged a lot more than they do today, and there has been a lot of inflation too)

I'm not quite that old, but I've done a lot a messaging on a 300 baud modem. The upgrade to 1200 was something I wished I co

Problem number one: For the most part, email is perfectly reliable. If it isn't delivered half an hour, 99% of the time it's because I screwed up the address. I'd like to know after 5 minutes, but I'd take half an hour. And I don't want the computer trying for four freaking days to send an email that I messed up.

Problem number two: Let's say there was a legitimate problem with the network. A router was taken down for maintenance, for instance. These days, people grumble if it's down for more than 10 minutes, and few outages last more than a couple hours. For the re-try interval, 12 hours is probably sufficient, but 24 will cover an overnight outage and its subsequent fix with time to spare. Heck -- How many outages last for more than a day? In the rare event that it does, it may last a week, or maybe a permanent change occurred to keep the mail from ever being deliverable.

So, I have no advice to you other than please, please make everyone you know configure their system as such.

The timeouts are there to handle cases where a remote server is off the net for whatever reason. While I can see shortening the warning message, your not helping yourself if you shorten the period of time that the server attempts to deliver for.

Sendmail (I'm not sure what MTA is being used for this example, but I would hope that would be irrelevant) can handle multiple queue times based on the priority of the message. With this you could have the high priority mail fail in 12 hours while nor

Translation: warn me if it takes more than 15 minutes to hit his server, and give up if it remains undeliverable an hour after I sent it. Warn me if the recipient takes more than 4 hours to read (IMAP) or fetch (POP3) to fetch the message after it arrives in his mailbox, and destroy it if it remains unread/unfetched for two days.

I agree that it would be good to have the initial warning message generated after 30 minutes. Or, perhaps after only 5-15 minutes! Since 99.9% of all email messages reach their destinations instantly (usually in a matter of seconds), alerting users to unusual behaviour is a good thing.

As was said by others, the purpose of this short timeout is to give the user a chance to try other methods of communication (FAX, phone, carrier pigeon, etc.). By holding the warning message until 24 hours or more have ela

We use dogsleds.If the dogs come back wanting food without the sled. Then the driver was eaten by a bear and the message did not get through and the sled sunk below the ice. Resend Messageelse If The dogs come back with the sled but without the driver and w/o reply Then the driver was eaten by a bear and the the dogs were hungry so they came home. Resend Messageelse If The dogs come back with the sled and the reply but without the driver. Then the team made it to the destination got the reply but the driver was eaten by a bear on the way home. However, the dogs were hungry so they returned.else If the driver returns with the team and the reply. Then the reply is a fake. The driver hung out at the brothel down the road for a few weeks and faked the reply. Resend message.

1) Send the email and request acknowledgement in your message
2) Make two printouts of the mail
3) Fax the first printout to your recipent
3) Phone the peer party for the receipt confirmation of both electronic and fax copy of said email
4) Mail the first printout to your recipent, don't forget to request acknowledgement
5) File the second printout in a huge three-ring binder
6) Assign a clerk to have him/her check hourly the status of the emails with the corresponding parties

... when you're dealing with people who don't take email seriously. We just got acknowledgement of an email request on a show-stopping problem, as it worked its way up the corporate ladder; it's already 5 business days old, and JUST reached the boss of the person who may have the information we need, even though the server delivered it to his mailbox within minutes of it being sent.

If the information is important they should pick up the phone. Email is very casual. Calling someone has much more of a personal touch. I also think it's easier to develop a relationship with your customers over the phone.

I wanted to flame our employees after they complained about not being to do business during Slammer worm. Hello, we have fax machines.

One consequence of the ubiquitous use of technology is people get lazy. God forbid they use their Egghead and find another way to work.

I think in business there are two main reason people communicate; sales and support. For Sales you would have a Customer Relationship Management (CRM) system or software. The Support side you are also going to have some type of system to help manage everything. The information should be stored in these systems. These systems have been around for many years before email and faxes were commonly used.

I use mgetty+sendfax for a FAX system, and all incoming and outgoing faxes are in the backups and archives of the server (as g3 files). The only limitation is they are not very easily searchable. (I suppose one could run an OCR on all the fax and come up with a way to search)

I think the main issue here is expectations. Make sure you set those right. Your users' expectations sound a little off the mark for E-mail. I don't expect them to understand what's involved under the hood, so maybe you need to educate them. Servers can and do go down. A four-hour window is just way too small.

Use another medium for super-urgent communications, like IM or phone. Or just simply follow up with a phone call: "Did you get that urgent E-mail? No? OK, I'll look into it."

No, four hours is long beyond the bounds of all reason. If a messagecan't go through in two hours, one of two things is wrong: eitherit was improperly addressed, or the recipient's business or ISP hasserious network problems of the sort normally associated with grossimcompetence or a major disaster (building fire, tornado, earthquake,or what-have-you). Four HOURS? What, don't they have a spareserver they can press into MTA service in a pinch? Or was itdown

As others have mentioned, even if the message leaves YOUR server, that really doesn't mean it was read. For me, I try to request a quick (manual) receipt for any important messages where time is of the essence; but it gets ignored most of the time. =)

What would be nice is if there was a standard for email "read" notices. Is there one? I sort of doubt it, considering the hacks I've seen to try and emulate it. Outlook has a proprietary thing that

> What would be nice is if there was a standard for email "read"> notices. Is there one? I sort of doubt it, considering the hacks> I've seen to try and emulate it. Outlook has a proprietary thing> that I doubt works.

This is a fairly old standard. (Pegasus Mail supported it in 2.0,which was out WAY before there was an Outlook and, for that matter,before there was a Netscape.) The problem is that privacy fanaticslobbied the mail client writers to have this feature disabled bydefault, even in t

after 60 minutes, it notifies the luser the mail is having problems arriving to the destination host but the server will keep trying, and after 48 hours notifies the user the message cant be delivered at all.

I have delay sent out after just a few minutes. If a message can't be sent in the first 10 minutes, chances are it's not going to be sent for the next few hours. So my delay message is short, letting the user know that the message isn't getting through. However sometimes things clean themselves up after a few days, so my "failure" message is set for 3 days. That way the message can keep trying as long as is reasonable, but the user also is informed right away that there may be problems.

I'm not sure when the feature was introduced, but later versions of Sendmail allow you to set different timeouts for different message priorities. The necessary settings for your "sendmail.mc" file are:

confTO_QUEUERETURN_NORMAL

confTO_QUEUERETURN_URGENT

confTO_QUEUERETURN_NONURGENT

and the same again with "WARN" in the place of "RETURN". The best thing is, if you set these in a certain way it *really* causes grief for those pricks that like to set the urgent flag on all their emails because they get innundated with warnings. It's like a LART, only without the lawsuit.;)

After the Sobig virus so of our email were taking 3 hours to get through and alot of our users were asking us why it took so long to send an email to someone that was less than 20 meters away (our ISP still does our email as I haven't had time to set one up in house). After getting close to 20 people asking me the same question I sent out an email giving everyone a quick idea of what happens under the hood and how it was a miricle that they got email at all.

It went something like this (short version):When you click on send the message is sent to our ISP. Our ISP then sends it to another ISP (our old ISP that till host our mail)which then sends it back to us. At each ISP it goes into a que with 1,000 of other messages. For your email to get from you to the person 20 meters from you it has to travel 6000+ km (Australia is a big country and our current ISP is in perth) and it normally does this in less than 5 minutes.

Also there are currently two viruses on the internet that have slowed down the entire internet: SoBig and Slammer.

After I sent the email out and explained how email worked and why everything was so slow lots of the users told me that they never new so much happened in the background. I haven't had anyone complain about email again.

I was buying it all, until that last line. You should have quite while you were ahead.

Either you're making this all up, or you only sent that message 5 minutes ago and then left the building. Please stop building up false hopes in young, impressionable, email admins, it's just not nice!

Apart from the occasional typo, I've never had a problem with mail not getting delivered. However I have had problems with it getting spam-filtered. One time it was because of a 'parody' version of the stupid disclaimer that PHB's seem to like putting on all their mail, which just happened to use a few too many of the wrong kind of keywords. Another time I was suggesting some software changes, and provided URL's for the appropriate RFC's.. My mail eventually got noticed, but it sat in the 'spam' folder for

E-mail is asynchronous. There's no guarantee that it will be delivered in a certain amount of time.

The telephone is synchronous. When it's answered, you're talking to the person real-time.

You've got to pick the right communications medium for the message. If your house is burning down, would you send an e-mail to the fire department? You'd be stupid to do that. And, going the other way, trying to turn a synchronous communications medium into an asynchronous one has given us all the curse of the 'voice mai

I think that most mail apps support return receipts? Heck, even webmail will. A big problem is that even if email is sent, there's no guarantee that it will be read in a timely manner. At least if you train your personnel to use return receipts, they'll know themselves whether or not the message got read (and if they don't get it by when they want, pick up the phone!).

Is there an equivilient server-side protocol to return a receipt if mail is sucessfully delivered? I suppose you could just write it into y