[vchkpw] Why not disconnect after rejection/limit ?
Hi, I'm trying to fine tune my mail system, and looking at how qmail-smtpd/vchkpw handle rejected mail i started thinking; why qmail-smtp doesn't disconnect after the intrusion threshold? it keeps rejecting messages (from the spammer normally) and eating cpu and band whit. Perhaps there is a good reason to don't disconnect but i think it could be a nice feature too. any opinion about this? Ion
[vchkpw] qmailadmin 1.2.10 vpopmail 5.4.15 segfaults on forwards page
I've spent the past few days working on this problem for a good 8 hours a day, so figure I'll send it back to the list for some insight.This is using no valias code, so it should be using vpalias.c. I'm using standard qmail aliases.I'm getting qmailadmin segfaulting when handling forwards, most obviously is viewing the forward list even. My debugging has taken me to the final call to 'alias_line = valias_select_all_next(alias_name);' when alias_name is the final alias in the set, or when the set is empty (no aliases at all).If I make it stop running (through code hacks) valias_select_all_next one short of the number of aliases, all works well with no problems no matter what I do in qmailadmin. However, when it continues, it tends to continue but corrupt other areas, such as segfaulting on a fclose() in send_template_now() mainly. There seems to be some sort of overrun going on here but I can't seem to find it to my displeasure.Is anyone else seeing these issues? Any ideas on a solution? I'm looking to vpalias.c for solutions and have been fiddling with that code as well with no real success, as everything seems alright.qmailadmin 1.2.10 : '--enable-htmldir=/var/www' '--enable-cgibindir=/var/www/cgi-bin' '--enable-help' '--enable-cgipath=/cgi-bin/qmailadmin' '--enable-domain-autofill'\"vpopmail 5.4.15 : '--enable-qmail-ext' '--enable-auth-module=cdb' '--enable-logging=y'Debian 3.1Thanks in advance folks,-M
Re: [vchkpw] Why not disconnect after rejection/limit ?
On 3/3/2006 10:28 AM, Michael Krieger wrote: An SMTP server MUST NOT intentionally close the connection except: - After receiving a QUIT command and responding with a 221 reply. - After detecting the need to shut down the SMTP service and returning a 421 response code. This response code can be issued after the server receives any command or, if necessary, asynchronously from command receipt (on the assumption that the client will receive it after the next command is issued). Not to turn this into a RFC contest on the wrong mailing list, but we must be interpreting that differently -- my qmail-1.03.isp.patch will close a connection after a defined number of errors. I claim RFC 2821 #3.9 compatibility, because before closing the connection, I send a 400 error. I have the 'need' to close the connection, because I no longer want to hear from this abuser, and he is automatically entered into tcp.smtp.cdb for rejection. -- Jeremy Kister http://jeremy.kister.net./
Re: [vchkpw] Why not disconnect after rejection/limit ?
Jeremy Kister wrote: On 3/3/2006 10:28 AM, Michael Krieger wrote: An SMTP server MUST NOT intentionally close the connection except: - After receiving a QUIT command and responding with a 221 reply. - After detecting the need to shut down the SMTP service and returning a 421 response code. This response code can be issued after the server receives any command or, if necessary, asynchronously from command receipt (on the assumption that the client will receive it after the next command is issued). Not to turn this into a RFC contest on the wrong mailing list, but we must be interpreting that differently -- my qmail-1.03.isp.patch will close a connection after a defined number of errors. I claim RFC 2821 #3.9 compatibility, because before closing the connection, I send a 400 error. I have the 'need' to close the connection, because I no longer want to hear from this abuser, and he is automatically entered into tcp.smtp.cdb for rejection. Just my 0.02c: I have been doing this for months with custom patches... I generally stop dictionary attacks this way, as well as some folks who send me a GET / HTTP 1.(0|1) request on port 25. -- Jorge Valdes Intercom El Salvador [EMAIL PROTECTED] voz: ++(503) 2278-5068 fax: ++(503) 2265-7025
