Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 5 replies
  • Subscribers 1 subscriber
  • Views 1965 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

5.016 - SMTP Recipient Verification Broken

Damin
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.
  • 0
    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 [:)] )
  • 0 in reply to tom_01
    [ 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..
  • 0 in reply to Damin
    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
  • 0
    From damin@nacs.net Mon Aug 30 16:21:39 2004
    Date: Mon, 30 Aug 2004 16:20:47 -0400 (EDT)
    From: Greg Boehnlein 
    To: Astaro Support US 
    Cc: support@n2net.net
    Subject: Re: Recipient Verification - Case#10479

    On Wed, 4 Aug 2004, Astaro Support US wrote:

    > 
    > Here is what I received back from the developer:
    > 
    > Yes, there is a cache, but it should expire after 2 hours for negative
    > verifications and 24 hours for positive ones.
    > 
    > You can flush it with:
    > 
    > /var/mdw/scripts/smtp stop
    > rm -rf /var/chroot-smtp/spool/db
    > /var/mdw/scripts/smtp start
    > 
    > There is also an option to disable caching completely, but try the above
    > first.
    > 
    > Give this a shot and let me know how it goes.  
    >  
    > Cory King | Support Engineer, Astaro Corp.
    > http://www.astaro.com |Tel. 250-869-0990
    > Support Portal www.astaro.com/support

    Just a followup on this.

    It worked. We applied all Up2Dates to bring the box to 5.0.21 and then 
    followed the instructions that you provided. When we re-enabled recipient 
    verification, everything was good to go.

    -- 
        Vice President of N2Net, a New Age Consulting Service, Inc. Company
             http://www.n2net.net Where everything clicks into place!
                                 KP-216-121-ST
  • 0 in reply to Damin
    I just recently had the same problem, when trying to allow an address that was previously cancelled.  The same solution worked for me, but as a suggestion maybe the ability to clear this sort of cache wherever they are used within the product should be added to the sexy user interface.