perl.qpsmtpd

perl.qpsmtpd http://www.nntp.perl.org/group/perl.qpsmtpd/ ... Copyright 1998-2008 perl.org Thu, 16 Oct 2008 19:49:18 +0000 ask@perl.org Re: trying to get config for tls_ciphers by John Peacock Jan Völkers wrote: > I'd like to communicate encrypted, but when i configure tls, qpsmtp > stops working with the line "trying to get config for tls_ciphers" in > the last logline. That may be the last log line, but it is highly unlikely that it is the last thing executed. If you turn up the logging to 11, do you see ciphers: DEFAULT as well? Are you running a known broken distro like Solaris (which doesn't provide a fully functional SSL library by default)? > I have added a file tls_ciphers with "DEFAULT" inside. No change. > I use pem files - could that be the problem? What format is preferred? $perldoc IO::Socket::SSL ... SSL_cert_file If your SSL certificate is not in the default place (certs/server-cert.pem for servers, certs/client-cert.pem for clients), then you should use this option to specify the location of your certificate. ... NOTE: you cannot have a password on your certificate/key file, because there is no way for qpsmtpd to handle that. You also need to pass the CA cert that was used to sign your certificate (since you need the full chain). Try running this: perl -MIO::Socket::SSL -e ' my $ssl_ctx = IO::Socket::SSL::SSL_Context->new( SSL_use_cert => 1, SSL_cert_file => "/path/to/cert", SSL_key_file => "/path/to/key", SSL_ca_file => "/path/to/ca", SSL_cipher_list => "HIGH", SSL_server => 1 ) or die "Could not create SSL context: $!"; ' and see what that does (which is precisely what the tls plugin does internally). HTH John http://www.nntp.perl.org/group/perl.qpsmtpd/2008/10/msg8253.html Tue, 07 Oct 2008 04:04:56 +0000 trying to get config for tls_ciphers by Jan Völkers I'd like to communicate encrypted, but when i configure tls, qpsmtp stops working with the line "trying to get config for tls_ciphers" in the last logline. I have added a file tls_ciphers with "DEFAULT" inside. No change. I use pem files - could that be the problem? What format is preferred? Any hints? Jan http://www.nntp.perl.org/group/perl.qpsmtpd/2008/10/msg8252.html Mon, 06 Oct 2008 07:31:16 +0000 [PATCH] Add support for both AUTH LOGIN and PLAIN to auth_flat_file by Pedro Melo Hi, a small patch to enable AUTH PLAIN and LOGIN in the auth_flat_file plugin. I'm using it for a small experiment and certain version of LookOut dont seem to support CRAM-MD5. Best regards, --- qpsmtpd/plugins/auth/auth_flat_file | 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/qpsmtpd/plugins/auth/auth_flat_file b/qpsmtpd/plugins/auth/auth_flat_file index 6a82342..c4f130d 100644 --- a/qpsmtpd/plugins/auth/auth_flat_file +++ b/qpsmtpd/plugins/auth/auth_flat_file @@ -36,6 +36,8 @@ sub register { my ( $self, $qp ) = @_; $self->register_hook("auth-cram-md5", "authsql"); + $self->register_hook("auth-plain", "authsql"); + $self->register_hook("auth-login", "authsql"); } sub authsql { -- 1.6.0.2.GIT http://www.nntp.perl.org/group/perl.qpsmtpd/2008/10/msg8251.html Mon, 06 Oct 2008 05:45:00 +0000 Re: [qpsmtpd] Is there an orderly restart? by John Peacock b-sub-96e3ab9a984935f@rope.net wrote: > My concern with killing all of the connections is that I have some > internal processes that (I think) will occasionally corrupt log and data > files when this happens. You may want to reconsider your design, then. If you are trying to aggregate multiple log streams into a single file using any form of locking, you are almost inevitably going to be fighting corruption. You could use something like multilog, but that only allows you to post-process the log entries (when the log file is rolled), which may not be timely enough for your needs (though of course you could make the logfile size as small as you needed it to be for granularity). One thing to consider would to be a log process outside of qpsmtpd that you can freely write to, then have your processing happen in a controlled manner in a third process. The folks I work with have released the implementation we use internally: https://labs.omniti.com/trac/jlog I'm not necessarily recommending that tool per se (as the documentation is almost non-existent at the moment), but rather as an example of the style of programming you probably need to pursue: qpsmtpd => logger <= log processor By decoupling qpsmtpd from the log processing, you can do whatever you want to qpsmtpd and the log processor still gets clean log entries to analyze. John http://www.nntp.perl.org/group/perl.qpsmtpd/2008/10/msg8250.html Thu, 02 Oct 2008 04:25:19 +0000 Re: general question about ClamAV plugin by Matt Sergeant On Tue, 30 Sep 2008 17:03:36 -0700 (PDT), cmacduff@gmail.com wrote: > When using the ClamAV plugin i realize that this is not the entire > ClamAV application but how do I then keep the virus definitions for > the plugin up to date? do I need to actually install the ClamAV > application to use freshclam to update the virus definations and then Yes. > do i need to have the ClamAV plugin point to a different spot for it > to see these newer definations? No, that's automatic. http://www.nntp.perl.org/group/perl.qpsmtpd/2008/10/msg8249.html Wed, 01 Oct 2008 06:45:04 +0000 general question about ClamAV plugin by cmacduff When using the ClamAV plugin i realize that this is not the entire ClamAV application but how do I then keep the virus definitions for the plugin up to date? do I need to actually install the ClamAV application to use freshclam to update the virus definations and then do i need to have the ClamAV plugin point to a different spot for it to see these newer definations? http://www.nntp.perl.org/group/perl.qpsmtpd/2008/10/msg8248.html Wed, 01 Oct 2008 02:13:07 +0000 Re: Latest SMTP.pm causes fatal errors by Chris Lewis Matt Sergeant wrote: > On Tue, 30 Sep 2008 08:34:05 +0200, Hanno Hecker wrote: >>> I'm confused why the error is caused - anyone better with perl than me >>> can help out? >> Same confusion here... and I cannot reproduce it. >> $ perl -v | grep 'This is perl' >> This is perl, v5.8.8 built for i486-linux-gnu-thread-multi >> >> Running -async works without a problem, with and without (start)tls. > > Same here. Chris can you reduce it to a couple of plugins and let us > know the setup required to reproduce? I have got the TLS plugin enabled. This is perl, v5.8.8 built for sun4-solaris I'll ge around to plugin reduction. http://www.nntp.perl.org/group/perl.qpsmtpd/2008/09/msg8247.html Tue, 30 Sep 2008 07:55:47 +0000 Re: queueing based on rcpt to: address by Jörg C . Meyer I implemented it as suggested by Hanno and it works like a charm. And since this mail switching qpsmtpd instance is feed by a qmail process there can't be more than one recipient in a transaction, so we don't have a problem if one of the destination MTAs fails. Jörg > On Mon, 29 Sep 2008 14:51:08 +0200 (CEST) > Jörg C. Meyer <joerg@meyer.homedns.org> wrote: >> I want to queue mails via SMTP to different SMTP servers based on the >> rcpt >> to: address. The goal is to route different parts of an email domain to >> different servers in a mail server migration szenario. >> >> How should I implement this? I thought about hacking the "smtp-forward" >> plugin. > Why not wrap this plugin's hook_queue and return DECLINED if the > destination is not for this instance... and then load the wrapper > multiple times with different arguments, see docs/plugins.pod. > > Hanno > http://www.nntp.perl.org/group/perl.qpsmtpd/2008/09/msg8246.html Tue, 30 Sep 2008 07:46:08 +0000 Re: Latest SMTP.pm causes fatal errors by Matt Sergeant On Tue, 30 Sep 2008 08:34:05 +0200, Hanno Hecker wrote: >> I'm confused why the error is caused - anyone better with perl than me >> can help out? > Same confusion here... and I cannot reproduce it. > $ perl -v | grep 'This is perl' > This is perl, v5.8.8 built for i486-linux-gnu-thread-multi > > Running -async works without a problem, with and without (start)tls. Same here. Chris can you reduce it to a couple of plugins and let us know the setup required to reproduce? http://www.nntp.perl.org/group/perl.qpsmtpd/2008/09/msg8245.html Tue, 30 Sep 2008 05:55:29 +0000 Re: DNSBL and answer id check missing by Peter J. Holzer On 2008-09-30 01:30:44 -0700, Ask Bjørn Hansen wrote: > How about making qpsmtpd require Net::DNS 0.60 then? I've built in a work-around for the problem in older releases of Net::DNS. But I'm not sure if that still works - from a casual glance at the source I'd say no, and I'm not sure how it could ever have worked. Maybe the dnsbl plugin didn't use async at the time? hp -- _ | Peter J. Holzer | Openmoko has already embedded |_|_) | Sysadmin WSR | voting system. | | | hjp@hjp.at | Named "If you want it -- write it" __/ | http://www.hjp.at/ | -- Ilja O. on community@lists.openmoko.org http://www.nntp.perl.org/group/perl.qpsmtpd/2008/09/msg8244.html Tue, 30 Sep 2008 05:31:22 +0000 Re: DNSBL and answer id check missing by Ask Bjørn Hansen How about making qpsmtpd require Net::DNS 0.60 then? - ask http://www.nntp.perl.org/group/perl.qpsmtpd/2008/09/msg8243.html Tue, 30 Sep 2008 01:30:56 +0000 Re: Latest SMTP.pm causes fatal errors by Hanno Hecker On Mon, 29 Sep 2008 23:24:41 -0400 Matt Sergeant <matt@sergeant.org> wrote: > On Mon, 29 Sep 2008 21:20:02 -0400, Chris Lewis wrote: > > Running SVN head on Solaris 8 & 9, synchronized today. > > > > qpsmtpd-async > > > > FATAL PLUGIN ERROR: Can't coerce array into hash at > > /opt/NTM/lib/perl5/site_perl/5.8.8/Qpsmtpd/SMTP. > > pm line 132 during global destruction. Mhh, this is the "return" line of transaction(): sub transaction { my $self = shift; return $self->{_transaction} || $self->reset_transaction(); } Are you running any plugins hooking "reset_transaction"? > > Causes incomplete processing of _all_ email. > > > > When I take out this line (latest change to SMTP.pm), the problem goes > > away (line 40) > > > > $self->SUPER::_restart(%args) if $args{restart}; # calls > > Qpsmtpd::_restart() > > I'm confused why the error is caused - anyone better with perl than me > can help out? Same confusion here... and I cannot reproduce it. $ perl -v | grep 'This is perl' This is perl, v5.8.8 built for i486-linux-gnu-thread-multi Running -async works without a problem, with and without (start)tls. Hanno http://www.nntp.perl.org/group/perl.qpsmtpd/2008/09/msg8242.html Mon, 29 Sep 2008 23:33:42 +0000 Re: Latest SMTP.pm causes fatal errors by Matt Sergeant On Mon, 29 Sep 2008 21:20:02 -0400, Chris Lewis wrote: > Running SVN head on Solaris 8 & 9, synchronized today. > > qpsmtpd-async > > FATAL PLUGIN ERROR: Can't coerce array into hash at > /opt/NTM/lib/perl5/site_perl/5.8.8/Qpsmtpd/SMTP. > pm line 132 during global destruction. > > Causes incomplete processing of _all_ email. > > When I take out this line (latest change to SMTP.pm), the problem goes > away (line 40) > > $self->SUPER::_restart(%args) if $args{restart}; # calls > Qpsmtpd::_restart() I'm confused why the error is caused - anyone better with perl than me can help out? > I note that the > > $self->log(LOGCRIT, "from email address : [$from]"); > > and > > $self->log(LOGCRIT, "to email address : [$rcpt]"); > > Haven't been changed to LOGDEBUG yet. Pretty please? Yeah - a long time irritation. Changed in SVN now. Matt. http://www.nntp.perl.org/group/perl.qpsmtpd/2008/09/msg8241.html Mon, 29 Sep 2008 20:25:09 +0000 Latest SMTP.pm causes fatal errors by Chris Lewis Running SVN head on Solaris 8 & 9, synchronized today. qpsmtpd-async FATAL PLUGIN ERROR: Can't coerce array into hash at /opt/NTM/lib/perl5/site_perl/5.8.8/Qpsmtpd/SMTP. pm line 132 during global destruction. Causes incomplete processing of _all_ email. When I take out this line (latest change to SMTP.pm), the problem goes away (line 40) $self->SUPER::_restart(%args) if $args{restart}; # calls Qpsmtpd::_restart() I note that the $self->log(LOGCRIT, "from email address : [$from]"); and $self->log(LOGCRIT, "to email address : [$rcpt]"); Haven't been changed to LOGDEBUG yet. Pretty please? http://www.nntp.perl.org/group/perl.qpsmtpd/2008/09/msg8240.html Mon, 29 Sep 2008 18:20:38 +0000 Re: $transaction->body_filename; by Matt Sergeant On Mon, 29 Sep 2008, Chris Lewis wrote: > Matt told me that the body_filename not showing headers is actually an > idiosyncracy of qpsmtpd-async, and behaves more like one would expect > under qpsmtpd-forkserver etc. and that he had fixed that. > > Is that in SVN yet? Yes. http://www.nntp.perl.org/group/perl.qpsmtpd/2008/09/msg8239.html Mon, 29 Sep 2008 12:13:03 +0000 Re: $transaction->body_filename; by Chris Lewis Matt told me that the body_filename not showing headers is actually an idiosyncracy of qpsmtpd-async, and behaves more like one would expect under qpsmtpd-forkserver etc. and that he had fixed that. Is that in SVN yet? http://www.nntp.perl.org/group/perl.qpsmtpd/2008/09/msg8238.html Mon, 29 Sep 2008 10:53:07 +0000 Re: DNSBL and answer id check missing by Chris Lewis Charlie Brady wrote: > > On Sun, 28 Sep 2008, Ask Bj�rn Hansen wrote: > >> On Sep 28, 2008, at 12:01 AM, Diego d'Ambra wrote: >> >>> my $res = new Net::DNS::Resolver; >>> $res->tcp_timeout(30); >>> $res->udp_timeout(30); >>> $res->srcport(1024+int(rand(64511))); >> >> Shouldn't this fix be in Net::DNS::Resolver? > > http://search.cpan.org/src/OLAF/Net-DNS-0.63/Changes > > Apparently some hjp caused that to be so in June 2007. In 0.60 actually: Fix rt 23961 Randomized the ID on the queries. Thanks to "hjp" for reporting and suggesting a fix. The randomization of the src port is supposed to be handled by the setting the source port to "0" (default). Overriding the default or using persistent sockets may be problematic. Also see: http://www.potaroo.net/ietf/idref/draft-hubert-dns-anti-spoofing/ http://www.nntp.perl.org/group/perl.qpsmtpd/2008/09/msg8237.html Mon, 29 Sep 2008 10:52:22 +0000 Re: queueing based on rcpt to: address by Hanno Hecker On Mon, 29 Sep 2008 14:51:08 +0200 (CEST) Jörg C. Meyer <joerg@meyer.homedns.org> wrote: > I want to queue mails via SMTP to different SMTP servers based on the rcpt > to: address. The goal is to route different parts of an email domain to > different servers in a mail server migration szenario. > > How should I implement this? I thought about hacking the "smtp-forward" > plugin. Why not wrap this plugin's hook_queue and return DECLINED if the destination is not for this instance... and then load the wrapper multiple times with different arguments, see docs/plugins.pod. Hanno http://www.nntp.perl.org/group/perl.qpsmtpd/2008/09/msg8236.html Mon, 29 Sep 2008 10:29:37 +0000 Re: DNSBL and answer id check missing by Charlie Brady On Mon, 29 Sep 2008, Charlie Brady wrote: > > On Sun, 28 Sep 2008, Ask Bjørn Hansen wrote: > >> On Sep 28, 2008, at 12:01 AM, Diego d'Ambra wrote: >> >> > my $res = new Net::DNS::Resolver; >> > $res->tcp_timeout(30); >> > $res->udp_timeout(30); >> > $res->srcport(1024+int(rand(64511))); >> >> Shouldn't this fix be in Net::DNS::Resolver? > > http://search.cpan.org/src/OLAF/Net-DNS-0.63/Changes > > Apparently some hjp caused that to be so in June 2007. And from http://rt.cpan.org/Public/Bug/Display.html?id=23961: Patch made it into release 0.60 http://www.nntp.perl.org/group/perl.qpsmtpd/2008/09/msg8235.html Mon, 29 Sep 2008 08:55:42 +0000 Re: DNSBL and answer id check missing by Charlie Brady On Sun, 28 Sep 2008, Ask Bjørn Hansen wrote: > On Sep 28, 2008, at 12:01 AM, Diego d'Ambra wrote: > >> my $res = new Net::DNS::Resolver; >> $res->tcp_timeout(30); >> $res->udp_timeout(30); >> $res->srcport(1024+int(rand(64511))); > > Shouldn't this fix be in Net::DNS::Resolver? http://search.cpan.org/src/OLAF/Net-DNS-0.63/Changes Apparently some hjp caused that to be so in June 2007. http://www.nntp.perl.org/group/perl.qpsmtpd/2008/09/msg8234.html Mon, 29 Sep 2008 08:54:02 +0000 Re: queueing based on rcpt to: address by Peter Eisch On 9/29/08 7:51 AM, "Jörg C. Meyer" <joerg@meyer.homedns.org> wrote: > Hi, > > I want to queue mails via SMTP to different SMTP servers based on the rcpt > to: address. The goal is to route different parts of an email domain to > different servers in a mail server migration szenario. > > How should I implement this? I thought about hacking the "smtp-forward" > plugin. > That's a good place to start, but I offer a consideration: If you have an email that's destined for both MTAs, will you deliver it to just one and let it forward to the other server? If you deliver to both, how will you handle the case where delivery to one succeeded and the other failed. peter http://www.nntp.perl.org/group/perl.qpsmtpd/2008/09/msg8233.html Mon, 29 Sep 2008 07:12:49 +0000 queueing based on rcpt to: address by Jörg C . Meyer Hi, I want to queue mails via SMTP to different SMTP servers based on the rcpt to: address. The goal is to route different parts of an email domain to different servers in a mail server migration szenario. How should I implement this? I thought about hacking the "smtp-forward" plugin. Kind regards, Jörg http://www.nntp.perl.org/group/perl.qpsmtpd/2008/09/msg8232.html Mon, 29 Sep 2008 05:51:32 +0000 Re: Spamassasin and relay client by Radu Greab > First of all, the isa_plugin method is available is the debian > version. But there is a problem with loading path. I get the following : > > could not open plugins/spamassassin: No such file or directory at > /usr/share/perl5/Qpsmtpd/Plugin.pm line 121. > [...] > > my plugin_dir file indicate the two previous place > > But the isa_plugin() method and compile() method does not load the > correct file. If you could upgrade, qpsmtpd 0.43 would fix that problem. http://www.nntp.perl.org/group/perl.qpsmtpd/2008/09/msg8231.html Mon, 29 Sep 2008 03:24:39 +0000 Re: Spamassasin and relay client by julien Hello, First of all, the isa_plugin method is available is the debian version. But there is a problem with loading path. I get the following : could not open plugins/spamassassin: No such file or directory at /usr/share/perl5/Qpsmtpd/Plugin.pm line 121. I put the wrapper plugin in : /usr/local/share/qpsmtpd/plugins/ and /usr/share/qpsmtpd/plugins/ my plugin_dir file indicate the two previous place But the isa_plugin() method and compile() method does not load the correct file. In the isa_plugin() method I replace the call to compile by adding the complete path ----- 0.32-6 version ---- $self->compile($self->plugin_name . "_isa_$cleanParent", $newPackage, "plugins/$parent"); # assumes Cwd is qpsmtpd root warn "---- $newPackage\n"; --- modified version ------- $self->compile($self->plugin_name . "_isa_$cleanParent", $newPackage, "/usr/share/qpsmtpd/plugins/$parent"); warn "---- $newPackage\n"; It works ! but if I want to write a wrapper for a "local" plugins in /usr/local/share/qpsmtpd/plugins I need to change the path in /usr/share/perl5/Qpsmtpd/Plugin.pm Is it possible to modify the Plugin.pm in order to search the "parent" plugin in directory listing in /etc/qpsmtpd/plugin_dir like : $dirs = file_contents("/etc/qpsmtpd/plugin_dir"); foreach($dirs as $dir){ if(file_exists($dir.$parent)){ $self->compile(...., $dir.$parent); break; } } I known it is not a perl code but I have just a little experience in this language. Julien. Quoting julien@nura.eu: > Thanks for your reply ! > > I'm using the etch version 0.32-6. I have been using the 0.40 version > before (on some server). I recently install debian version (on other > server) for the simplicity of installation. > > So I write my own wrapper plugin called "sa_norelay" with the > following code : > -------------------- > sub init { > my ($self, $qp, @args) = @_; > $self->isa_plugin("spamassassin"); > } > > sub hook_data_post { > my ($self, $transaction) = @_; > return DECLINED if $self->qp->connection->relay_client; > return $self->SUPER::hook_data_post($transaction); > } > ------------------ > Then I replace the spamassin call in config/plugins file by sa_norelay, > and switch to the 0.40 version or newer. > > Am I right ? > > It is more elegant to leave the spam plugins unchange ! > > Thanks you Hanno ! and thanks to qpsmtpd developper and contributor ! > > Julien > > > > > > Quoting Hanno Hecker <vetinari@ankh-morp.org>: > >> Hi Julien, >> >> On Fri, 26 Sep 2008 12:00:36 +0200 >> julien@nura.eu wrote: >>> I'd like to disable spamassassin check for mail coming from relay >>> clients. Is there a way to do that with the config file >>> /etc/qpsmtpd/plugins without modifying the plugin code ? >> Not with a/the config file, but with a simple wrapper plugin. >> >>> So far, I added the following lines to the spamassasin plugin >>> code in the hook_data_post function : >>> >>> # no spam check for relay client >>> if ( $self->qp->connection->relay_client ) { >>> $self->log(LOGDEBUG,"No spam check from relay client"); >>> return (OK); >>> } >> You should return DECLINED here, else no other plugin will be run (like >> a virus checker). >> >> [...] >>> The code is working. But is there a more elegant way to do that? >> [...] >>> I am using the debian relase of qpsmtpd. >> Hmm... etch or lenny/sid? I'm not sure when the "isa_plugin" was added, >> but the etch version is too old for that. For lenny this may work as >> "sa_norelay" plugin. Not sure, I've never used the debian packages, just >> SVN checkouts (even if all my systems are debian :)) >> Use this instead of "spamassassin" in the config file. Arguments and >> usage is the same as the original spamassassin plugin. >> -------------------- >> sub init { >> my ($self, $qp, @args) = @_; >> $self->isa_plugin("spamassassin"); >> } >> >> sub hook_data_post { >> my ($self, $transaction) = @_; >> return DECLINED if $self->qp->connection->relay_client; >> return $self->SUPER::hook_data_post($transaction); >> } >> ------------------ >> >> Hanno >> http://www.nntp.perl.org/group/perl.qpsmtpd/2008/09/msg8230.html Mon, 29 Sep 2008 01:35:14 +0000 Re: [qpsmtpd] Is there an orderly restart? by b-sub-96e3ab9a984935f On Sun, 28 Sep 2008, John Peacock wrote: > b-sub-96e3ab9a984935f@rope.net wrote: > > Is there a way to not accept any more connections, let the current > > connections finish, and then restart qpsmtpd? Something has to be better > > than my current heavy hammer approach. > > I use 'svc -t' instead of HUP, because it will kill all of the connections > associated with the master process. And I do it whenever I feel like it. > > The SMTP protocol was designed specifically to be very tolerant of disruptions; > all legitimate servers will happily resend an e-mail because of a snipped > connection (though at their internal retry interval). It is really not possible > to lose legitimate e-mail by randomly stopping your SMTP server to reload > plugins. On the other hand, most zombie SMTP clients can't handle anything out > of the ordinary, so that's once piece of spam you probably won't receive... Thank-you for your response. This I am aware of, and is not a problem. My concern with killing all of the connections is that I have some internal processes that (I think) will occasionally corrupt log and data files when this happens. Perl's flock() is not reliable enough (all processes accessing these files were using flock() ), and I found the most often accessed files were being corrupted very often. Many processes are after the same file. I wrote a file access arbitrator daemon (based on IO::Select and IO::Socket), which has proven much more robust, but is still not adequate. I have a couple more ideas for improving it, but if I can reduce the killed processes (that is, letting my internal processes finish what they start), then that will help in the meantime. On further examination/testing, I think "svc -h' may be what I want (for now), and I should just avoid killing the current connections and let them finish. The only problem is that it can often take a while to drain the queue. http://www.nntp.perl.org/group/perl.qpsmtpd/2008/09/msg8229.html Sun, 28 Sep 2008 08:01:45 +0000 Re: [qpsmtpd] Is there an orderly restart? by John Peacock b-sub-96e3ab9a984935f@rope.net wrote: > Is there a way to not accept any more connections, let the current > connections finish, and then restart qpsmtpd? Something has to be better > than my current heavy hammer approach. I use 'svc -t' instead of HUP, because it will kill all of the connections associated with the master process. And I do it whenever I feel like it. The SMTP protocol was designed specifically to be very tolerant of disruptions; all legitimate servers will happily resend an e-mail because of a snipped connection (though at their internal retry interval). It is really not possible to lose legitimate e-mail by randomly stopping your SMTP server to reload plugins. On the other hand, most zombie SMTP clients can't handle anything out of the ordinary, so that's once piece of spam you probably won't receive... John http://www.nntp.perl.org/group/perl.qpsmtpd/2008/09/msg8228.html Sun, 28 Sep 2008 06:45:54 +0000 Re: DNSBL and answer id check missing by Ask Bjørn Hansen On Sep 28, 2008, at 12:01 AM, Diego d'Ambra wrote: > my $res = new Net::DNS::Resolver; > $res->tcp_timeout(30); > $res->udp_timeout(30); > $res->srcport(1024+int(rand(64511))); Shouldn't this fix be in Net::DNS::Resolver? - ask -- http://develooper.com/ - http://askask.com/ http://www.nntp.perl.org/group/perl.qpsmtpd/2008/09/msg8227.html Sun, 28 Sep 2008 02:15:02 +0000 PATCH: Re: DNSBL and answer id check missing by Diego d'Ambra This is a multi-part message in MIME format. http://www.nntp.perl.org/group/perl.qpsmtpd/2008/09/msg8226.html Sun, 28 Sep 2008 01:59:38 +0000 Re: DNSBL and answer id check missing by Diego d'Ambra Diego d'Ambra wrote: [...] > > I made a little change to DNSBL to ensure it randomize scr port and I > see a major difference. > Maybe latest version of Net::DNS does this (after Dan's widely report exploit). My box is an older Sarge solution, so others may not see same issue. But even with random src port it will happen - on my system probably around 100 times per day. Best regards, Diego d'Ambra http://www.nntp.perl.org/group/perl.qpsmtpd/2008/09/msg8225.html Sun, 28 Sep 2008 01:05:56 +0000 Re: DNSBL and answer id check missing by Diego d'Ambra Matt Sergeant wrote: > On Sat, 27 Sep 2008 13:56:58 +0200, Diego d'Ambra wrote: >> To me it seems that plugin DNSBL is using Net::DNS bgsend/bgread, but >> is not checking the id of the reply received. >> >> If true this means that an attacker can white- or blacklist any email > > Thinking more about this - since we don't do any "dnswl" type stuff, it > doesn't seem that relevant. > > All the attacker can do is blacklist more emails, which given the > timings surely he can only blacklist his own emails? > > Just a thought - wondering if this really needs to be fixed. > I made a little change to DNSBL to ensure it randomize scr port and I see a major difference. ---snip--- my $res = new Net::DNS::Resolver; $res->tcp_timeout(30); $res->udp_timeout(30); $res->srcport(1024+int(rand(64511))); ---snip--- Anyway the worst is maybe that with current solution, results are very wrong - e.g. blacklisting a sender that shouldn't be, but is because no checking of received dns replies. The more busy your server is, the more it happens - on a server handling around 2 millions SMTP sessions per day, I see blacklisting of "valid" sender about every 30 seconds. I vote for a fix :-) Best regards, Diego d'Ambra http://www.nntp.perl.org/group/perl.qpsmtpd/2008/09/msg8224.html Sun, 28 Sep 2008 00:02:06 +0000 Re: DNSBL and answer id check missing by Matt Sergeant On Sat, 27 Sep 2008 20:09:37 -0400, Chris Lewis wrote: > I've extended the async dnsbl plugin to do scoring. It occured to me a > few days ago that DNSBLs with negative scores (DNSWLs) should be treated > as a hit if they get a timeout or other failure. This has prompted me > to comment about checking ids too. > > The stock one doesn't do scoring, and hence can't do DNSWL. You want my > code? You might not like my logging conventions however ;-) Like I said, the async version doesn't suffer from this bug, because it uses ParaDNS which checks the id fields (but doesn't do 0x20 checking - I wish I knew enough to be able to extend it to do so). http://www.nntp.perl.org/group/perl.qpsmtpd/2008/09/msg8223.html Sat, 27 Sep 2008 18:04:21 +0000 Re: DNSBL and answer id check missing by Chris Lewis Matt Sergeant wrote: > On Sat, 27 Sep 2008 13:56:58 +0200, Diego d'Ambra wrote: >> To me it seems that plugin DNSBL is using Net::DNS bgsend/bgread, but >> is not checking the id of the reply received. >> >> If true this means that an attacker can white- or blacklist any email > > Thinking more about this - since we don't do any "dnswl" type stuff, it > doesn't seem that relevant. > > All the attacker can do is blacklist more emails, which given the > timings surely he can only blacklist his own emails? > > Just a thought - wondering if this really needs to be fixed. I've extended the async dnsbl plugin to do scoring. It occured to me a few days ago that DNSBLs with negative scores (DNSWLs) should be treated as a hit if they get a timeout or other failure. This has prompted me to comment about checking ids too. The stock one doesn't do scoring, and hence can't do DNSWL. You want my code? You might not like my logging conventions however ;-) http://www.nntp.perl.org/group/perl.qpsmtpd/2008/09/msg8222.html Sat, 27 Sep 2008 17:10:11 +0000 Re: DNSBL and answer id check missing by Matt Sergeant On Sat, 27 Sep 2008 13:56:58 +0200, Diego d'Ambra wrote: > To me it seems that plugin DNSBL is using Net::DNS bgsend/bgread, but > is not checking the id of the reply received. > > If true this means that an attacker can white- or blacklist any email Thinking more about this - since we don't do any "dnswl" type stuff, it doesn't seem that relevant. All the attacker can do is blacklist more emails, which given the timings surely he can only blacklist his own emails? Just a thought - wondering if this really needs to be fixed. Matt. http://www.nntp.perl.org/group/perl.qpsmtpd/2008/09/msg8221.html Sat, 27 Sep 2008 15:56:55 +0000 Re: DNSBL and answer id check missing by Diego d'Ambra Hanno Hecker wrote: > Hi Diego, > > On Sat, 27 Sep 2008 10:11:15 -0400 > Matt Sergeant <matt@sergeant.org> wrote: >> On Sat, 27 Sep 2008 13:56:58 +0200, Diego d'Ambra wrote: >>> To me it seems that plugin DNSBL is using Net::DNS bgsend/bgread, but >>> is not checking the id of the reply received. > [...] >>> I'm working on a way to test this, but would love to hear others >>> opinion, before doing to much work for maybe nothing :-) >> I'm pretty sure you're probably right. The async version uses ParaDNS >> which does do the id checking. > What about a generic resolver module for qpsmtpd? We're doing quite a > lot of lookups in the different plugins. > $ grep -lr bgsend plugins/ > plugins/dnsbl > plugins/rhsbl > plugins/dns_whitelist_soft > plugins/uribl > Plus the non async lookups in require_resolvable_fromhost and the > core. > Excellent idea and especially if the "other places" also need to be fixed. I'll gladly assist, but maybe somebody with greater knowledge in qpsmtpd's inner working should draft some minimum requirements? Best regards, Diego d'Ambra http://www.nntp.perl.org/group/perl.qpsmtpd/2008/09/msg8220.html Sat, 27 Sep 2008 12:40:57 +0000 Re: DNSBL and answer id check missing by Hanno Hecker Hi Diego, On Sat, 27 Sep 2008 10:11:15 -0400 Matt Sergeant <matt@sergeant.org> wrote: > On Sat, 27 Sep 2008 13:56:58 +0200, Diego d'Ambra wrote: > > To me it seems that plugin DNSBL is using Net::DNS bgsend/bgread, but > > is not checking the id of the reply received. [...] > > I'm working on a way to test this, but would love to hear others > > opinion, before doing to much work for maybe nothing :-) > > I'm pretty sure you're probably right. The async version uses ParaDNS > which does do the id checking. What about a generic resolver module for qpsmtpd? We're doing quite a lot of lookups in the different plugins. $ grep -lr bgsend plugins/ plugins/dnsbl plugins/rhsbl plugins/dns_whitelist_soft plugins/uribl Plus the non async lookups in require_resolvable_fromhost and the core. Hanno http://www.nntp.perl.org/group/perl.qpsmtpd/2008/09/msg8219.html Sat, 27 Sep 2008 09:18:52 +0000 Re: DNSBL and answer id check missing by Matt Sergeant On Sat, 27 Sep 2008 13:56:58 +0200, Diego d'Ambra wrote: > To me it seems that plugin DNSBL is using Net::DNS bgsend/bgread, but > is not checking the id of the reply received. > > If true this means that an attacker can white- or blacklist any email > by sending fake dns replies (only randomisation is source port). > Furthermore any other application on same machine also doing dns > lookup may end up using same source port and have it's replies being > mixed with those plugin DNSBL is waiting for. > > Spamassassin is also using Net::DNS bgsend/bgread, but does verify if > the dns answer id matched the request. > > Maybe Net::DNS requires the caller to do the validation, or did I > miss something? > > I'm working on a way to test this, but would love to hear others > opinion, before doing to much work for maybe nothing :-) I'm pretty sure you're probably right. The async version uses ParaDNS which does do the id checking. (we should probably do 0x20 checking too, but I think that's beyond my skill levels :-/ ) http://www.nntp.perl.org/group/perl.qpsmtpd/2008/09/msg8218.html Sat, 27 Sep 2008 07:11:51 +0000 DNSBL and answer id check missing by Diego d'Ambra To me it seems that plugin DNSBL is using Net::DNS bgsend/bgread, but is not checking the id of the reply received. If true this means that an attacker can white- or blacklist any email by sending fake dns replies (only randomisation is source port). Furthermore any other application on same machine also doing dns lookup may end up using same source port and have it's replies being mixed with those plugin DNSBL is waiting for. Spamassassin is also using Net::DNS bgsend/bgread, but does verify if the dns answer id matched the request. Maybe Net::DNS requires the caller to do the validation, or did I miss something? I'm working on a way to test this, but would love to hear others opinion, before doing to much work for maybe nothing :-) Best regards, Diego d'Ambra http://www.nntp.perl.org/group/perl.qpsmtpd/2008/09/msg8217.html Sat, 27 Sep 2008 04:57:11 +0000 Re: Spamassasin and relay client by Robert Spier Hanno Hecker wrote: > > On Fri, 26 Sep 2008 19:10:42 +0200 > julien@nura.eu wrote: > > So I write my own wrapper plugin called "sa_norelay" with the following code : > [...] > > Then I replace the spamassin call in config/plugins file by > > sa_norelay, and switch to the 0.40 version or newer. > > > > Am I right ? > Yes, if it works in 0.40 :) I don't know when this was added. Plugin wrappers have been around for a long long long time. Since at least 0.31, which is late 2005. I'm really happy to start seeing people use them. -R http://www.nntp.perl.org/group/perl.qpsmtpd/2008/09/msg8216.html Fri, 26 Sep 2008 22:36:06 +0000 [qpsmtpd] Is there an orderly restart? by b-sub-96e3ab9a984935f I find that when I am creating or changing plugins, I end up restarting qpsmtpd regularly. However, this simply amounts to doing "svc -h" and then cleaning up a few outstanding connections (killing their PIDs), which stops the subsequent log entries: Creating TCP socket 0:465: Address already in use Is there a way to not accept any more connections, let the current connections finish, and then restart qpsmtpd? Something has to be better than my current heavy hammer approach. Or should I simply be doing "svc -h" and then letting nature take its course? Thank-you. http://www.nntp.perl.org/group/perl.qpsmtpd/2008/09/msg8215.html Fri, 26 Sep 2008 15:17:50 +0000 Re: Spamassasin and relay client by Hanno Hecker On Fri, 26 Sep 2008 19:10:42 +0200 julien@nura.eu wrote: > So I write my own wrapper plugin called "sa_norelay" with the following code : [...] > Then I replace the spamassin call in config/plugins file by > sa_norelay, and switch to the 0.40 version or newer. > > Am I right ? Yes, if it works in 0.40 :) I don't know when this was added. Hanno http://www.nntp.perl.org/group/perl.qpsmtpd/2008/09/msg8214.html Fri, 26 Sep 2008 11:23:49 +0000