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 Callouts

It may just be me (highly likely) but I am having a bit of an issue setting up the SMTP Proxy correctly (running ASL 4.015).
I have had the Sender Address Verification enabled for some time now with no issues. I am however now getting some SPAM on one of my main mail accounts which is a bit of a problem. I decided to enable the Callouts option in the proxy but this has caused yet another issue.
If I try to send a message to my mail server using my WebMail account (from my ISP), something I need to do when I am traveling, it gets rejected at the firewall with the following message:

2003-Nov  8 18:20:52 firewall exim[16450]: 2003-11-08 18:20:52 H=(mail.xxx.net.au) [203.x.x.x] F= rejected RCPT : Sender verify failed

The Astaro help states that a RCPT command is issued to the senders SMTP server to see if the senders address is valid. Well, it is, but it gets rejected.

Does someone know exactly what commands are sent as part of this Callout verification as I can telnet to the SMTP address that is given in the error message and connect. It’s all a bit confusing.
I would like to use this feature but if it disables my ability to use my WebMail, which it does at this time, I cannot.

Can someone shed a little light on this subject for me?

Thanks in advance.
  


This thread was automatically locked due to age.
Parents
  • Sender Address Verification is basicly done in two steps.

    First:
    mail domain identification by inquireing DNS server about mail server address for the domain (MX).

    Second (the callout part):
    SMTP connection to identified MX to verify that a useraccount with the claimed mailaddress exists. Ie. simulate a NULL return path message to "user@domain.net.au" without a body.
    Code:
      
    
    > 220 remote.mx.com -- ESMTP Sendmail AIX4.3/8.9.3/8.9.0
     250 remote.mx.com OK, [0.0.0.0].
    <>
    > 250 2.1.0 <>... Sender ok

    > 550 2.1.5 user@domain.net.au... User unknown

     

    If a non-"250" result code is returned for the "rcpt to:" statement:

    471 error code = temporary fail
    550 error code = rejected (the proxy will not accept mail from this address)
    250 result code = ok (proxy will accept mail from this address)

    I guess next step would be to analyse the mailheader in the mails sent from your webmail (if you are able to send any mail) to se if something is wrong here or if you have to dig any deeper in you ASL box.

    ... good luck!
  • Thanks for the information.
    I will try this and see what happens. 
  • The callout function works well in rejecting messages I know are spam/relays however I am also having rejections from sites/users I know are not spam or relays [the Astaro online shop for example! :-(  ]
    Seeing as how the callout function would seem to cause as many problems as it solves, I refer to other posts on this issue, can someone enlighten me on the order in which each part of the SMTP proxy function operates.
    For example, if I created a whitelist entry for a user/site that is being rejected by the callout RCPT function, will it be received at my mail server or does the sender address verification take precedence?
    Knowing these things might make the non receipt of spam/relayed messages a little closer to reality.
    Thanks,
  • Have you figured out what part in the sender verification that fails? Is it the MX lookup or the Callout? Or both?

    Is the DNS proxy enabled? if not enable it and do some more testing.  
  • The Big O,

    it seems to be a problem to exclude single e-mail addresses from user verification and content checking but with the global whitelist you are able to set certain domains as trusted domains.

    the online help states:

    [ QUOTE ]
    :: Global Whitelist ::

    The global whitelist settings allow you to add "trusted" hosts (or networks) and sender domains. Hosts and domains in these lists will not be able to relay on the firewall, but they are not subject to the following mechanisms:

        * Realtime Blackhole lists
        * Sender verification
        * MIME error checking
        * Spam detection
        * Expression filter

    The global whitelist can be used for the following purposes:

        * Lower the content scanning load on the firewall, if you trust hosts that trade large volumes of mail with your site.
        * Exempt "problem" hosts from content scanning.

    You should use the "Trusted domains" option with caution, since sender addresses can be easily faked. If possible, always use the "Trusted Hosts" option.

    [/ QUOTE ]

    Greetings
    cyclops   
Reply
  • The Big O,

    it seems to be a problem to exclude single e-mail addresses from user verification and content checking but with the global whitelist you are able to set certain domains as trusted domains.

    the online help states:

    [ QUOTE ]
    :: Global Whitelist ::

    The global whitelist settings allow you to add "trusted" hosts (or networks) and sender domains. Hosts and domains in these lists will not be able to relay on the firewall, but they are not subject to the following mechanisms:

        * Realtime Blackhole lists
        * Sender verification
        * MIME error checking
        * Spam detection
        * Expression filter

    The global whitelist can be used for the following purposes:

        * Lower the content scanning load on the firewall, if you trust hosts that trade large volumes of mail with your site.
        * Exempt "problem" hosts from content scanning.

    You should use the "Trusted domains" option with caution, since sender addresses can be easily faked. If possible, always use the "Trusted Hosts" option.

    [/ QUOTE ]

    Greetings
    cyclops   
Children
  • Sorry for the time delay in replying, been away . . .

    I have decided to turn off the Callouts feature. Too many false positives. Sad really, as I thought this was an excellent feature when I first saw it.  :-(