Re: [qmailtoaster] Re: How to fix DNS for Received: from unknown
On Tue, 21 Oct 2014 18:50:11 -0700, Eric Shubert wrote: Personally, I think that's information that doesn't need to be in the message header (along with the authenticated user's account id, but that's another matter). Apparently, that info is important for SA. Here's my discussion on the SA users list that elicited this: http://goo.gl/icChJU (I think that getting the DNS fixed so RBL tests work will take care of that). I'm happy to hear its configurable. I'm going to change my config so the header is written and see if SA scoring improves. I'd like to see spamdyke add its own header at some point, at which time I'm sure it will be there. Sam's very thorough about these things. ;) Is spamdyke packaged with QMT nowadays? I'm not using it. Quinn - To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
Re: [qmailtoaster] Re: Disable SSLv3, POODLE: SSLv3 vulnerability
On Tue, 21 Oct 2014 19:02:09 -0700, Eric Shubert wrote: In order to disable SSL in dovecot, you could either block the SSL ports (993, 995) in the firewall, or change /etc/dovecot/toaster.conf file by adding :!SSLv3 to the list of ciphers: ssl_cipher_list = ALL:!LOW:!SSLv2:!SSLv3:!EXP:!aNULL:DES-CBC3-SHA Reconsider disabling SSLv3 ciphers! In OpenSSL they're used by TLSv1.0 and TLSv1.1. The TLSv1.1 protocol didn't introduce any new ciphers, it uses SSLv3 ciphers. If you do this—as far as I've read, I didn't try—TLS for clients that don't support at least version 1.2 will stop working. https://security.stackexchange.com/questions/70832/why-doesnt-the-tls-protocol-work-without-the-sslv3-ciphersuites The correct action is to disable the SSLv3 protocol itself, if possible. Limiting connections to clients capable of = TLSv1.2 might be fine, but I do know how many support that; maybe most? Quinn
Re: [qmailtoaster] Re: SpamAssassin (continued)
On 10/21/2014 10:18 PM, Eric Shubert wrote: On 10/21/2014 05:45 PM, Dan McAllister wrote: OK, to review: I have a QMT install that doesn't seem to be running SpamAssassin against inbound mail. I hope here to show what is going on so that someone can interpret the logs (better than I can). I have setup a forward on the domain that is not being scanned properly. Messages go into the account (through what should be a spam/virus scanner) and then gets bounced back to my regular mail server. Here are the header entries for the message going into the client's mail server (remember, log file entries work their way UP -- that is, new log entries go at the TOP of the header): *Received:*(qmail 13916 invoked by uid 89); 22 Oct 2014 00:10:45 - *Received:*by simscan 1.4.0 ppid: 13908, pid: 13912, t: 0.3950s scanners: attach: 1.4.0 clamav: 0.98.1/m:55/d:19525 *Received:*from unknown (HELO b-b-b.com) (u...@it4soho.com https://mail.it4soho.com/src/compose.php?send_to=dan%40it4soho.com@10.11.12.13) by mail.host.com with ESMTPA; 22 Oct 2014 00:10:45 - And here are the headers for when the message comes back into my server... *Received:*(qmail 13967 invoked by uid 89); 22 Oct 2014 00:11:03 - *Received:*by simscan 1.4.0 ppid: 13952, pid: 13955, t: 3.6881s scanners: attach: 1.4.0 clamav: 0.98.1/m:55/d:19525 spam: 3.3.2 *X-Spam-Checker-Version:*SpamAssassin 3.3.2 (2011-06-06) on host.it4soho.com *X-Spam-Level: *X-Spam-Status:*No, score=3.3 required=5.0 tests=AWL,BAYES_99,HTML_MESSAGE, RDNS_NONE autolearn=no version=3.3.2 *Received:*from unknown (HELO a-a-a.com) (1.2.3.4) by mail.it4soho.com with SMTP; 22 Oct 2014 00:11:00 - Note the conspicuous ABSENCE of the X-Spam-* entries that come from SpamAssassin in the first collection... Now, when I look at the contents of the spamd log file, I see the same types of entries I see in the main server that DOES put the headers where they are expected. So I am next thinking there is an issue with SpamAssassin itself... but I have ZERO experience with SA (I have so much else to do, I typically turn it on and just let it go! Never debugged SA before!) :) Any help is appreciated.. Dan IT4SOHO I'm real glad other have chimed in, because from what you've described, I don't really have a clue. The Received: by simscan line above shows that spamassassin isn't being used. Yet your simcontrol says that it should be. I think EricB may be on to something. Run cdb to activate the latest simcontrol file. Short of that, I'd like to see samples of your spamd log file, and the contents of your local.cf configuration file. Maybe something's defeating sa there. Who knows what you did to turn it off??? ;) The normal way would be to modify the simcontrol file, then run qmailctl cdb. Let us know how you make out. Thanks. Agreed - the normal way would be the simcontrol file followed by a CDB rebuild... but I checked that first... Per the OTHER Eric's request: 1) spamd is in the /var/qmail/supervise folder and the run file matches my good server exec /usr/bin/spamd -x -u vpopmail -s stderr 21 2) the contents of the simcontrol file have been posted already, but are: :clam=yes,spam=yes,spam_hits=12,attach=.mp3:.src:.bat:.pif 3) per Eric Shubert's request, contents of the spamd log file # qmlog spamd | tail 10-22 09:29:09 Oct 22 09:29:09.397 [7613] info: spamd: connection from localhost [127.0.0.1] at port 50523 10-22 09:29:09 Oct 22 09:29:09.401 [7613] info: spamd: processing message 053A7D23649B4DB25B2DBE8718FFE98FE55CF97F@APPSERVER3 for clamav:89 10-22 09:29:09 Oct 22 09:29:09.899 [7613] info: spamd: clean message (1.3/5.0) for clamav:89 in 0.5 seconds, 8275 bytes. 10-22 09:29:09 Oct 22 09:29:09.899 [7613] info: spamd: result: . 1 - HTML_MESSAGE,RDNS_NONE scantime=0.5,size=8275,user=clamav,uid=89,required_score=5.0,rhost=localhost,raddr=127.0.0.1,rport=50523,mid=053A7D23649B4DB25B2DBE8718FFE98FE55CF97F@APPSERVER3,autolearn=no 10-22 09:29:09 Oct 22 09:29:09.933 [27470] info: prefork: child states: II 10-22 09:29:32 Oct 22 09:29:32.780 [7613] info: spamd: connection from localhost [127.0.0.1] at port 50525 10-22 09:29:32 Oct 22 09:29:32.784 [7613] info: spamd: processing message 696d8c8c293aecacc28402d816919...@oesty.com for clamav:89 10-22 09:29:32 Oct 22 09:29:32.963 [7613] info: spamd: clean message (1.2/5.0) for clamav:89 in 0.2 seconds, 9156 bytes. 10-22 09:29:32 Oct 22 09:29:32.964 [7613] info: spamd: result: . 1 - DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HTML_MESSAGE,RDNS_NONE scantime=0.2,size=9156,user=clamav,uid=89,required_score=5.0,rhost=localhost,raddr=127.0.0.1,rport=50525,mid=696d8c8c293aecacc28402d816919...@oesty.com,autolearn=no 10-22 09:29:32 Oct 22 09:29:32.999 [27470] info: prefork: child states: II I'm learning more and more about simscan
[qmailtoaster] Re: How to fix DNS for Received: from unknown
On 10/21/2014 11:58 PM, Quinn Comendant wrote: On Tue, 21 Oct 2014 18:50:11 -0700, Eric Shubert wrote: Personally, I think that's information that doesn't need to be in the message header (along with the authenticated user's account id, but that's another matter). Apparently, that info is important for SA. Here's my discussion on the SA users list that elicited this: http://goo.gl/icChJU (I think that getting the DNS fixed so RBL tests work will take care of that). I'm happy to hear its configurable. I'm going to change my config so the header is written and see if SA scoring improves. I'd like to see spamdyke add its own header at some point, at which time I'm sure it will be there. Sam's very thorough about these things. ;) Is spamdyke packaged with QMT nowadays? I'm not using it. Quinn - That's interesting. The extra DNS lookup is no big deal really, as it'd be cached by the resolver. I don't recall any other negative side effects of taking the -H away. I seem to recall some discussion about it several years back on this list though. Would you try to find that and see what the upshot was? We should probably consider removing the -H option. This is somewhat moot though, as the new qmail package will be using xinetd/init instead of tcpserver/supervise in an upcoming release. Everything except qmail is no longer using supervise, and qmail is the last piece. I don't have a time estimate for this, but I expect it will be the next release. Yes, there is a new spamdyke rpm included with the yum repos for the new QMT. You cannot use this with the legacy qmail-toaster package though, as the configurations are a little different. You should most definitely be using spamdyke. You can install it with the qtp-install-spamdyke script. Your server will thank you, as you'll see the load drop significantly because it won't be scanning nearly as much. I wouldn't run a mail server without it. -- -Eric 'shubes' - To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
Re: [qmailtoaster] Re: SpamAssassin (continued)
On 10/22/2014 7:31 AM, Dan McAllister wrote: On 10/21/2014 10:18 PM, Eric Shubert wrote: On 10/21/2014 05:45 PM, Dan McAllister wrote: OK, to review: I have a QMT install that doesn't seem to be running SpamAssassin against inbound mail. I hope here to show what is going on so that someone can interpret the logs (better than I can). I have setup a forward on the domain that is not being scanned properly. Messages go into the account (through what should be a spam/virus scanner) and then gets bounced back to my regular mail server. Here are the header entries for the message going into the client's mail server (remember, log file entries work their way UP -- that is, new log entries go at the TOP of the header): *Received:*(qmail 13916 invoked by uid 89); 22 Oct 2014 00:10:45 - *Received:*by simscan 1.4.0 ppid: 13908, pid: 13912, t: 0.3950s scanners: attach: 1.4.0 clamav: 0.98.1/m:55/d:19525 *Received:*from unknown (HELO b-b-b.com) (u...@it4soho.com https://mail.it4soho.com/src/compose.php?send_to=dan%40it4soho.com@10.11.12.13) by mail.host.com with ESMTPA; 22 Oct 2014 00:10:45 - And here are the headers for when the message comes back into my server... *Received:*(qmail 13967 invoked by uid 89); 22 Oct 2014 00:11:03 - *Received:*by simscan 1.4.0 ppid: 13952, pid: 13955, t: 3.6881s scanners: attach: 1.4.0 clamav: 0.98.1/m:55/d:19525 spam: 3.3.2 *X-Spam-Checker-Version:*SpamAssassin 3.3.2 (2011-06-06) on host.it4soho.com *X-Spam-Level: *X-Spam-Status:*No, score=3.3 required=5.0 tests=AWL,BAYES_99,HTML_MESSAGE, RDNS_NONE autolearn=no version=3.3.2 *Received:*from unknown (HELO a-a-a.com) (1.2.3.4) by mail.it4soho.com with SMTP; 22 Oct 2014 00:11:00 - Note the conspicuous ABSENCE of the X-Spam-* entries that come from SpamAssassin in the first collection... Now, when I look at the contents of the spamd log file, I see the same types of entries I see in the main server that DOES put the headers where they are expected. So I am next thinking there is an issue with SpamAssassin itself... but I have ZERO experience with SA (I have so much else to do, I typically turn it on and just let it go! Never debugged SA before!) :) Any help is appreciated.. Dan IT4SOHO I'm real glad other have chimed in, because from what you've described, I don't really have a clue. The Received: by simscan line above shows that spamassassin isn't being used. Yet your simcontrol says that it should be. I think EricB may be on to something. Run cdb to activate the latest simcontrol file. Short of that, I'd like to see samples of your spamd log file, and the contents of your local.cf configuration file. Maybe something's defeating sa there. Who knows what you did to turn it off??? ;) The normal way would be to modify the simcontrol file, then run qmailctl cdb. Let us know how you make out. Thanks. Agreed - the normal way would be the simcontrol file followed by a CDB rebuild... but I checked that first... Per the OTHER Eric's request: 1) spamd is in the /var/qmail/supervise folder and the run file matches my good server exec /usr/bin/spamd -x -u vpopmail -s stderr 21 2) the contents of the simcontrol file have been posted already, but are: :clam=yes,spam=yes,spam_hits=12,attach=.mp3:.src:.bat:.pif 3) per Eric Shubert's request, contents of the spamd log file # qmlog spamd | tail 10-22 09:29:09 Oct 22 09:29:09.397 [7613] info: spamd: connection from localhost [127.0.0.1] at port 50523 10-22 09:29:09 Oct 22 09:29:09.401 [7613] info: spamd: processing message 053A7D23649B4DB25B2DBE8718FFE98FE55CF97F@APPSERVER3 for clamav:89 10-22 09:29:09 Oct 22 09:29:09.899 [7613] info: spamd: clean message (1.3/5.0) for clamav:89 in 0.5 seconds, 8275 bytes. 10-22 09:29:09 Oct 22 09:29:09.899 [7613] info: spamd: result: . 1 - HTML_MESSAGE,RDNS_NONE scantime=0.5,size=8275,user=clamav,uid=89,required_score=5.0,rhost=localhost,raddr=127.0.0.1,rport=50523,mid=053A7D23649B4DB25B2DBE8718FFE98FE55CF97F@APPSERVER3,autolearn=no 10-22 09:29:09 Oct 22 09:29:09.933 [27470] info: prefork: child states: II 10-22 09:29:32 Oct 22 09:29:32.780 [7613] info: spamd: connection from localhost [127.0.0.1] at port 50525 10-22 09:29:32 Oct 22 09:29:32.784 [7613] info: spamd: processing message 696d8c8c293aecacc28402d816919...@oesty.com for clamav:89 10-22 09:29:32 Oct 22 09:29:32.963 [7613] info: spamd: clean message (1.2/5.0) for clamav:89 in 0.2 seconds, 9156 bytes. 10-22 09:29:32 Oct 22 09:29:32.964 [7613] info: spamd: result: . 1 - DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HTML_MESSAGE,RDNS_NONE
[qmailtoaster] Re: Disable SSLv3, POODLE: SSLv3 vulnerability
On 10/22/2014 12:18 AM, Quinn Comendant wrote:
On Tue, 21 Oct 2014 19:02:09 -0700, Eric Shubert wrote:
In order to disable SSL in dovecot, you could either block the SSL
ports (993, 995) in the firewall, or change /etc/dovecot/toaster.conf
file by adding :!SSLv3 to the list of ciphers:
ssl_cipher_list = ALL:!LOW:!SSLv2:!SSLv3:!EXP:!aNULL:DES-CBC3-SHA
Reconsider disabling SSLv3 ciphers! In OpenSSL they're used by TLSv1.0 and
TLSv1.1. The TLSv1.1 protocol didn't introduce any new ciphers, it uses SSLv3
ciphers. If you do this—as far as I've read, I didn't try—TLS for clients that
don't support at least version 1.2 will stop working.
https://security.stackexchange.com/questions/70832/why-doesnt-the-tls-protocol-work-without-the-sslv3-ciphersuites
The correct action is to disable the SSLv3 protocol itself, if possible. Limiting
connections to clients capable of = TLSv1.2 might be fine, but I do know how
many support that; maybe most?
Quinn
Good points, thanks. Given this bit, it would seem that closing the SSL
ports, either at the firewall or by restricting the ports dovecot uses
by adding a listen option to the pop3 and imap sections, would be
effective. Here's the bit from dovecot's example.conf file (which has
been somewhat negligently omitted from the QMT dovecot package - my
mistake):
# If you want to specify ports for each service, you will need to configure
# these settings inside the protocol imap/pop3 { ... } section, so you can
# specify different ports for IMAP/POP3. For example:
# protocol imap {
# listen = *:10143
# ssl_listen = *:10943
# ..
# }
# protocol pop3 {
# listen = *:10100
# ..
# }
#listen = *
I expect there will always be some confusion about SSL/TLS. The dovecot
wiki (http://wiki2.dovecot.org/SSL) explains things pretty well.
I'm still not real clear though on where the poodle vulnerability
exactly lies, so I'm a little unsure. What I do know is that Qualys
regards the risk as relatively low, so I wouldn't lose any sleep over
this one.
Thanks.
--
-Eric 'shubes'
-
To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
Re: [qmailtoaster] Re: Disable SSLv3, POODLE: SSLv3 vulnerability
On Fri, 17 Oct 2014 10:52:12 +0300, Catalin Leanca wrote: I managed to disable SSLv3 in /etc/courier/imapd-ssl and /etc/courier/pop3-ssl Changed TLS_PROTOCOL=SSLv3 to TLS_PROTOCOL=TLS1 Catalin (and others): have you succeeded in disabling SSLv3 in courier? When I try this configuration, I am unable to connect even with a TLS-compatible client, not even the openssl itself: openssl s_client -state -nbio -connect mail.example.com:993 I get this output: CONNECTED(0003) turning on non blocking io SSL_connect:before/connect initialization SSL_connect:SSLv2/v3 write client hello A SSL_connect:error in SSLv2/v3 read server hello A write R BLOCK SSL_connect:error in SSLv2/v3 read server hello A read:errno=54 According to the openssl documentation, this error usually results from the connection not being able to auto-negotiate a suitable ssl version to use. So, I force a TLS connection using -tls1: openssl s_client -state -nbio -connect oak2.strangecode.com:993 -tls1 And then I get a successful connection with the openssl client. The problem is the real IMAP client I use (Gyazmail) doesn't connect (thought it does support TLS). Perhaps it is trying SSLv3 first, and fails to negotiate to TLS? I read also some Courier versions have this problem, some not [1]. I'd appreciate if you could run the above openssl command (without -tls1) and let me know if it connects for you or not. BTW, if you want to test that your server refuses SSLv3 connections, run the openssl client with '-ssl3'. Quinn [1] http://sourceforge.net/p/courier/mailman/message/17185523/ - To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
Re: [qmailtoaster] Re: Disable SSLv3, POODLE: SSLv3 vulnerability
For me , that command works. I also modified IMAPDSSLSTART=NO and IMAP_TLS_REQUIRED=1 On 22/10/14 18:21, Quinn Comendant wrote: On Fri, 17 Oct 2014 10:52:12 +0300, Catalin Leanca wrote: I managed to disable SSLv3 in /etc/courier/imapd-ssl and /etc/courier/pop3-ssl Changed TLS_PROTOCOL=SSLv3 to TLS_PROTOCOL=TLS1 Catalin (and others): have you succeeded in disabling SSLv3 in courier? When I try this configuration, I am unable to connect even with a TLS-compatible client, not even the openssl itself: openssl s_client -state -nbio -connect mail.example.com:993 I get this output: CONNECTED(0003) turning on non blocking io SSL_connect:before/connect initialization SSL_connect:SSLv2/v3 write client hello A SSL_connect:error in SSLv2/v3 read server hello A write R BLOCK SSL_connect:error in SSLv2/v3 read server hello A read:errno=54 According to the openssl documentation, this error usually results from the connection not being able to auto-negotiate a suitable ssl version to use. So, I force a TLS connection using -tls1: openssl s_client -state -nbio -connect oak2.strangecode.com:993 -tls1 And then I get a successful connection with the openssl client. The problem is the real IMAP client I use (Gyazmail) doesn't connect (thought it does support TLS). Perhaps it is trying SSLv3 first, and fails to negotiate to TLS? I read also some Courier versions have this problem, some not [1]. I'd appreciate if you could run the above openssl command (without -tls1) and let me know if it connects for you or not. BTW, if you want to test that your server refuses SSLv3 connections, run the openssl client with '-ssl3'. Quinn [1] http://sourceforge.net/p/courier/mailman/message/17185523/ - To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com -- CS Catalin LEANCA ICI ROTLD - Serviciul Tehnic Bd. Maresal Averescu 8-10, Sector 1, Bucuresti - To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
Re: [qmailtoaster] Re: How to fix DNS for Received: from unknown
Hi Eric, On Wed, 22 Oct 2014, Eric Shubert wrote: This is somewhat moot though, as the new qmail package will be using xinetd/init instead of tcpserver/supervise in an upcoming release. Everything except qmail is no longer using supervise, and qmail is the last piece. I don't have a time estimate for this, but I expect it will be the next release. I didn't find in the list archive if you've explained it already I'm curious: ¿why did you consider better to not run qmail and another pieces under tcpserver/supervise and choose go back to inetd/xinetd? Could you elaborate on that please? (on free time of course) regards, -- Abel Lucano GlobalGate Ingeniería - To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
[qmailtoaster] current install process
I was poking around the github site and (probably just blind) did not see the current install process (still running a V1 toaster). Current link? Regards. D - To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
