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

5.016 - SMTP Recipient Verification Broken

Hello,
     It appears as if recipient verification is broken in 5.016. After an up2date to the latest version, we cannot receive inbound mail using SMTP Routes and Recipient Verification.

Here is an example w/ SMTP Verification Turned Off:

Connected to mail.jamesoswald.com.
Escape character is '^]'.
220 mail.jamesoswald.com ESMTP ready.
helo nacs.net
250 mail.jamesoswald.com Hello nacs.net [207.166.192.10]
mail from: damin@nacs.net
250 OK
rcpt to: user@jamesoswald.com
250 Accepted

Here is an example w/ SMTP Verification Turned On:

Connected to mail.jamesoswald.com
Escape character is '^]'.
220 mail.jamesoswald.com ESMTP ready.
helo nacs.net
250 mail.jamesoswald.com Hello nacs.net [207.166.192.10]
mail from: damin@nacs.net
250 OK
rcpt to: user@jamesoswald.com
550 unrouteable address

I have tried doing a tcpdump on the Astaro box to see if it is even contacting the internal mail server (192.168.1.89) for the Recipient Verification, and it is not!

Any suggestions?


This thread was automatically locked due to age.
Parents Reply Children
  • [ QUOTE ]
    Can't confirm this. Please turn on Rcpt verification again and then post /var/chroot-smtp/etc/exim.conf (In a private message if you like [:)] ) 

    [/ QUOTE ]

    I'll be happy to post the file, but the answer that you are looking for is: "Yes, the Middleware correctly adds the RCPT verification stanzas the Exim configuration". [;)]

    The relavant portion from the default conf:
      # recipient verification for our domains
      deny  domains = +relay_to_domains
            !verify = recipient/callout/defer_ok/callout_defer_ok
            message = unrouteable address

    When receipt verification is turned on exim.conf contains:
      # recipient verification for our domains
      deny  domains = +relay_to_domains
            !verify = recipient/callout/defer_ok/callout_defer_ok
            message = unrouteable address

    So I'm stumped..
  • Does your internal mail server reject bounces (MAIL FROM:<>)?

    On the ASL, first do "dev-install.sh" (to get the telnet binary), then try telnetting to your internal mail server port 25, and try this sequence:

    Code:

    HELO 
    MAIL FROM:<>
    RCPT TO:
    QUIT



    See what happens [:)]

    /tom