Follow Slashdot stories on Twitter

 


Forgot your password?
Close
typodupeerror
×
The Internet

How are Your SMTP Timeouts Configured? 61

Posted by Cliff 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?"
This discussion has been archived. No new comments can be posted.

How are Your SMTP Timeouts Configured? More

How are Your SMTP Timeouts Configured?

Comments Filter:

  • obvious (Score:1, Funny)

    by Anonymous Coward
    Open relay
    what other setting matters.

  • Defaults of 4 hours and 4 days. (Score:4, Insightful)

    by ComputerSlicer23 ( 516509 ) on Tuesday October 07, 2003 @10:48PM (#7159618)
    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. (Score:4, Insightful)

      by Mattcelt ( 454751 ) on Tuesday October 07, 2003 @11:21PM (#7159865)
      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. (Score:1, Funny)

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

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

    • 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...
    • 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 (Score:3, Interesting)

    by Alpha27 ( 211269 ) on Tuesday October 07, 2003 @10:50PM (#7159635)
    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.
    • 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.

    • 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 (Score:3, Interesting)

      by 0x0d0a ( 568518 )
      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.
      • 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 lo
  • 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.

    • 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.
        • > 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... (Score:4, Insightful)

    by ptaff ( 165113 ) on Tuesday October 07, 2003 @10:56PM (#7159679) Homepage
    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... (Score:3, Insightful)

      by turg ( 19864 ) *
      He's not blaming the hammer. He just wants to inform the user in a timely fashion that the lawn still needs mowing.
    • > 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]
    • [b]
      So your email walked up hill, both ways?
      [/b]

    • 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

  • I completely agree. (Score:4, Insightful)

    by hawkstone ( 233083 ) on Tuesday October 07, 2003 @11:07PM (#7159758)
    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.)
    • 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 nor
    • 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
    • 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 (Score:5, Funny)

    by the_other_one ( 178565 ) * on Tuesday October 07, 2003 @11:08PM (#7159764) Homepage
    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 (Score:2, Funny)

    by jsse ( 254124 )
    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 y
  • ... 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.
    • Carla was the prom queen...

      Sorry, couldn't resist. That's one of my favorite scenes in The Rock.
    • 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 al

      • 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 c
      • 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)
        • 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

  • Expectations (Score:2, Insightful)

    by sakyamuni ( 528502 )

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

    • > 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
  • 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 believe Outlook's scheme is standardized, and that other clients support it.
    • You're looking for DSNs (delivery service notifications; RFCs 3461 and 3464) and MDNs (message disposition notifications; RFC 3503).

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

  • Use the message priority flag (Score:4, Informative)

    by Zocalo ( 252965 ) on Wednesday October 08, 2003 @05:05AM (#7161191) Homepage
    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. ;)
  • 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. (Score:4, Interesting)

    by natmsincome.com ( 528791 ) <adinobro@gmail.com> on Wednesday October 08, 2003 @06:48AM (#7161444) Homepage
    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.

    • Your sysadmin -- Fire his ass ;-)
    • . . . 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!

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

  • Educate your users (Score:2, Insightful)

    by PD ( 9577 ) *
    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

Slashdot Top Deals

It is easier to write an incorrect program than understand a correct one.

Close