logo

Contact Us  |  Log In  |  Sign Up  |  Blog

 
MailSite Knowledge Base
Find answers and solutions to MailSite questions and problems
Outgoing mail is held indefinitely in HOLDING
Document #:10026

Applies To:
  • MailSite All

Synopsis:
Messages received by MailSite that are destined for remote addresses are queued for delivery in the HOLDING folder. Under certain circumstances, these messages may remain in HOLDING for days before being returned to sender. The length of time is controlled via Schedules > Elapsed Time Schedule within the MailSite Console.

More Information:
Messages are held indefinitely in the HOLDING queue because the remote mail system cannot be contacted or is not able to receive mail. Typically occurs because of incorrect MX records in the DNS server at the remote site.

Use the following procedure to determine whether the problem is related to MX records:

1. Open one of the queued messages (.MSG) in SPOOL\HOLDING and determine the destination domain.
2. In the SPOOL\DOMAINS folder, locate the folder corresponding to the destination domain of this message.
3. Within the domain's folder, open the file DOMAIN.MRI in a text editor (such as Notepad). The file should contain information like the following:

Domain-name: rockliffe.com
Last-tried: 910535708
Try-number: 1

Mx-host: rockliffe.com
Mx-preference: 0
Mx-status: 0
Mx-expires: 910539263
Mx-ip-address: 209.232.120.66


If "Mx-" lines similar to those shown above do not appear in DOMAIN.MRI, then the DNS of the remote site has not been properly configured. Notify the administrator of the remote domain of the problem.

If the "Mx-" entries exist in DOMAIN.MRI and appear to be complete, then the issue is an inability to connect to the remote mail server. This may indicate a connectivity problem on your network or at the destination site. To troubleshoot the connection, execute the following from the Windows Command Prompt (using the host and domain name of the remote mail server system):

C:\>ping mail.domain.com

The PING command, if successful, will return data sch as the following:

Pinging mail.domain.com [209.232.120.66] with 32 bytes of data:
Reply from 209.232.120.66: bytes=32 time=10ms TTL=128
Reply from 209.232.120.66: bytes=32 time=10ms TTL=128
Reply from 209.232.120.66: bytes=32 time=10ms TTL=128
Reply from 209.232.120.66: bytes=32 time=10ms TTL=128


If PING instead returns 'Bad IP Address' then your DNS resolution is not working.

If PING requests timeout, then your Internet connection may not be working.

If the PING operation succeeded and the remote mail host can be contacted, use the TELNET command to open a connection to the remote system's SMTP server:

C:\>telnet mail.domain.com 25

TELNET should respond with a welcome banner, like the following:

220 mail.domain.com MailSite SMTP Receiver Ready

If the TELNET connection fails, it may be that the remote mail system is temporarily offline, or that a router or server between your system and the remote site is malfunctioning. Your server AV software or Firewall may be blocking outbound access to port 25. If you are unable to telnet to mail.mailsite.com 25, then it is likely something on your server/network blocking access to port 25. To test the connection path, use the TRACERT command:

C:/>tracert mail.domain.com

This command will display information for each server or router between your site and the remote server. Check this output for one or more non-responsive components.

The remote mail system may also be blocking all SMTP connections from your network; for example, if your mail server is on the MAPS RBL blacklist, or if the remote site is blocking all clients that are unknown in the DNS. Contact to the administrator of the remote site to determine whether they are blocking your mail.

Last revised 2009-4-30

Products  |  Features  |  Support  |  Resources  |  Partners  |  Site Map  |  FAQ  |  Privacy  |  Contact Us