How are Your SMTP Timeouts Configured?

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?"

Comments

obvious

[Anonymous Coward]

Open relay
what other setting matters.

Re:obvious

[Anonymous Coward]

import java.milf;

public class YourMother implements Fuckable extends MyCock

Defaults of 4 hours and 4 days.

[ComputerSlicer23]

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.

Kirby

Re:Defaults of 4 hours and 4 days.

[Mattcelt]

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.

Re:Defaults of 4 hours and 4 days.

[Anonymous Coward]

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...

Re:Defaults of 4 hours and 4 days.

[I8TheWorm]

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 told you it might not work" or not, users are very dependant on that service. And when the CEO calls and says "my e-mail didn't go through" the response is not likely to be something like the above.

Why rely on email?

[Dancin_Santa]

You made a good point about sending faxes or using FedEx.

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.

Without the voice confirmation, it's impossible to tell (as your headached co-worker knows) whether or not the message has been delivered.

Re:Why rely on email?

[raju1kabir]

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 sensitive documents.

Re:Why rely on email?

[Specialist2k]

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...

Re:Why rely on email?

[91degrees]

Most of the time, if you want to do this, you may as well just call or just fax.

If it absolutely HAS to get there, demand a reply. Resend if you don;t get it.

Some suggestions

[Alpha27]

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.

Re:Some suggestions

[Alpha27]

At least one thing we can be thankful for....

The USPS has prior art on delayed mail, so no patent can be taken by the inventors of SMTP or anyone else.

Re:Some suggestions

[0x0d0a]

And email is not as reliable as other services. It's not regular mail, there's no certified letters.

I had an airmail letter get lost just the other day.

Considering the far, far, far, far larger volume of email I send -- way over 100 to 1 ratio to normal mail -- email may not actually be less reliable.

Re:Some suggestions

[Alpha27]

Well it looks like we're running out of options....

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 looking at all. (sorry I was on the other smokeline; or sorry had something in my eye)
- interference from other smoke signals. way too many jokes can be applied here.
- smoke and real fires might get confusing.

Ok ok, how about... two cups and a string. We can use titanium cups and silk spider webbing. Make the ultimate internet. Unforunately I do see the manifestation of audio blogs, and ppl's incessant wining. (ooh, my spouse doesn't cook, clean or wash, woe is me)

Message in a bottle? Nope, tidal currents may have a bottle floating for years before your message about what you want for dinner finally arrives.

Catapulting message bottles? Now that sounds like fun, until property damage occurs, and accidental deaths.

Well looks like we have no reliable way to send a message. I guess we'll just have to pretend we did and blame the other person.

timeouts

[SpaFF]

I have my queuereturn set to 2 days and my queuewarn set to 12 hours.

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.

Re:timeouts

[hawkstone]

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?

Re:timeouts

[SpaFF]

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. This would allow people to only get one message, but you would have to process your queue very frequently (like every 5 mins or so) if you wanted to actually have a half-hearted attempt to deliver the message.

Re:timeouts

[jonadab]

> I don't think this is something you can do with sendmail.

So if you need to do that, don't use sendmail. Use one of the
other options -- Net::Server::Mail, for example, can surely be
made to handle such things.

Impatience...

[ptaff]

When I was a kid, I used to think that a 2400 modem was really fast. You could download a 300KB game in a few minutes. And I could store dozens of them on my 20MB hard drive.

When I hear newbies complaining about their slow 300KB/s connections and too small 100GB storage units, I feel anger inside. They just can't appreciate the value of technology.

When E-mail was introduced 30 years ago, it was an amazing feat: you could send messages across the country in less time than regular postal service. Wow.

Now we're complaining about limitations of a 30-year old technology that works as intended. Come on. It's still amazing. There are IMs, IRC channels all over the place for these "urgent needs".

Don't blame the hammer if it doesn't mow your lawn.

Re:Impatience...

[turg]

He's not blaming the hammer. He just wants to inform the user in a timely fashion that the lawn still needs mowing.

Re:Impatience...

[jonadab]

> 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. [mutters
something about that new-fangled UUCP network and snotty children]

