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

[9.105-9] Callout does not work as expected

I can't tell exactly when this odd behaviour started, but I am pretty sure that callout was ok with 9.605.
Since early V7 I have a separate mail server configured as the target for the static host list and the ASG used this mail server for callouts, too. This mail server knows all our valid mail addresses and gives a "421 - recipient not in route list" back to the ASG, if the receiver is not on the list. In this case the mail, obviously for a non-existant mail address, was denied at SMTP time.

Now with 9.105-9 this mail server still delivers the 421 message back to the UTM in case the receiver is not on the list. But mails for non-existant receivers are not denied anymore, they will be accepted by UTM and are stored in the SMTP spool. The UTM tries to deliver such mails again and again, every 2 or 3 minutes and for days. 

WTF??? What is the reason for changing this behaviour and how can I change the config to get back the old (And correct) way? 
I want the UTM to deny mails for non-existant receivers and not to store them in the SMTP spool. 

PS: Switching to AD mode is not an option.


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

    People are talking about that since 9.1 was introduced , I am not sure the exact Ver , but it is not related to 9.105-9.
    Look in the forum and you will find that some already talked about that.
    There is no good or bad news about that , only that it acts like that.
    I accept that it is not a normal behavior and should be checked .
    I will try to ask the support to check on that tomorrow .
    If I will have news I will inform here.

    All my best.
    Gilipeled

    Gil Peled.

    CEO- Expert2IT LTD.

    SOPHOS Platinum Partner.

    Gil@expert2it.co.Il.

Reply
  • Hi ,

    People are talking about that since 9.1 was introduced , I am not sure the exact Ver , but it is not related to 9.105-9.
    Look in the forum and you will find that some already talked about that.
    There is no good or bad news about that , only that it acts like that.
    I accept that it is not a normal behavior and should be checked .
    I will try to ask the support to check on that tomorrow .
    If I will have news I will inform here.

    All my best.
    Gilipeled

    Gil Peled.

    CEO- Expert2IT LTD.

    SOPHOS Platinum Partner.

    Gil@expert2it.co.Il.

Children
  • Thanks for answering, Gilipeled.
    I've seen some threads about callout, but IMHO they had different focuses. In general, callout is nearly useless since 9.1x if the UTM accepts mails for non-existant recipients instead of rejecting them.
    Now I have a SMTP spool folder full of useless mails. If I know the sender I can bounce the mails. Unnecessary manual work. Most of them are spam mails from non-existant sender addresses which populate the folder and they need to be deleted.

    I am awaiting your response...
  • Hi,

    your backend mailserver must reply with a 5xx error not an 4xx error.

    When you answer with an 4xx error, this means there is a temporary error and it might be fixed. (it is a soft bounce).

    You must answer the question about the mailbox with an 5xx error, than astaro an every other mailserver knows the mailbox is not available.

    Sven

    Astaro user since 2001 - Astaro/Sophos Partner since 2008

  • Hi,
    your backend mailserver must reply with a 5xx error not an 4xx error.
    When you answer with an 4xx error, this means there is a temporary error and it might be fixed. (it is a soft bounce).
    You must answer the question about the mailbox with an 5xx error, than astaro an every other mailserver knows the mailbox is not available.

    This answer hits the nail on the head. Of course the response "421 - recipient not in route list" is syntactically wrong, a leading 550 would be correct. I did not realize this error before Sven's answer pushed me on the the right way. Thank you!
    This error is a confirmed bug in the mailservers software and exists since I've updated it right at the same time when UTM was updated to 9.1xx. 

    Sorry for this way too fast shoot from the hip, my apologies. I've just reverted the mailservers version to the version before and now everything works as expected.