This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

30 hours before notification from ASG of mail delivery delay

How long should it take for an ASG to notify a sender that a message hasn't gone through to a recipient?  With many messages, you might not care, but for some messages, it's very important.

A sender sends a message to a recipient.  30 hours later the Astaro notifies the sender that the recipient's mail server has not acknowledged, but that it will keep trying.

Why 30 hours before notification?  Is this parameter adjustable?  One or two hours ought to be enough.

Here is the message the sender received:
From: Mail Delivery System [mailto:Mailer-Daemon@firewall.[sender-company].com]
Sent: Tuesday, March 01, 2011 7:48 PM
To: [Sender of Msg]
Subject: firewall.[sender-company].com Warning: message 147DKG-0005tS-01 delayed 24 hours

This message was created automatically by the SMTP relay on firewall.[sender-company].com.
A message that you sent has not been delivered to all of its recipients after more than 24 hours on the queue on firewall.[sender-company].com.
  
The message identifier is:     147DKG-0005tS-01
The subject of the message is: Costs, Timeline, & Journal Entries
The date of the message is:    Mon, 28 Feb 2011 14:52:23 -0800
  
The following address(es) have not yet been delivered:

  recipient@[recipient-company].com
    Delay reason: SMTP error from remote mail server after end of data:
    host mx1.[recipient-company].com [x.x.x.x]: 451 qq temporary problem (#4.3.0)

No action is required on your part. Delivery attempts will continue for some time, and this warning may be repeated at intervals if the message remains undelivered. Eventually the mail delivery software will give up, and when that happens, the message will be returned to you.


This thread was automatically locked due to age.
Parents
  • This is not a configurable option and the first notification should go out after around 24 hours. Most mail servers are set to send this first notification after 12-24 hours by default. The amount of time that it takes is based on the DSN code. If it is a "hard-fail" code, such as 5.1.1, then the NDR will be generated immediately. In your case, it is a "soft-fail". There is some issue keeping the mail from reaching the final destination, but nothing that is telling the Astaro definitively that the message cannot go, so it will keep trying at staggered intervals for three days (with notification at 24 hours, 48 hours, and at final fail) until finally giving up for good.
     
    The way that this works is regulated by IETF RFCs that were designed when it was not unusual to have servers offline for extended periods due to maintenance, bandwidth was extremely limited, and taking into account that the underpinings of email (SMTP) really aren't all that robust. They only take into account that things operate in as robust a means as possible and interoperability.
     
    It's actually fairly common to block NDRs to the internet altogether, due to the possibility of getting DoSed in an NDR-storm.
    __________________
    ACE v8/SCA v9.3

    ...still have a v5 install disk in a box somewhere.

    http://xkcd.com
    http://www.tedgoff.com/mb
    http://www.projectcartoon.com/cartoon/1
Reply
  • This is not a configurable option and the first notification should go out after around 24 hours. Most mail servers are set to send this first notification after 12-24 hours by default. The amount of time that it takes is based on the DSN code. If it is a "hard-fail" code, such as 5.1.1, then the NDR will be generated immediately. In your case, it is a "soft-fail". There is some issue keeping the mail from reaching the final destination, but nothing that is telling the Astaro definitively that the message cannot go, so it will keep trying at staggered intervals for three days (with notification at 24 hours, 48 hours, and at final fail) until finally giving up for good.
     
    The way that this works is regulated by IETF RFCs that were designed when it was not unusual to have servers offline for extended periods due to maintenance, bandwidth was extremely limited, and taking into account that the underpinings of email (SMTP) really aren't all that robust. They only take into account that things operate in as robust a means as possible and interoperability.
     
    It's actually fairly common to block NDRs to the internet altogether, due to the possibility of getting DoSed in an NDR-storm.
    __________________
    ACE v8/SCA v9.3

    ...still have a v5 install disk in a box somewhere.

    http://xkcd.com
    http://www.tedgoff.com/mb
    http://www.projectcartoon.com/cartoon/1
Children
No Data