Re:Impatience...

[vasqzr]

[b]
So your email walked up hill, both ways?
[/b]

Re:Impatience...

[b!arg]

In the snow...

I completely agree.

[hawkstone]

For God's sake, yes!

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.

(Flames -- err, I mean opposing viewpoints -- welcome.)

Re:I completely agree.

[Krellan]

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 elapsed, the user's attention will have gone on to other things and they will begin to erroneously assume that the email has already safely arrived.

However, the hard timeout, at which the SMTP server gives up trying to forward the message, should remain at 4 days or more. I've had servers go down for a few days, typically a weekend upgrade, and it's great to be able to bring them back up without bouncing anybody's email messages. Reducing the hard timeout would just put more of a burden on everybody else to get their servers back up before the hard timeouts expire. It's hard enough to guarantee bringing up a system in 4 days after a disaster, and some want to make it only 1 day?!

Perhaps a third timeout should be added: something between the soft timeout and the hard timeout. I can see having timeouts of 15 minutes, 24 hours, and 4 days. At the middle timeout (24 hours), a second warning message would be generated for the sender, to further let them know that their message has been delayed. This keeps up the "three strikes" tradition of having the first two error messages be only warnings, and only the third email message is a true error (containing the bounced message).

Re:I completely agree.

[Anonymous Coward]

If it isn't delivered half an hour, 99% of the time it's because I screwed up the address.

The other 1%: because you're trying to send to a hotmail.com address. (Do thoese ever go through right away?)

Re:I completely agree.

[macdaddy]

Heck -- How many outages last for more than a day?

Obviously you've never been the administrator of anything.

Up here in the great white north

[the_other_one]

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 Message
else 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 Message
else 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.

Solutions

[jsse]

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

It's your business on which your life is depending. You can't be too safe, you know.

Server timeouts don't matter...

[WoodstockJeff]

... 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.

Use the Phone

[citadelgrad]

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.

Re:Use the Phone

[ffsnjb]

Carla was the prom queen...

Sorry, couldn't resist. That's one of my favorite scenes in The Rock.

Re:Use the Phone

[bhima]

I I genuinely hate phones & fax machines!

Neither provide a legitimate archival system. Thank the Gods fax has moved away from thermal paper! But it's still not archival ready.

In the time that follows how do you remember what decision was made, or what was done?

How you record a phone call into a design history file? Meeting minutes are bad enough but to transcribe a phone call is painful, our conference calls are a nightmare to archive!

E-mail must be as reliable as phone or fax services (even if all I get is a record that it was sent properly!). To use phone or fax as a regular replacement for these things is not only archaic but in some instances irresponsible. As a corollary to this: E-mail Storage must be reliable too. You must be able to ensure archival quality reliability and change logging. Microsoft's various PST & OST do not fit this being that they are both unreliable (for some reason they are easily corrupted) and they don't log any changes to content.

I suppose the difference is I use my email as part design history and part document storage! Which it was never designed to do. So I back up early and backup often!

Re:Use the Phone

[citadelgrad]

I agree. I hate phones and there is usually no proper storage system.

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.

Email is a quick and dirty form of communication. The archival of email allows us to CYA.

The interesting thing with the Internet and Technology is everyone expects it to work all the time. Scenario: Johnny can't get a pdf purchase order to a client for 48 hours because the mail server is backed-up with a virus. Johnny can't understand why it is not getting to the client. What if: Johnny print's out a 1 cent copy of the order and puts into a FedEx package($8), overnight. Now if it gets lost because the Plane blows up due to a leaky fuel line. Does Johnny remail the order? Damn right. He knows shit happens. Why can't people have similar expectations of technology? ~Adapt or die~ WeRD!

Re:Use the Phone

[chipperdog]

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)

Re:Use the Phone

[bhima]

Hey! That's a pretty good idea.

Still doesn't change the fact that I'd rather use 8 track cassettes than Fax :)

Though one of my gripes with fax is than they are not easily indexed or searchable

It is TOO just like regular mail!

[microcars]

I just got an email that was sent MARCH 2003.

