Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 4 replies
  • Subscribers 2 subscribers
  • Views 1340 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

SMTP PROXY fails to dequeue messages.

gregw
version 4.015

If the internal SMTP server  becomes unreachable,  the SMTP proxy on the firewall fails to deliver mail to the internal SMTP after it becomes reachable again,  even after 8 hours.  Typical log bit:

2003-Nov 16 01:36:09 fw exim[24410]: 2003-11-16 01:36:09 1ALGWK-0007dj-Ls == greg@calibreNOSPAM.com R=static_exact T=remote_smtp defer (-53): retry time not reached for any host

at the CLI,  typing:
chroot /var/chroot-smtp /bin/exim -qff

will push the queue to the internal mailserver correcting things.

Anyone know what might be the real issue here?  Our set up seems simple enough:

INTERNET > SMTP_PROXY-on-FW > internal-SMTP server.

I have waited over 8 hours to see if the mail will dequeue by itself  after the internal SMTP server is back up without luck.  Any new mail  arriving at this point (after the internal SMTP server is reachable) will queue up on the FW giving the same error as above, seemingly never to dequeue.  After issuing the above command from the CLI,  old mail is pushed to the internal SMTP server and new mail arriving is processed as expected.
  


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

    when the e-mail server is temporary not available mail gets queued up. This queue has certain timers:

    From /var/chroot/smtp/etc/exim.conf

    [ QUOTE ]
     F,2h,15m; G,16h,1h,1.5; F,4d,6h

    [/ QUOTE ]

    So it depends on the downtime of your server how long the interval of retrying becomes (sounds very German, who cares :-) , hope you get me).

    The command you have applied ignores all the timers and tries to deliver at once a so called forced queue run - it is almost equal to deleting the content of  /var/chroot-mail/smtp/spool/db .

    Greetings
    cyclops     
  • 0 in reply to cyclops
    Thanks for the reply.  I am familar with how mail systems work,  but no experince with exim till now.  This is why I mentioned the 8 hour wait.  Perhaps I should of said why I waited 8 hours.   Anyway,  you'll notice in the post I also mention  new mail arriving is also queued and not delivered to the internal mail server.  This does not seem like normal behaviour for a MTA.  

    Again thanks for your input, 

    greg
       
  • 0 in reply to gregw
    now I am guessing (didn't reproduce it) but I think that exim stores information that your server was down in /var/chroot-mail/smtp/spool/db and doesn't try to deliver mail to this specific server until the timer is up. Simply delete the content of /var/chroot-mail/smtp/spool/db and things should be well again (this doesn't harm exim or the SMTP proxy, did that before)

    Greetings
    cyclops  
  • 0 in reply to cyclops
    it would seem the patches have fixed things.  I unplugged the ethernet to the internal mail server and things worked as expected after plugging it back in.  I mistakenly thought it was at patch leve 015 but it was not.  (I thought what I seen was a list of applied patches,  not patches waiting to be applied.)

    thanks all,  and tanks Cory for Astaro tech.

    g  
Reply
  • 0 in reply to cyclops
    it would seem the patches have fixed things.  I unplugged the ethernet to the internal mail server and things worked as expected after plugging it back in.  I mistakenly thought it was at patch leve 015 but it was not.  (I thought what I seen was a list of applied patches,  not patches waiting to be applied.)

    thanks all,  and tanks Cory for Astaro tech.

    g  
Children
No Data