Thread Info
  • State Suggested Answer
  • Locked Locked
  • Replies 3 replies
  • Answers 1 answer
  • Subscribers 3 subscribers
  • Views 4811 views
  • Users 0 members are here
Options
Suggested
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

Email with wrong tld hangs three days before Non Delivery Notification

KantBerlin

Hi,

when sending an email with wrong tld (instead of .com, .de was used), the sender gets a Bounce Message after three days:

-----Ursprüngliche Nachricht-----
Von: Mail Delivery System [mailto:Mailer-Daemon@email.senderdomain.com]
Gesendet: Freitag, 17. November 2017 11:42
An: Max Mustermann
Betreff: email.senderdomain.com Mail delivery failed : returning message to sender

This message was created automatically by the SMTP relay on email.senderdomain.com.
 
A message that you sent could not be delivered to all of its recipients.
The following address(es) failed:

  adam@wrongtld.de
    retry timeout exceeded

------ This is a copy of the message, including all the headers. ------

 

In smtp logs, I see this message every minute for this mail and for three days:

/var/log/smtp.log:2017:11:17-05:07:00 fwb-1 exim-out[4498]: 2017-11-17 05:07:00 1eEYcX-0003nK-EY == adam@wrongtld.de R=dnslookup T=remote_smtp defer (-53): retry time not reached for any host
/var/log/smtp.log:2017:11:17-05:10:07 fwb-1 exim-out[4734]: 2017-11-17 05:10:07 1eEYcX-0003nK-EY == adam@wrongtld.de R=dnslookup T=remote_smtp defer (110): Connection timed out

If I search the log files for "retry time not reached for any host" i find no further emails with the problem.
Is it possible to get the bounce message earlier for this error? Normally something like that happens in minutes.

Thanks for any hints.

Best regards,
KantBerlin

 



This thread was automatically locked due to age.
Parents
  • 0

    This is normal behavior.  By the standard, servers are supposed to try for four days before giving up.  The design assumption is that servers or network paths may be down.

    These days, I think most systems only wait for two days before giving up.

    The retry behavior is probably configurable at the shell level.  You will have to ask support to find out how.

Reply
  • 0

    This is normal behavior.  By the standard, servers are supposed to try for four days before giving up.  The design assumption is that servers or network paths may be down.

    These days, I think most systems only wait for two days before giving up.

    The retry behavior is probably configurable at the shell level.  You will have to ask support to find out how.

Children
No Data
Unfiltered HTML