It "arrived" on October 06 2003 and asked about an event in April. I assumed the sender was referring to April 2004 and replied as such.

I got an angry reply telling me to "Check the Date on the Email I Sent You!"

The headers showed October 6. Nothing else!
This guy thought I was JUST getting around to checking my email and was really pissed off that I took 6 months to respond to him!

I thought this stuff only happened to the USPS.

I almost completely disagree

[infra-red]

Uhm... NO!!!

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 normal mail takes a normal amount of time.

When mail runs great, its smooth and very timely. But when it breaks, it can go down hard.

In my experience, the recovery of a mail server isn't what takes the most time, its the ammount of time it takes to process the backlog from other servers queues.

If you run at 50% capacity, then basically, an outage of 2 hours will take you 2 hours more to get caught up, and thats assumeing that your server is running optimally. Best way to find bottlenecks in your mail servers is to shut it down for an hour and see what stops it from working (syslog is great for doing this if you have unbuffered logging).

Timeouts are there to help the system recover when something goes wrong. Use the priorities to change the timeouts, but dropping mail too quickly is just doing everyone a disservice.

Personal experience. I saw a system setup to drop all messages that were not delivered in 45 minutes. I was floored when I saw this. They had a problem with the machine and their system took almost a week to stabalize and catch up (underpowered systems running too many opposing services. DNS on the mail servers is not good since when you do alot of mail, your lookups steal CPU from your mail servers and the problem gets amplified when you processing the backlog)

Expectations

[sakyamuni]

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."

Re:Expectations

[jonadab]

> A four-hour window is just way too small.

No, four hours is long beyond the bounds of all reason. If a message
can't go through in two hours, one of two things is wrong: either
it was improperly addressed, or the recipient's business or ISP has
serious network problems of the sort normally associated with gross
imcompetence or a major disaster (building fire, tornado, earthquake,
or what-have-you). Four HOURS? What, don't they have a spare
server they can press into MTA service in a pinch? Or was it
down for three hours before they even noticed? If my ISP didn't
take their job more seriously than that, I'd have switched ISPs
long ago.

If it's a major disaster, the recipient will have other worries than
receiving your message, so the long timeouts are appropriate. If
it's gross incompetence on the part of the recipient's IT department
or ISP, which is not as unusual as we might wish, the recipient may
not realise this and may blame the problem on you -- which means,
you need to know about the problem so you can make arrangements to
contact the recipient another way. If it was improperly addressed,
the sender needs to know, and the sooner the quicker.

For a mail server that handles residential customers, I would leave
the timeouts long. If a residential customer gets a warning that
the message isn't going through, they're either going to shrug and
blame themselves or their computer (in which case, it makes no
difference whether it's been ten minutes or ten days since the
message was sent) or else they're going to call tech support. So
you want to send as few of these as possible, hence, long timeouts.

For an MTA at a business used by employees to send mostly business
mail, I would definitely shorten the timeouts. If a message does
not go through in a timely fashion, what will the user do? Call
you? Maybe the first couple of times, but you instruct your tier-1 guy to explain that it could be a result of the recipient's network
having problems, and before long your users are trained that if
they get the warning and the message has to be timely, they need
to make other arrangements.

Frankly, thirty minutes seems quite long to me, for the warning.
Most messages go through in thirty seconds. A ten-minute warning
will only fire occasionally, and when it does you'd usually still
be getting the warning if the timeout was set to ninety minutes.
You do want to leave the bounce timeout set in days, though,
because many messages (yes, even many business messages) are not
quite so urgent, and you don't want to make the user retry manually
every couple of hours; that would be a much bigger hassle.

And I agree with whoever said you only want the timeout short
for the first warning; you don't want a warning *every* ten
minutes (oh, my word, no), only after the first ten minutes,
and perhaps another one after a day or so, and that's enough,
until it bounces. The user already has the idea it's not
going through in a timely fashion; if they weren't concerned
enough to take action the first time, they won't be the second
time or the third time either.

I'd rather have user override options

[leonbrooks]

X-Undelivered-Warning: 900
X-Undelivered-Abandon: 3600
X-Unread-Warning: 14400
X-Unread-Abandon: 176800

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.

