I'm very sorry it's taken me so long to get back to you about this!
If you're willing to edit the code, I suggest changing spamdyke.c. Change line
1615 (the first line of an if statement) to this:
if (
And change line 1644 (the call to filter_dns_rbl()) to this:
if (filter_dns_rbl(current_settings,
¤t_settings->current_options->filter_action,
¤t_settings->current_options->filter_action_locked,
¤t_settings->current_options->rejection,
¤t_settings->current_options->rejection_buf,
current_settings->current_options->reject_message_buf, MAX_BUF,
current_settings->current_options->reject_reason_buf, MAX_BUF) ==
FILTER_DECISION_DO_FILTER) return_value = FILTER_FLAG_QUIT;
And change line 1668 (setting return_value) to this:
return_value = (return_value != FILTER_FLAG_QUIT) ?
FILTER_FLAG_INTERCEPT : FILTER_FLAG_QUIT;
And change line 3400 (an if statement) to this:
if (0)
Then recompile with "make" and install the new spamdyke binary.
With those changes on lines 1615 and 3400, spamdyke will wait until the client
sends the recipient addresses to check its filters (including DNS RBLs), the
same way it does when a configuration directory is given. However, the changes
on lines 1644 and 1668 will make it quit when an RBL is matched, the same way
it does when the client sends "QUIT", even if a sender or recipient whitelist
is matched. All other rejections should behave normally.
Caveat emptor: I haven't tested these suggestions or even attempted to compile
them. Good luck!
-- Sam Clippinger
On Mar 24, 2017, at 10:19 AM, Alessio Cecchi via spamdyke-users
<spamdyke-users@spamdyke.org> wrote:
> Thanks Sam for your answer,
>
> anyway it is crucial for us to avoid letting the timeout expire after "RCTP
> TO" message in case of RBL check. So, even developing a custom patch, we need
> something to prevent clients keeping the connection open after "554 Refused.
> Your IP address is listed in the RBL at..." message.
>
> We tried adding a simple exit(0) around line 1695 of filter.c just to test
> the behavior but doing that the client is not able to connect anymore.
>
> Can you suggest a (even dirty) way to workaround it or point me to the proper
> direction to investigate it further?
>
> This is an extract of the handshake message at the end of which we need to
> close the communication
>
> 220 popmx-staging.cloud.net ESMTP
> helo example.com
> 250 popmx-staging.cloud.net
> MAIL FROM: exam...@example.com
> 250 Refused. Your IP address is listed in the RBL at cidr.bl
> RCPT TO: t...@test.com
> 554 Refused. Your IP address is listed in the RBL at cidr.bl
>
> <---- we need to close the connection in this moment (when we receive 554
> Refused) instead of waiting for DATA and then waiting the default timeout.
>
> Thanks for your time.
>
> Alessio Cecchi
>
> Il 19/03/2017 20:05, Sam Clippinger via spamdyke-users ha scritto:
>> Unfortunately no, spamdyke isn't designed with the idea of different
>> timeouts for different reasons. It will always keep the connection open as
>> long as there is any chance the message could be allowed. For example, if
>> your configuration includes a recipient whitelist and the remote IP is
>> blacklisted, spamdyke won't close the connection until the recipients are
>> given, just in case one of them is on the whitelist. Even when it's no
>> longer possible to match a whitelist, spamdyke still won't close the
>> connection because the remote client could sent a RSET command and begin a
>> new session.
>>
>> Your only option is to set a lower idle timeout, anything else would require
>> a major refactoring of spamdyke's code. Sorry!
>>
>> -- Sam Clippinger
>>
>>
>>
>>
>> On Mar 10, 2017, at 4:11 AM, Alessio Cecchi via spamdyke-users
>> <spamdyke-users@spamdyke.org> wrote:
>>
>>> Hi,
>>>
>>> some months ago we switch from rblsmtpd to spamdyke in order to have more
>>> info in the log about blocked IP. But after switch to spamdyke the number
>>> of concurrency incoming SMTP sessions was increased about 10 time.
>>>
>>> This because with rblsmtpd we set a timeout of 10 seconds and spamdyke have
>>> a global timeout that we set at 180 seconds (idle-timeout-secs). So when an
>>> IP in blacklist connects to our MX it grabs a qmail-smtpd process for 180
>>> seconds instead of 10.
>>>
>>> Increasing the number of /var/qmail/control/concurrencyincoming is not a
>>> solution because we expose our cluster to receive a number of sessions that
>>> we could be unable to manage.
>>>
>>> Can spamdyke close a connections with IP in blacklist after a time shorter
>>> than idle-timeout-secs?
>>>
>>> Here an example of timeout:
>>>
>>> with spamdyke
>>>
>>> $ time telnet mx01.mail.net 25
>>> Trying 192.168.1.135...
>>> Connected to mx01.mail.net.
>>> Escape character is '^]'.
>>> 220 mx01.mail.net ESMTP
>>> helo ciao.com
>>> 250 mx01.mail.net
>>> MAIL FROM: ales...@ciao.it
>>> 250 Refused. Your IP address is listed in the RBL at www.spamhaus.org:
>>> http://www.spamhaus.org/query/bl?ip=19.9.131.86
>>> RCPT TO: ales...@ciao.com
>>> 554 Refused. Your IP address is listed in the RBL at www.spamhaus.org:
>>> http://www.spamhaus.org/query/bl?ip=19.9.131.86
>>>
>>> [ here we should close the connection ]
>>>
>>> DATA
>>> 554 Refused. Your IP address is listed in the RBL at www.spamhaus.org:
>>> http://www.spamhaus.org/query/bl?ip=19.9.131.86
>>> 421 Timeout. Talk faster next time.
>>> Connection closed by foreign host.
>>>
>>> real 3m46.105s
>>> user 0m0.000s
>>> sys 0m0.000s
>>>
>>> with rblsmtpd:
>>>
>>> $ time telnet mx01.mail.net 25
>>> Trying 192.168.1.135...
>>> Connected to mx01.mail.net.
>>> Escape character is '^]'.
>>> 220 rblsmtpd.local
>>> Connection closed by foreign host.
>>>
>>> real 0m10.389s
>>> user 0m0.000s
>>> sys 0m0.000s
>>>
>>> Thanks
>>>
>>> --
>>> Alessio Cecchi
>>> Postmaster @ http://www.qboxmail.it
>>> https://www.linkedin.com/in/alessice
>>>
>>> _______________________________________________
>>> spamdyke-users mailing list
>>> spamdyke-users@spamdyke.org
>>> http://www.spamdyke.org/mailman/listinfo/spamdyke-users
>>
>>
>>
>> _______________________________________________
>> spamdyke-users mailing list
>> spamdyke-users@spamdyke.org
>> http://www.spamdyke.org/mailman/listinfo/spamdyke-users
>
> --
> Alessio Cecchi
> Postmaster @ http://www.qboxmail.it
> https://www.linkedin.com/in/alessice
> _______________________________________________
> spamdyke-users mailing list
> spamdyke-users@spamdyke.org
> http://www.spamdyke.org/mailman/listinfo/spamdyke-users
_______________________________________________
spamdyke-users mailing list
spamdyke-users@spamdyke.org
http://www.spamdyke.org/mailman/listinfo/spamdyke-users
