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

suspend mail delivery

How can I configure my astaro or rather exim to suspend mail delivery (still accept but not forward them)?
Im planing a big internal mail upgrade, so exim should not be able to send any mails to my internal mta's.
And just shutdown the internal mta is probably not enaugh, could be that during the upgrade it will come up again for testing and more and then astaro would forward all queued mails... but this should not happen..[8-)].

Thanks


This thread was automatically locked due to age.
Parents
  • I just did a quick test in my lab.

    1. In Webadmin I've changed the IP address of internal mail server object to a fake one (from 192.168.1.1 to 192.168.1.111). All incoming messages after that went to spool (scrshot).
    2. Changed back the IP address to the original one, selected all messages from the spool and choosed Retry action. All successfully delivered.

    As far as I know default UTM SMTP retry timeout is 48h. 

    BTW, there is also an open feature request for reducing or increasing  SMTP relay Retry Timeout option (I myself gave 3 votes for it):
    Mail Protection: Configurable SMTP Retry Timeout
Reply
  • I just did a quick test in my lab.

    1. In Webadmin I've changed the IP address of internal mail server object to a fake one (from 192.168.1.1 to 192.168.1.111). All incoming messages after that went to spool (scrshot).
    2. Changed back the IP address to the original one, selected all messages from the spool and choosed Retry action. All successfully delivered.

    As far as I know default UTM SMTP retry timeout is 48h. 

    BTW, there is also an open feature request for reducing or increasing  SMTP relay Retry Timeout option (I myself gave 3 votes for it):
    Mail Protection: Configurable SMTP Retry Timeout
Children
  • I just did a quick test in my lab.

    1. In Webadmin I've changed the IP address of internal mail server object to a fake one (from 192.168.1.1 to 192.168.1.111). All incoming messages after that went to spool (scrshot).
    2. Changed back the IP address to the original one, selected all messages from the spool and choosed Retry action. All successfully delivered.

    Yeah, sounds good. Thanks.