Re:I'd rather have user override options

[mindhaze]

Yeah! this would be amazing! Who do we contact to get the email RFC modified?

I'm far too dependant on email to have it any other way!

Email receipts anyone?

[WoTG]

Anyone know if there is a standard for email receipts?

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 I doubt works. I've also seen what amounts to a webbug being used for HTML messages.

Re:Email receipts anyone?

[0x0d0a]

I believe Outlook's scheme is standardized, and that other clients support it.

Re:Email receipts anyone?

[richi]

You're looking for DSNs (delivery service notifications; RFCs 3461 and 3464) and MDNs (message disposition notifications; RFC 3503).

richi.

Re:Email receipts anyone?

[jonadab]

> 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 fanatics
lobbied the mail client writers to have this feature disabled by
default, even in the mail clients that did support it, and so it
never became reliable and never caught on. Today, of course,
turning it on by default would be insane, because of spam, but
that was not the reason ten years ago. People were concerned that
the sender might know when they read the message and so might
expect an immediate response, and they wanted to be able to claim
they hadn't seen the message yet, if they didn't have time to
respond or just didn't feel like it.

Re:Email receipts anyone?

[WoTG]

Thanks for the info (ditto for the other responses). So, because of spam, I'll never get email read receipts, eh? Great...

mdaemon is pretty smart at handling this

[Indy1]

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.

Delay short, failure long.

[clambake]

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.

Use the message priority flag

[Zocalo]

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. ;)

DeliverBy

[grahamm]

Could this problem not be solved by using the (RFC2852) Deliver By mechanism when submitting the email where timely delivery is important?

Education is the answer.

[natmsincome.com]

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.

Re:Education is the answer.

[rerunn]

Your sysadmin -- Fire his ass ;-)

Re:Education is the answer.

[dheltzel]

. . . 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!

Re:Education is the answer.

[Tony-A]

Please stop building up false hopes in young, impressionable, email admins, it's just not nice!

Always blame Microsoft.

That's what you do first. Then you find out why.
Works incredibly well.

Mail is reliable, spam filters aren't

[zcat_NZ]

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 a week or two first.

haven't been aroung long have you?

[bluGill]

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 could afford for years. Then a year latter lightening took out the modem and I was back to 300 baud until I could afford a modem again.

Educate your users

[PD]

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 mail' and the 'answering machine'. Voice mail is a hack, trying to make the telephone do something it wasn't meant to do. And, as a hack, it's cumbersome to use. Virtually all voice mail systems work differently, and they make you go through their menus in a serial fashion. See how long it takes to delete 100 voice mails, and you'll know what I mean.

Educate your users.

You write an RFC modifying the protocol yourself.

[leonbrooks]

Scary, isn't it? (-:

Ti...ming

[Anonymous Coward]

When I first started at the company I'm at now, the internet connection was high speed download but dialup upload (don't ask me, I never understood why either). So the previous guy who looked after things had set up a relay on one box so people could queue up their messages, epecially if there were any large attachments, and the machine would send them out one by one. The initial time out warning was at 24 hours, and after 48 it would kick the message into a 'Bad' message folder. I went in this folder one day to clear it out, and found some interesting things. For example, someone had tried to e-mail a friggin' 220 MEG file! There were a couple of others around the hundred meg mark, and a few more in the high 80's. Add in the 'retry twice', and it's a wonder any of our e-mails made it out at all. This relay box was quickly changed to limit the message size to 3 meg, and a 4 hour first warning and 12 hour fail warning. This solved many problems :) Mind you, I still had to deal with a horrible 'Net provider Look Communications, and even had one of their own tech guys tell me they no longer offered the hardware we were using because, and I quote, "it's flaky". But we were stuck with them until an alternate high speed option became available in our area. And let me tell you, once there was one, I had us quickly changed over.

But I digress... I'd say cut those times down, and make sure people ain't trying to e-mail CDs to their buddies :)

Return Receipt?

[phorm]

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 your SMTP delivery system, that a mail returns a message if it went through (or a web-visible mail queue, whatever).