[qmailtoaster] current install process

2014-10-22 Thread DNK 
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

Re: [qmailtoaster] Re: How to fix DNS for "Received: from unknown"

2014-10-22 Thread aal 


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

Re: [qmailtoaster] Re: Disable SSLv3, POODLE: SSLv3 vulnerability

2014-10-22 Thread Catalin Leanca 

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: Disable SSLv3, POODLE: SSLv3 vulnerability

2014-10-22 Thread Quinn Comendant 
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

[qmailtoaster] Re: Disable SSLv3, POODLE: SSLv3 vulnerability

2014-10-22 Thread Eric Shubert 

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: SpamAssassin (continued)

2014-10-22 Thread Eric Broch 
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
>>>
>>> @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 2>&1
> 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:

[qmailtoaster] Re: How to fix DNS for "Received: from unknown"

2014-10-22 Thread Eric Shubert 

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)

2014-10-22 Thread Dan McAllister 

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
@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 2>&1
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

Re: [qmailtoaster] Re: Disable SSLv3, POODLE: SSLv3 vulnerability

2014-10-22 Thread Quinn Comendant 
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