<DIV>The problem with external access to the server was due to GrayWall settings.</DIV> <DIV> </DIV> <DIV>The dns problem possibly had 2 parts. 1. Slow response time for the recipients reverse dns look up. 2. The 20 second timeout as the default setting in Mercury.  Since increasing a number of the timeouts in Mercury modules I have not had any more email problems.</DIV>

<DIV>Since upgrading to 4.51 we have been having a lot of problems with emails.</DIV> <DIV> </DIV> <DIV>I get Error 451 a lot when trying to reply to emails, but not often when creating new emails. These errors seem to occur when I am accessing the mail server from offsite and if I try to access it over a VPN from offsite also.</DIV> <DIV> <DIV>I have checked the MTU value as per a different thread and changed it to a non fragmenting value (1465) reported by TCP Optimizer.</DIV> <DIV> </DIV></DIV> <DIV>I turned on session logging and here are the 2 types of error messages I get. These errors were for emails with attachments.</DIV> <DIV> </DIV> <DIV>17:14:14.343: << <cr><lf> 17:14:14.375: << .<cr><lf> 17:15:14.406: 8: Socket read timeout 17:15:14.562: << QUIT<cr><lf> 17:15:18.984: >> 205 2.0.0 Ok: queued as 708E7988068<cr><lf> 17:15:18.000: --- Connection closed normally at Mon Aug 06 17:15:18 2007. --- 17:15:18.046: 21:56:35.046: --- Tue Aug 07 21:56:35 2007 --- 21:56:35.218: Connect to 'xx.yy.69.109', timeout 60. 21:57:36.250: 8: Socket read timeout 21:57:36.281: --- Connection closed normally at Tue Aug 07 21:57:36 2007. ---</DIV> <DIV> </DIV> <DIV>21:42:44.265: 9: Socket write error 10054 (connection aborted by remote host) 21:42:44.296: 9: Socket write error 10054 (connection aborted by remote host) 21:42:44.359: << QUIT<cr><lf> 21:42:44.390: 9: Socket write error 10054 (connection aborted by remote host) 21:42:44.421: 7: Socket read error 10054 (connection aborted by remote host) 21:42:44.453: --- Connection closed normally at Tue Aug 07 21:42:44 2007. ---</DIV> <DIV> </DIV> <DIV>Does anyone have any ideas about the cause of this?</DIV> <DIV> </DIV> <DIV> </DIV>

<DIV>The Mercury SMTP Client is also reporting errors.</DIV> <DIV> </DIV> <DIV>"Network write failure during data transmission to zzz.yyy.www.vvv"</DIV> <DIV> </DIV> <DIV>"Connection error during handshake with zzz.yyy.www.vvv"</DIV> <DIV> </DIV> <DIV>With regards to the 451 errors. I have noticed a lot of "Closed by GreyWall" messages in the SMTP Server window. I assume this is the source of my 451 errors.</DIV> <DIV> </DIV>

<P>Have you tried turning Graywall off?</P> <P>A little more information about your configuration may be useful - what mail clients are used and how they are connecting to Mercury, which daemons you have installed etc.</P> <P mce_keep="true"> </P>

<DIV>I have all Mercury modules loaded. After I identified the Graywall issue I reconfigured it a little and I hope this problem is gone. I am still getting problems sending emails to some external accounts. Originally I thought it was related to sending pdf attachments but recently I has one with a .rar attachment and one with no attachment return arrors even though the emails were delivered.</DIV> <DIV> </DIV> <DIV>We use Eudora for our email clients accessign the server using POP3. When I get an opportunity I want to look at alternatives as Eurdora seems to be on the way out.</DIV> <DIV> </DIV> <DIV>Currently we are not using IMAP but that is an option we want to look at in the future.</DIV>

<p>If I understand you correctly you get networking errors when sending via SMTP to Mercury from the Internet or via a VPN connection (but not from your local network), and there are networking errors in outgoing SMTP connections from Mercury as well. Errors occur only for larger messages (as you say they have attachments). </p><p>If the MTU value is optimal and the problem isn't restricted to special destinations the next step would be to examine all networking devices in the chain these messages are transferred at your site, such as the network adapter in the Mercury server, network switch, router, firewall, DSL modem etc., and look for malfunctions. Restarting all equipment can sometimes help (routing tables in network switches can get very confused over time). If not, replacing one item at the time may be the only way to find the source of the problem.</p><p>We use Eudora a lot, both POP3 and IMAP, and even though it's true that the program isn't being developed any more it still works without problems.</p><p>/Rolf  </p><p> </p>

<DIV>Rolf,</DIV> <DIV> </DIV> <DIV>There seem to be a number of problems with my mail system.</DIV> <DIV> </DIV> <DIV>The 1st problem related to the GreyWall. It wouldn't accept emails from me when I was using the vpn or otherwise accessing the mail system from an external IP address. That seems to be fixed now.</DIV> <DIV> </DIV> <DIV>The 2nd problem is that a number of recipients seem to send error messages to Mercury when emails with pdf attachments are sent to them even though the email is delivered. Mercury then keeps resending the emails. In another thread it was recommended to change the windows MTU (1500 defualt) to something different as the adsl connection uses 1492. I have reset mine to 1465 but this hasn't fixed the problem. The theory was that some packets were fragmenting.</DIV> <DIV> </DIV> <DIV>The 3rd problem is that one or more reciepients were not receiving emails at all. Mercury returned a timeout error. On further investigation one of the recipients informed me that their dns server response time was slow. I also noted that the dns timeout in Mercury was set to 20 seconds. The recipient did some work to speed up his dns response and I changed the mercury dns timeout to 60 seconds. 20 seconds (default) seemed quite low. This appears to have fixed this problem.</DIV> <DIV> </DIV> <DIV>I found this link useful for identifying the problem with the recipients dns.  <A href="http://member.dnsstuff.com/pages/dnsreport.php">http://member.dnsstuff.com/pages/dnsreport.php</A></DIV>

<P>Are you are using MercuryE ?  It has been suggested that specifying name servers is better than using the Windows default in most cases.  Have you got a good reverse DNS on a static IP too? - lots of servers are fussy about who they receive from these days.  I would suggest using the relay module (MercuryC) if at all possible.</P> <P mce_keep="true"> </P> <P mce_keep="true"> </P>

Have you tried checking the directory permissions for the mail boxes and the Mercury Queue directories to ensure that the account you are logged on to your internal domain with when accessing from outside has the necessary permissions?   Some operations are carried out by mercury using its own log on account others by the account running the mail client.   This is mainly and issue with reading emails and with sending to local addresses, so It is not likely to be your issue but if you are still having problems do check the security settings on your mail server.