Re: [qmailtoaster] status of qmail-1.03-3 CentOS 7 ?

2018-08-16 Thread Remo Mattei
Yes, I now have two of the qmail servers on 7 with .1 I need to migrate some 
domains like 20 or so from an old 5.x centos..

Remo

> On Aug 16, 2018, at 18:37, Eric Broch  wrote:
> 
> Did the first one upgrade to 1.03-3.1 okay?
> 
> 
> On 8/16/2018 7:05 PM, Remo Mattei wrote:
>> So some interesting thing!!
>> 
>> The second server I tried to run the .1 update and it went but I could not 
>> get stuff back on running. Luck me I had a .tg of the bin for qmail and what 
>> I did I downgraded, then restore the .gz and was able to get it back alive.. 
>> One of the major issues was I could not send mail out (apple mail) round 
>> cube etc.. would not send. Once restored, I checked and all was good.. So 
>> giving it a second chance.. I rerun the yum command with the .1 and 
>> restarted the services and now it’s all working and downloaded the 
>> qmail-remote and since I had dkim working it’s all good again. I also added 
>> the DMARC DNS entry and here is the output
>> 
>> 
>> 
>>> On Aug 16, 2018, at 17:01, Andrew Swartz >> > wrote:
>>> 
>>> Eric,
>>> 
>>> That's interesting.  Those tcprules are that which was present after the
>>> upgrade.  I do not know if it changed them or left them default from
>>> qt-install.  I only copied tcp.smtp to tcp.smtps and changed the ciphers
>>> at the end of the line.  I definitely did not add domain keys to it.
>>> 
>>> Also, there is still a control/domainkeys directory.  It is empty.  It
>>> must have been created by qt-install because I did not create it.  I do
>>> plan on adding dkim, but I've not gotten to it yet.
>>> 
>>> -Andy
>>> 
>>> 
>>> On 8/16/2018 3:49 PM, Eric Broch wrote:
 Andy,
 
 I noticed your tcprules include domain keys, be aware that if you
 upgrade to qmail-1.03-3.1 domainkeys have been removed.
 
 Eric
 
 
 On 8/16/2018 5:25 PM, Andrew Swartz wrote:
> Eric,
> 
> Your request prompted me to look more closely at these files.
> 
> I believe that installing qmail-1.03-3.qt.el7.x86_64.rpm overwrote my
> /var/qmail/supervise/smtps/run with a new one which is missing the
> 'export REQUIRE_AUTH=1' line.  The new one does correctly have 'export
> SMTPS=1'.  The new supervise/smtps/log/run names the log file
> "smtp-ssl", whereas I have named it "smtps".  I would argue it should be
> the latter for consistency, but it is clearly noncritical.
> 
> 
> Here is my /etc/tcprules.d/tcp.smtp:
> 
> :allow,BADMIMETYPE="",BADLOADERTYPE="M",CHKUSER_RCPTLIMIT="50",CHKUSER_WRONGRCPTLIMIT="10",NOP0FCHECK="1",QMAILQUEUE="/var/qmail/bin/simscan",DKQUEUE="/var/qmail/bin/qmail-queue.orig",DKVERIFY="DEGIJKfh",DKSIGN="/var/qmail/control/domainkeys/%/private"
> 
> 
> 
> 
> Here is my /etc/tcprules.d/tcp.smtps:
> 
> :allow,BADMIMETYPE="",BADLOADERTYPE="M",CHKUSER_RCPTLIMIT="50",CHKUSER_WRONGRCPTLIMIT="10",NOP0FCHECK="1",QMAILQUEUE="/var/qmail/bin/simscan",DKQUEUE="/var/qmail/bin/qmail-queue.orig",DKVERIFY="DEGIJKfh",DKSIGN="/var/qmail/control/domainkeys/%/private",TLSCIPHERS="TLSv1.2:!eNULL:!aNULL"
> 
> 
> 
> They are identical except that the smtp one does not have a TLSCIPHERS
> setting.  This is for two reasons:
> 1.  per my read of the TLS patch, if not present, it defaults to using
> qmail/control/tlsserverciphers. This would make qmail-smtpd and
> qmail-remote use the same ciphers (because tlsclientciphers is just a
> link to tlsserverciphers).  Since both of those are doing relay, that
> would seem appropriate for most setups.  Except...
> 2. Spamdyke does the STARTTLS for incoming (relay) mail. Therefore
> specifying a cipher for port 25 is useless.
> 
> If I were to continue to have port 587/STARTTLS in addition to 465/TLS,
> then I would have the supervise/submission/run script specify
> tcp.smtps.cdb so that the cipher rules are the same for these two ports
> because they are both handling submission and both not going through
> spamdyke.
> 
> 
> Here is my /var/qmail/supervise/smtps/run:
> #!/bin/sh
> QMAILDUID=`id -u vpopmail`
> NOFILESGID=`id -g vpopmail`
> MAXSMTPD=`cat /var/qmail/control/concurrencyincoming`
> SMTPD="/var/qmail/bin/qmail-smtpd"
> TCP_CDB="/etc/tcprules.d/tcp.smtps.cdb"
> HOSTNAME=`hostname`
> VCHKPW="/home/vpopmail/bin/vchkpw"
> export REQUIRE_AUTH=1
> export SMTPS=1
> 
> exec /usr/bin/softlimit -m 12800 \
>  /usr/bin/tcpserver -v -R -H -l $HOSTNAME -x $TCP_CDB -c
> "$MAXSMTPD" \
>  -u "$QMAILDUID" -g "$NOFILESGID" 0 465 \
>  $SMTPD $VCHKPW /bin/true 2>&1
> 
> 
> A line had to be added to /etc/rc.d/init.d/qmail (a near copy of line
> 83, placed right after it) so that /etc/tcprules.d/tcp.smtps gets
> compiled to /etc/tcprules.d/tcp.smtps.cdb when running 'qmailctl cdb'.
> 
> -Andy
> 
> 
> On 

Re: [qmailtoaster] status of qmail-1.03-3 CentOS 7 ?

2018-08-16 Thread Eric Broch

Did the first one upgrade to 1.03-3.1 okay?


On 8/16/2018 7:05 PM, Remo Mattei wrote:

So some interesting thing!!

The second server I tried to run the .1 update and it went but I could 
not get stuff back on running. Luck me I had a .tg of the bin for 
qmail and what I did I downgraded, then restore the .gz and was able 
to get it back alive.. One of the major issues was I could not send 
mail out (apple mail) round cube etc.. would not send. Once restored, 
I checked and all was good.. So giving it a second chance.. I rerun 
the yum command with the .1 and restarted the services and now it’s 
all working and downloaded the qmail-remote and since I had dkim 
working it’s all good again. I also added the DMARC DNS entry and here 
is the output




On Aug 16, 2018, at 17:01, Andrew Swartz > wrote:


Eric,

That's interesting.  Those tcprules are that which was present after the
upgrade.  I do not know if it changed them or left them default from
qt-install.  I only copied tcp.smtp to tcp.smtps and changed the ciphers
at the end of the line.  I definitely did not add domain keys to it.

Also, there is still a control/domainkeys directory.  It is empty.  It
must have been created by qt-install because I did not create it.  I do
plan on adding dkim, but I've not gotten to it yet.

-Andy


On 8/16/2018 3:49 PM, Eric Broch wrote:

Andy,

I noticed your tcprules include domain keys, be aware that if you
upgrade to qmail-1.03-3.1 domainkeys have been removed.

Eric


On 8/16/2018 5:25 PM, Andrew Swartz wrote:

Eric,

Your request prompted me to look more closely at these files.

I believe that installing qmail-1.03-3.qt.el7.x86_64.rpm overwrote my
/var/qmail/supervise/smtps/run with a new one which is missing the
'export REQUIRE_AUTH=1' line.  The new one does correctly have 'export
SMTPS=1'.  The new supervise/smtps/log/run names the log file
"smtp-ssl", whereas I have named it "smtps".  I would argue it 
should be

the latter for consistency, but it is clearly noncritical.


Here is my /etc/tcprules.d/tcp.smtp:

:allow,BADMIMETYPE="",BADLOADERTYPE="M",CHKUSER_RCPTLIMIT="50",CHKUSER_WRONGRCPTLIMIT="10",NOP0FCHECK="1",QMAILQUEUE="/var/qmail/bin/simscan",DKQUEUE="/var/qmail/bin/qmail-queue.orig",DKVERIFY="DEGIJKfh",DKSIGN="/var/qmail/control/domainkeys/%/private"




Here is my /etc/tcprules.d/tcp.smtps:

:allow,BADMIMETYPE="",BADLOADERTYPE="M",CHKUSER_RCPTLIMIT="50",CHKUSER_WRONGRCPTLIMIT="10",NOP0FCHECK="1",QMAILQUEUE="/var/qmail/bin/simscan",DKQUEUE="/var/qmail/bin/qmail-queue.orig",DKVERIFY="DEGIJKfh",DKSIGN="/var/qmail/control/domainkeys/%/private",TLSCIPHERS="TLSv1.2:!eNULL:!aNULL"



They are identical except that the smtp one does not have a TLSCIPHERS
setting.  This is for two reasons:
1.  per my read of the TLS patch, if not present, it defaults to using
qmail/control/tlsserverciphers. This would make qmail-smtpd and
qmail-remote use the same ciphers (because tlsclientciphers is just a
link to tlsserverciphers).  Since both of those are doing relay, that
would seem appropriate for most setups.  Except...
2. Spamdyke does the STARTTLS for incoming (relay) mail. Therefore
specifying a cipher for port 25 is useless.

If I were to continue to have port 587/STARTTLS in addition to 465/TLS,
then I would have the supervise/submission/run script specify
tcp.smtps.cdb so that the cipher rules are the same for these two ports
because they are both handling submission and both not going through
spamdyke.


Here is my /var/qmail/supervise/smtps/run:
#!/bin/sh
QMAILDUID=`id -u vpopmail`
NOFILESGID=`id -g vpopmail`
MAXSMTPD=`cat /var/qmail/control/concurrencyincoming`
SMTPD="/var/qmail/bin/qmail-smtpd"
TCP_CDB="/etc/tcprules.d/tcp.smtps.cdb"
HOSTNAME=`hostname`
VCHKPW="/home/vpopmail/bin/vchkpw"
export REQUIRE_AUTH=1
export SMTPS=1

exec /usr/bin/softlimit -m 12800 \
/usr/bin/tcpserver -v -R -H -l $HOSTNAME -x $TCP_CDB -c
"$MAXSMTPD" \
-u "$QMAILDUID" -g "$NOFILESGID" 0 465 \
$SMTPD $VCHKPW /bin/true 2>&1


A line had to be added to /etc/rc.d/init.d/qmail (a near copy of line
83, placed right after it) so that /etc/tcprules.d/tcp.smtps gets
compiled to /etc/tcprules.d/tcp.smtps.cdb when running 'qmailctl cdb'.

-Andy


On 8/16/2018 1:33 PM, Eric Broch wrote:

Andy,

Would you mind sharing your tcprules files and smtp/smtps run scripts?

Eric


On 8/16/2018 3:03 PM, Andrew Swartz wrote:

Eric,

I already had smtps installed.  The new package seems to have
overwritten the prior files.

However, that was minimally problematic because I have smtps 
configured
a little differently than standard.  I have supervise/smtps/run 
specify

a separate tcprules.d file for smtps. This allows me to have a much
stricter cipherlist for mail submission than for relay.  The 
rationale

being that I can mandate that submission clients are up to date and
using TLSv1.2.  But for relay, I have to support all the old servers
(like qmail on centos-5) having an inability to do anything 
better than

SSLv3.


Re: [qmailtoaster] status of qmail-1.03-3 CentOS 7 ?

2018-08-16 Thread Remo Mattei
So some interesting thing!!

The second server I tried to run the .1 update and it went but I could not get 
stuff back on running. Luck me I had a .tg of the bin for qmail and what I did 
I downgraded, then restore the .gz and was able to get it back alive.. One of 
the major issues was I could not send mail out (apple mail) round cube etc.. 
would not send. Once restored, I checked and all was good.. So giving it a 
second chance.. I rerun the yum command with the .1 and restarted the services 
and now it’s all working and downloaded the qmail-remote and since I had dkim 
working it’s all good again. I also added the DMARC DNS entry and here is the 
output



> On Aug 16, 2018, at 17:01, Andrew Swartz  wrote:
> 
> Eric,
> 
> That's interesting.  Those tcprules are that which was present after the
> upgrade.  I do not know if it changed them or left them default from
> qt-install.  I only copied tcp.smtp to tcp.smtps and changed the ciphers
> at the end of the line.  I definitely did not add domain keys to it.
> 
> Also, there is still a control/domainkeys directory.  It is empty.  It
> must have been created by qt-install because I did not create it.  I do
> plan on adding dkim, but I've not gotten to it yet.
> 
> -Andy
> 
> 
> On 8/16/2018 3:49 PM, Eric Broch wrote:
>> Andy,
>> 
>> I noticed your tcprules include domain keys, be aware that if you
>> upgrade to qmail-1.03-3.1 domainkeys have been removed.
>> 
>> Eric
>> 
>> 
>> On 8/16/2018 5:25 PM, Andrew Swartz wrote:
>>> Eric,
>>> 
>>> Your request prompted me to look more closely at these files.
>>> 
>>> I believe that installing qmail-1.03-3.qt.el7.x86_64.rpm overwrote my
>>> /var/qmail/supervise/smtps/run with a new one which is missing the
>>> 'export REQUIRE_AUTH=1' line.  The new one does correctly have 'export
>>> SMTPS=1'.  The new supervise/smtps/log/run names the log file
>>> "smtp-ssl", whereas I have named it "smtps".  I would argue it should be
>>> the latter for consistency, but it is clearly noncritical.
>>> 
>>> 
>>> Here is my /etc/tcprules.d/tcp.smtp:
>>> 
>>> :allow,BADMIMETYPE="",BADLOADERTYPE="M",CHKUSER_RCPTLIMIT="50",CHKUSER_WRONGRCPTLIMIT="10",NOP0FCHECK="1",QMAILQUEUE="/var/qmail/bin/simscan",DKQUEUE="/var/qmail/bin/qmail-queue.orig",DKVERIFY="DEGIJKfh",DKSIGN="/var/qmail/control/domainkeys/%/private"
>>> 
>>> 
>>> 
>>> 
>>> Here is my /etc/tcprules.d/tcp.smtps:
>>> 
>>> :allow,BADMIMETYPE="",BADLOADERTYPE="M",CHKUSER_RCPTLIMIT="50",CHKUSER_WRONGRCPTLIMIT="10",NOP0FCHECK="1",QMAILQUEUE="/var/qmail/bin/simscan",DKQUEUE="/var/qmail/bin/qmail-queue.orig",DKVERIFY="DEGIJKfh",DKSIGN="/var/qmail/control/domainkeys/%/private",TLSCIPHERS="TLSv1.2:!eNULL:!aNULL"
>>> 
>>> 
>>> 
>>> They are identical except that the smtp one does not have a TLSCIPHERS
>>> setting.  This is for two reasons:
>>> 1.  per my read of the TLS patch, if not present, it defaults to using
>>> qmail/control/tlsserverciphers. This would make qmail-smtpd and
>>> qmail-remote use the same ciphers (because tlsclientciphers is just a
>>> link to tlsserverciphers).  Since both of those are doing relay, that
>>> would seem appropriate for most setups.  Except...
>>> 2. Spamdyke does the STARTTLS for incoming (relay) mail. Therefore
>>> specifying a cipher for port 25 is useless.
>>> 
>>> If I were to continue to have port 587/STARTTLS in addition to 465/TLS,
>>> then I would have the supervise/submission/run script specify
>>> tcp.smtps.cdb so that the cipher rules are the same for these two ports
>>> because they are both handling submission and both not going through
>>> spamdyke.
>>> 
>>> 
>>> Here is my /var/qmail/supervise/smtps/run:
>>> #!/bin/sh
>>> QMAILDUID=`id -u vpopmail`
>>> NOFILESGID=`id -g vpopmail`
>>> MAXSMTPD=`cat /var/qmail/control/concurrencyincoming`
>>> SMTPD="/var/qmail/bin/qmail-smtpd"
>>> TCP_CDB="/etc/tcprules.d/tcp.smtps.cdb"
>>> HOSTNAME=`hostname`
>>> VCHKPW="/home/vpopmail/bin/vchkpw"
>>> export REQUIRE_AUTH=1
>>> export SMTPS=1
>>> 
>>> exec /usr/bin/softlimit -m 12800 \
>>>  /usr/bin/tcpserver -v -R -H -l $HOSTNAME -x $TCP_CDB -c
>>> "$MAXSMTPD" \
>>>  -u "$QMAILDUID" -g "$NOFILESGID" 0 465 \
>>>  $SMTPD $VCHKPW /bin/true 2>&1
>>> 
>>> 
>>> A line had to be added to /etc/rc.d/init.d/qmail (a near copy of line
>>> 83, placed right after it) so that /etc/tcprules.d/tcp.smtps gets
>>> compiled to /etc/tcprules.d/tcp.smtps.cdb when running 'qmailctl cdb'.
>>> 
>>> -Andy
>>> 
>>> 
>>> On 8/16/2018 1:33 PM, Eric Broch wrote:
 Andy,
 
 Would you mind sharing your tcprules files and smtp/smtps run scripts?
 
 Eric
 
 
 On 8/16/2018 3:03 PM, Andrew Swartz wrote:
> Eric,
> 
> I already had smtps installed.  The new package seems to have
> overwritten the prior files.
> 
> However, that was minimally problematic because I have smtps configured
> a little differently than standard.  I have supervise/smtps/run specify
> a separate tcprules.d file for smtps. This allows me 

Re: [qmailtoaster] status of qmail-1.03-3 CentOS 7 ?

2018-08-16 Thread Andrew Swartz
Eric,

That's interesting.  Those tcprules are that which was present after the
upgrade.  I do not know if it changed them or left them default from
qt-install.  I only copied tcp.smtp to tcp.smtps and changed the ciphers
at the end of the line.  I definitely did not add domain keys to it.

Also, there is still a control/domainkeys directory.  It is empty.  It
must have been created by qt-install because I did not create it.  I do
plan on adding dkim, but I've not gotten to it yet.

-Andy


On 8/16/2018 3:49 PM, Eric Broch wrote:
> Andy,
> 
> I noticed your tcprules include domain keys, be aware that if you
> upgrade to qmail-1.03-3.1 domainkeys have been removed.
> 
> Eric
> 
> 
> On 8/16/2018 5:25 PM, Andrew Swartz wrote:
>> Eric,
>>
>> Your request prompted me to look more closely at these files.
>>
>> I believe that installing qmail-1.03-3.qt.el7.x86_64.rpm overwrote my
>> /var/qmail/supervise/smtps/run with a new one which is missing the
>> 'export REQUIRE_AUTH=1' line.  The new one does correctly have 'export
>> SMTPS=1'.  The new supervise/smtps/log/run names the log file
>> "smtp-ssl", whereas I have named it "smtps".  I would argue it should be
>> the latter for consistency, but it is clearly noncritical.
>>
>>
>> Here is my /etc/tcprules.d/tcp.smtp:
>>
>> :allow,BADMIMETYPE="",BADLOADERTYPE="M",CHKUSER_RCPTLIMIT="50",CHKUSER_WRONGRCPTLIMIT="10",NOP0FCHECK="1",QMAILQUEUE="/var/qmail/bin/simscan",DKQUEUE="/var/qmail/bin/qmail-queue.orig",DKVERIFY="DEGIJKfh",DKSIGN="/var/qmail/control/domainkeys/%/private"
>>
>>
>>
>>
>> Here is my /etc/tcprules.d/tcp.smtps:
>>
>> :allow,BADMIMETYPE="",BADLOADERTYPE="M",CHKUSER_RCPTLIMIT="50",CHKUSER_WRONGRCPTLIMIT="10",NOP0FCHECK="1",QMAILQUEUE="/var/qmail/bin/simscan",DKQUEUE="/var/qmail/bin/qmail-queue.orig",DKVERIFY="DEGIJKfh",DKSIGN="/var/qmail/control/domainkeys/%/private",TLSCIPHERS="TLSv1.2:!eNULL:!aNULL"
>>
>>
>>
>> They are identical except that the smtp one does not have a TLSCIPHERS
>> setting.  This is for two reasons:
>> 1.  per my read of the TLS patch, if not present, it defaults to using
>> qmail/control/tlsserverciphers. This would make qmail-smtpd and
>> qmail-remote use the same ciphers (because tlsclientciphers is just a
>> link to tlsserverciphers).  Since both of those are doing relay, that
>> would seem appropriate for most setups.  Except...
>> 2. Spamdyke does the STARTTLS for incoming (relay) mail. Therefore
>> specifying a cipher for port 25 is useless.
>>
>> If I were to continue to have port 587/STARTTLS in addition to 465/TLS,
>> then I would have the supervise/submission/run script specify
>> tcp.smtps.cdb so that the cipher rules are the same for these two ports
>> because they are both handling submission and both not going through
>> spamdyke.
>>
>>
>> Here is my /var/qmail/supervise/smtps/run:
>> #!/bin/sh
>> QMAILDUID=`id -u vpopmail`
>> NOFILESGID=`id -g vpopmail`
>> MAXSMTPD=`cat /var/qmail/control/concurrencyincoming`
>> SMTPD="/var/qmail/bin/qmail-smtpd"
>> TCP_CDB="/etc/tcprules.d/tcp.smtps.cdb"
>> HOSTNAME=`hostname`
>> VCHKPW="/home/vpopmail/bin/vchkpw"
>> export REQUIRE_AUTH=1
>> export SMTPS=1
>>
>> exec /usr/bin/softlimit -m 12800 \
>>  /usr/bin/tcpserver -v -R -H -l $HOSTNAME -x $TCP_CDB -c
>> "$MAXSMTPD" \
>>  -u "$QMAILDUID" -g "$NOFILESGID" 0 465 \
>>  $SMTPD $VCHKPW /bin/true 2>&1
>>
>>
>> A line had to be added to /etc/rc.d/init.d/qmail (a near copy of line
>> 83, placed right after it) so that /etc/tcprules.d/tcp.smtps gets
>> compiled to /etc/tcprules.d/tcp.smtps.cdb when running 'qmailctl cdb'.
>>
>> -Andy
>>
>>
>> On 8/16/2018 1:33 PM, Eric Broch wrote:
>>> Andy,
>>>
>>> Would you mind sharing your tcprules files and smtp/smtps run scripts?
>>>
>>> Eric
>>>
>>>
>>> On 8/16/2018 3:03 PM, Andrew Swartz wrote:
 Eric,

 I already had smtps installed.  The new package seems to have
 overwritten the prior files.

 However, that was minimally problematic because I have smtps configured
 a little differently than standard.  I have supervise/smtps/run specify
 a separate tcprules.d file for smtps. This allows me to have a much
 stricter cipherlist for mail submission than for relay.  The rationale
 being that I can mandate that submission clients are up to date and
 using TLSv1.2.  But for relay, I have to support all the old servers
 (like qmail on centos-5) having an inability to do anything better than
 SSLv3.

 I'm not wild about the cipherlist which installed, but that was easy to
 change.  My understanding is that the order of the ciphers in the list
 is important in that openssl interprets the list in a most-preferred to
 least-preferred order.  The list which installed has several SSLv3
 ciphers very early in the list.

 While one can specify exact ciphers, openssl also allows specifying the
 cipher "suites" instead
 (https://www.openssl.org/docs/manmaster/man1/ciphers.html).  I think
 this is much 

Re: [qmailtoaster] status of qmail-1.03-3 CentOS 7 ?

2018-08-16 Thread Eric Broch

Andy,

I noticed your tcprules include domain keys, be aware that if you 
upgrade to qmail-1.03-3.1 domainkeys have been removed.


Eric


On 8/16/2018 5:25 PM, Andrew Swartz wrote:

Eric,

Your request prompted me to look more closely at these files.

I believe that installing qmail-1.03-3.qt.el7.x86_64.rpm overwrote my
/var/qmail/supervise/smtps/run with a new one which is missing the
'export REQUIRE_AUTH=1' line.  The new one does correctly have 'export
SMTPS=1'.  The new supervise/smtps/log/run names the log file
"smtp-ssl", whereas I have named it "smtps".  I would argue it should be
the latter for consistency, but it is clearly noncritical.


Here is my /etc/tcprules.d/tcp.smtp:

:allow,BADMIMETYPE="",BADLOADERTYPE="M",CHKUSER_RCPTLIMIT="50",CHKUSER_WRONGRCPTLIMIT="10",NOP0FCHECK="1",QMAILQUEUE="/var/qmail/bin/simscan",DKQUEUE="/var/qmail/bin/qmail-queue.orig",DKVERIFY="DEGIJKfh",DKSIGN="/var/qmail/control/domainkeys/%/private"



Here is my /etc/tcprules.d/tcp.smtps:

:allow,BADMIMETYPE="",BADLOADERTYPE="M",CHKUSER_RCPTLIMIT="50",CHKUSER_WRONGRCPTLIMIT="10",NOP0FCHECK="1",QMAILQUEUE="/var/qmail/bin/simscan",DKQUEUE="/var/qmail/bin/qmail-queue.orig",DKVERIFY="DEGIJKfh",DKSIGN="/var/qmail/control/domainkeys/%/private",TLSCIPHERS="TLSv1.2:!eNULL:!aNULL"


They are identical except that the smtp one does not have a TLSCIPHERS
setting.  This is for two reasons:
1.  per my read of the TLS patch, if not present, it defaults to using
qmail/control/tlsserverciphers. This would make qmail-smtpd and
qmail-remote use the same ciphers (because tlsclientciphers is just a
link to tlsserverciphers).  Since both of those are doing relay, that
would seem appropriate for most setups.  Except...
2. Spamdyke does the STARTTLS for incoming (relay) mail. Therefore
specifying a cipher for port 25 is useless.

If I were to continue to have port 587/STARTTLS in addition to 465/TLS,
then I would have the supervise/submission/run script specify
tcp.smtps.cdb so that the cipher rules are the same for these two ports
because they are both handling submission and both not going through
spamdyke.


Here is my /var/qmail/supervise/smtps/run:
#!/bin/sh
QMAILDUID=`id -u vpopmail`
NOFILESGID=`id -g vpopmail`
MAXSMTPD=`cat /var/qmail/control/concurrencyincoming`
SMTPD="/var/qmail/bin/qmail-smtpd"
TCP_CDB="/etc/tcprules.d/tcp.smtps.cdb"
HOSTNAME=`hostname`
VCHKPW="/home/vpopmail/bin/vchkpw"
export REQUIRE_AUTH=1
export SMTPS=1

exec /usr/bin/softlimit -m 12800 \
     /usr/bin/tcpserver -v -R -H -l $HOSTNAME -x $TCP_CDB -c "$MAXSMTPD" \
     -u "$QMAILDUID" -g "$NOFILESGID" 0 465 \
     $SMTPD $VCHKPW /bin/true 2>&1


A line had to be added to /etc/rc.d/init.d/qmail (a near copy of line
83, placed right after it) so that /etc/tcprules.d/tcp.smtps gets
compiled to /etc/tcprules.d/tcp.smtps.cdb when running 'qmailctl cdb'.

-Andy


On 8/16/2018 1:33 PM, Eric Broch wrote:

Andy,

Would you mind sharing your tcprules files and smtp/smtps run scripts?

Eric


On 8/16/2018 3:03 PM, Andrew Swartz wrote:

Eric,

I already had smtps installed.  The new package seems to have
overwritten the prior files.

However, that was minimally problematic because I have smtps configured
a little differently than standard.  I have supervise/smtps/run specify
a separate tcprules.d file for smtps. This allows me to have a much
stricter cipherlist for mail submission than for relay.  The rationale
being that I can mandate that submission clients are up to date and
using TLSv1.2.  But for relay, I have to support all the old servers
(like qmail on centos-5) having an inability to do anything better than
SSLv3.

I'm not wild about the cipherlist which installed, but that was easy to
change.  My understanding is that the order of the ciphers in the list
is important in that openssl interprets the list in a most-preferred to
least-preferred order.  The list which installed has several SSLv3
ciphers very early in the list.

While one can specify exact ciphers, openssl also allows specifying the
cipher "suites" instead
(https://www.openssl.org/docs/manmaster/man1/ciphers.html).  I think
this is much more intuitive. I'm currently playing around with 'openssl
cipherlist' to get my preferred content and order correct.  I'm
currently leaning toward:

'TLSv1.2:SSLv3:!eNULL:!aNULL'    for smtp

and

'TLSv1.2:!eNULL:!aNULL'    for smtps

The important effect of my smtp list is that all of the TLSv1.2 ciphers
are preferred/attempted before reverting to SSLv3 ciphers.

Here is a paste-able command with human readable output to see the
content and order of the results (you will need to widen the terminal
window to see it correctly):

openssl ciphers -v 'TLSv1.2:SSLv3:!eNULL:!aNULL' | awk '{ printf "%-29s
%-9s  %-13s  %-10s  %-17s  %-s\n",$1,$2,$3,$4,$5,$6 }'

Playing with this has taught me some interesting things (which I do
vaguely remember reading elsewhere at some point).  First, there are no
TLSv1.1 ciphers.  Also, the TLSv1 ciphers are the same ciphers as SSLv3.
 

Re: [qmailtoaster] status of qmail-1.03-3 CentOS 7 ?

2018-08-16 Thread Andrew Swartz
Eric,

Your request prompted me to look more closely at these files.

I believe that installing qmail-1.03-3.qt.el7.x86_64.rpm overwrote my
/var/qmail/supervise/smtps/run with a new one which is missing the
'export REQUIRE_AUTH=1' line.  The new one does correctly have 'export
SMTPS=1'.  The new supervise/smtps/log/run names the log file
"smtp-ssl", whereas I have named it "smtps".  I would argue it should be
the latter for consistency, but it is clearly noncritical.


Here is my /etc/tcprules.d/tcp.smtp:

:allow,BADMIMETYPE="",BADLOADERTYPE="M",CHKUSER_RCPTLIMIT="50",CHKUSER_WRONGRCPTLIMIT="10",NOP0FCHECK="1",QMAILQUEUE="/var/qmail/bin/simscan",DKQUEUE="/var/qmail/bin/qmail-queue.orig",DKVERIFY="DEGIJKfh",DKSIGN="/var/qmail/control/domainkeys/%/private"



Here is my /etc/tcprules.d/tcp.smtps:

:allow,BADMIMETYPE="",BADLOADERTYPE="M",CHKUSER_RCPTLIMIT="50",CHKUSER_WRONGRCPTLIMIT="10",NOP0FCHECK="1",QMAILQUEUE="/var/qmail/bin/simscan",DKQUEUE="/var/qmail/bin/qmail-queue.orig",DKVERIFY="DEGIJKfh",DKSIGN="/var/qmail/control/domainkeys/%/private",TLSCIPHERS="TLSv1.2:!eNULL:!aNULL"


They are identical except that the smtp one does not have a TLSCIPHERS
setting.  This is for two reasons:
1.  per my read of the TLS patch, if not present, it defaults to using
qmail/control/tlsserverciphers. This would make qmail-smtpd and
qmail-remote use the same ciphers (because tlsclientciphers is just a
link to tlsserverciphers).  Since both of those are doing relay, that
would seem appropriate for most setups.  Except...
2. Spamdyke does the STARTTLS for incoming (relay) mail. Therefore
specifying a cipher for port 25 is useless.

If I were to continue to have port 587/STARTTLS in addition to 465/TLS,
then I would have the supervise/submission/run script specify
tcp.smtps.cdb so that the cipher rules are the same for these two ports
because they are both handling submission and both not going through
spamdyke.


Here is my /var/qmail/supervise/smtps/run:
#!/bin/sh
QMAILDUID=`id -u vpopmail`
NOFILESGID=`id -g vpopmail`
MAXSMTPD=`cat /var/qmail/control/concurrencyincoming`
SMTPD="/var/qmail/bin/qmail-smtpd"
TCP_CDB="/etc/tcprules.d/tcp.smtps.cdb"
HOSTNAME=`hostname`
VCHKPW="/home/vpopmail/bin/vchkpw"
export REQUIRE_AUTH=1
export SMTPS=1

exec /usr/bin/softlimit -m 12800 \
    /usr/bin/tcpserver -v -R -H -l $HOSTNAME -x $TCP_CDB -c "$MAXSMTPD" \
    -u "$QMAILDUID" -g "$NOFILESGID" 0 465 \
    $SMTPD $VCHKPW /bin/true 2>&1


A line had to be added to /etc/rc.d/init.d/qmail (a near copy of line
83, placed right after it) so that /etc/tcprules.d/tcp.smtps gets
compiled to /etc/tcprules.d/tcp.smtps.cdb when running 'qmailctl cdb'.

-Andy


On 8/16/2018 1:33 PM, Eric Broch wrote:
> Andy,
>
> Would you mind sharing your tcprules files and smtp/smtps run scripts?
>
> Eric
>
>
> On 8/16/2018 3:03 PM, Andrew Swartz wrote:
>> Eric,
>>
>> I already had smtps installed.  The new package seems to have
>> overwritten the prior files.
>>
>> However, that was minimally problematic because I have smtps configured
>> a little differently than standard.  I have supervise/smtps/run specify
>> a separate tcprules.d file for smtps. This allows me to have a much
>> stricter cipherlist for mail submission than for relay.  The rationale
>> being that I can mandate that submission clients are up to date and
>> using TLSv1.2.  But for relay, I have to support all the old servers
>> (like qmail on centos-5) having an inability to do anything better than
>> SSLv3.
>>
>> I'm not wild about the cipherlist which installed, but that was easy to
>> change.  My understanding is that the order of the ciphers in the list
>> is important in that openssl interprets the list in a most-preferred to
>> least-preferred order.  The list which installed has several SSLv3
>> ciphers very early in the list.
>>
>> While one can specify exact ciphers, openssl also allows specifying the
>> cipher "suites" instead
>> (https://www.openssl.org/docs/manmaster/man1/ciphers.html).  I think
>> this is much more intuitive. I'm currently playing around with 'openssl
>> cipherlist' to get my preferred content and order correct.  I'm
>> currently leaning toward:
>>
>> 'TLSv1.2:SSLv3:!eNULL:!aNULL'    for smtp
>>
>> and
>>
>> 'TLSv1.2:!eNULL:!aNULL'    for smtps
>>
>> The important effect of my smtp list is that all of the TLSv1.2 ciphers
>> are preferred/attempted before reverting to SSLv3 ciphers.
>>
>> Here is a paste-able command with human readable output to see the
>> content and order of the results (you will need to widen the terminal
>> window to see it correctly):
>>
>> openssl ciphers -v 'TLSv1.2:SSLv3:!eNULL:!aNULL' | awk '{ printf "%-29s
>> %-9s  %-13s  %-10s  %-17s  %-s\n",$1,$2,$3,$4,$5,$6 }'
>>
>> Playing with this has taught me some interesting things (which I do
>> vaguely remember reading elsewhere at some point).  First, there are no
>> TLSv1.1 ciphers.  Also, the TLSv1 ciphers are the same ciphers as SSLv3.
>>   Therefore listing 'TLSv1:!SSLv3' yields no 

Re: [qmailtoaster] status of qmail-1.03-3 CentOS 7 ?

2018-08-16 Thread Eric Broch

Remo,

In the '/var/qmail/supervise/smtps/run' file it should be 'export SMTPS=1'

client should be configure with ssl/tls, port 465, and normal password.

Eric


On 8/16/2018 3:59 PM, Remo Mattei wrote:

Here is what I had to change since by default did not change it..

On my smtps run file I had to change this

export SMTPS=1

To this export SMTPAUTH=“!”

To get it to work.

Remo



On Aug 16, 2018, at 14:33, Eric Broch > wrote:


Andy,

Would you mind sharing your tcprules files and smtp/smtps run scripts?

Eric


On 8/16/2018 3:03 PM, Andrew Swartz wrote:

Eric,

I already had smtps installed.  The new package seems to have
overwritten the prior files.

However, that was minimally problematic because I have smtps configured
a little differently than standard.  I have supervise/smtps/run specify
a separate tcprules.d file for smtps. This allows me to have a much
stricter cipherlist for mail submission than for relay.  The rationale
being that I can mandate that submission clients are up to date and
using TLSv1.2.  But for relay, I have to support all the old servers
(like qmail on centos-5) having an inability to do anything better than
SSLv3.

I'm not wild about the cipherlist which installed, but that was easy to
change.  My understanding is that the order of the ciphers in the list
is important in that openssl interprets the list in a most-preferred to
least-preferred order.  The list which installed has several SSLv3
ciphers very early in the list.

While one can specify exact ciphers, openssl also allows specifying the
cipher "suites" instead
(https://www.openssl.org/docs/manmaster/man1/ciphers.html).  I think
this is much more intuitive. I'm currently playing around with 'openssl
cipherlist' to get my preferred content and order correct.  I'm
currently leaning toward:

'TLSv1.2:SSLv3:!eNULL:!aNULL'for smtp

and

'TLSv1.2:!eNULL:!aNULL'for smtps

The important effect of my smtp list is that all of the TLSv1.2 ciphers
are preferred/attempted before reverting to SSLv3 ciphers.

Here is a paste-able command with human readable output to see the
content and order of the results (you will need to widen the terminal
window to see it correctly):

openssl ciphers -v 'TLSv1.2:SSLv3:!eNULL:!aNULL' | awk '{ printf "%-29s
%-9s  %-13s  %-10s  %-17s  %-s\n",$1,$2,$3,$4,$5,$6 }'

Playing with this has taught me some interesting things (which I do
vaguely remember reading elsewhere at some point).  First, there are no
TLSv1.1 ciphers.  Also, the TLSv1 ciphers are the same ciphers as SSLv3.
 Therefore listing 'TLSv1:!SSLv3' yields no ciphers. The take-home
message is that you either get TLSv1.2 or SSLv3; there is no in-between
for the ciphers.  That's why my above lists omit TLSv1.1 and TLSv1. My
understanding is that TLSv1 and TLSv1.1 had improvements in the protocol
but not the ciphers.

I refuse to use ALL, LOW, etc for creating the cipher list because they
are extremely opaque.  If a notice comes out saying "no one should use
SSLv3", these vague terms do not tell me if I'm using that.  I see no
downside to explicitly specifying the cipher suites.  If you want to be
insecure, you could specify SSLv2.  When the new openssl 1.1.1 comes out
and supports TLSv1.3 (which should happen any day), then I'll explicitly
add that to my cipherlist. If nothing else, it will prompt me to review
the list occasionally.

That merely addresses the ciphers.  There is also significance to the
SSL and TLS protocols, but there appears to be no qmail setting for
those.  It would be far better to use TLSv1 protocol than SSLv3 protocol
even though the ciphers are identical.  I'm gonna do some testing with
changing my qmail cipherlist and connecting via s_client with explicit
protocols and see how much effect the specified cipherlist has upon the
protocol.

This was intended to be a short email.  Sorry.  "I'm sorry this letter
is so long, I didn't have time to compose a short one."

I've had a lot of time this last week to work on this, but I now have
very little time until next week.  I'll consider testing 1.03-3.1 when I
get another chunk of time.

-Andy



On 8/16/2018 9:35 AM, Eric Broch wrote:

Thanks, Andy.

It installed SMTPS, correct?

If you felt bold, I needed some folks to test 1.03-3.1. ;-)

Eric


On 8/16/2018 11:28 AM, Andrew Swartz wrote:

Eric,

Thanks for the help.  I installed qmail-1.03-3.qt.el7.x86_64.rpm 
without

difficulty and it seems to be fully functional.

-Andy


On 8/15/2018 9:01 AM, Eric Broch wrote:
I ran this 1.03-3 version for several months with no issues, and 
haven't

heard anything from the community on it.

I personally upgraded to 1.03-3.1 (in the development tree) now on my
own production machine. In this version I take all the patches 
(below),
carrying over some, updating some and adding extras, and apply 
them in
an orderly fashion instead of using one big patch because IMHO 
opinion

patching will be easier to maintain this way. I'm going to create
1.03-3.2 in 

Re: [qmailtoaster] status of qmail-1.03-3 CentOS 7 ?

2018-08-16 Thread Remo Mattei
Here is what I had to change since by default did not change it..

On my smtps run file I had to change this

export SMTPS=1

To this export SMTPAUTH=“!”

To get it to work.

Remo



> On Aug 16, 2018, at 14:33, Eric Broch  wrote:
> 
> Andy,
> 
> Would you mind sharing your tcprules files and smtp/smtps run scripts?
> 
> Eric
> 
> 
> On 8/16/2018 3:03 PM, Andrew Swartz wrote:
>> Eric,
>> 
>> I already had smtps installed.  The new package seems to have
>> overwritten the prior files.
>> 
>> However, that was minimally problematic because I have smtps configured
>> a little differently than standard.  I have supervise/smtps/run specify
>> a separate tcprules.d file for smtps. This allows me to have a much
>> stricter cipherlist for mail submission than for relay.  The rationale
>> being that I can mandate that submission clients are up to date and
>> using TLSv1.2.  But for relay, I have to support all the old servers
>> (like qmail on centos-5) having an inability to do anything better than
>> SSLv3.
>> 
>> I'm not wild about the cipherlist which installed, but that was easy to
>> change.  My understanding is that the order of the ciphers in the list
>> is important in that openssl interprets the list in a most-preferred to
>> least-preferred order.  The list which installed has several SSLv3
>> ciphers very early in the list.
>> 
>> While one can specify exact ciphers, openssl also allows specifying the
>> cipher "suites" instead
>> (https://www.openssl.org/docs/manmaster/man1/ciphers.html).  I think
>> this is much more intuitive. I'm currently playing around with 'openssl
>> cipherlist' to get my preferred content and order correct.  I'm
>> currently leaning toward:
>> 
>> 'TLSv1.2:SSLv3:!eNULL:!aNULL'for smtp
>> 
>> and
>> 
>> 'TLSv1.2:!eNULL:!aNULL'  for smtps
>> 
>> The important effect of my smtp list is that all of the TLSv1.2 ciphers
>> are preferred/attempted before reverting to SSLv3 ciphers.
>> 
>> Here is a paste-able command with human readable output to see the
>> content and order of the results (you will need to widen the terminal
>> window to see it correctly):
>> 
>> openssl ciphers -v 'TLSv1.2:SSLv3:!eNULL:!aNULL' | awk '{ printf "%-29s
>> %-9s  %-13s  %-10s  %-17s  %-s\n",$1,$2,$3,$4,$5,$6 }'
>> 
>> Playing with this has taught me some interesting things (which I do
>> vaguely remember reading elsewhere at some point).  First, there are no
>> TLSv1.1 ciphers.  Also, the TLSv1 ciphers are the same ciphers as SSLv3.
>>  Therefore listing 'TLSv1:!SSLv3' yields no ciphers. The take-home
>> message is that you either get TLSv1.2 or SSLv3; there is no in-between
>> for the ciphers.  That's why my above lists omit TLSv1.1 and TLSv1. My
>> understanding is that TLSv1 and TLSv1.1 had improvements in the protocol
>> but not the ciphers.
>> 
>> I refuse to use ALL, LOW, etc for creating the cipher list because they
>> are extremely opaque.  If a notice comes out saying "no one should use
>> SSLv3", these vague terms do not tell me if I'm using that.  I see no
>> downside to explicitly specifying the cipher suites.  If you want to be
>> insecure, you could specify SSLv2.  When the new openssl 1.1.1 comes out
>> and supports TLSv1.3 (which should happen any day), then I'll explicitly
>> add that to my cipherlist. If nothing else, it will prompt me to review
>> the list occasionally.
>> 
>> That merely addresses the ciphers.  There is also significance to the
>> SSL and TLS protocols, but there appears to be no qmail setting for
>> those.  It would be far better to use TLSv1 protocol than SSLv3 protocol
>> even though the ciphers are identical.  I'm gonna do some testing with
>> changing my qmail cipherlist and connecting via s_client with explicit
>> protocols and see how much effect the specified cipherlist has upon the
>> protocol.
>> 
>> This was intended to be a short email.  Sorry.  "I'm sorry this letter
>> is so long, I didn't have time to compose a short one."
>> 
>> I've had a lot of time this last week to work on this, but I now have
>> very little time until next week.  I'll consider testing 1.03-3.1 when I
>> get another chunk of time.
>> 
>> -Andy
>> 
>> 
>> 
>> On 8/16/2018 9:35 AM, Eric Broch wrote:
>>> Thanks, Andy.
>>> 
>>> It installed SMTPS, correct?
>>> 
>>> If you felt bold, I needed some folks to test 1.03-3.1. ;-)
>>> 
>>> Eric
>>> 
>>> 
>>> On 8/16/2018 11:28 AM, Andrew Swartz wrote:
 Eric,
 
 Thanks for the help.  I installed qmail-1.03-3.qt.el7.x86_64.rpm without
 difficulty and it seems to be fully functional.
 
 -Andy
 
 
 On 8/15/2018 9:01 AM, Eric Broch wrote:
> I ran this 1.03-3 version for several months with no issues, and haven't
> heard anything from the community on it.
> 
> I personally upgraded to 1.03-3.1 (in the development tree) now on my
> own production machine. In this version I take all the patches (below),
> carrying over some, updating some and adding extras, and apply 

Re: [qmailtoaster] status of qmail-1.03-3 CentOS 7 ?

2018-08-16 Thread Eric Broch

Andy,

Would you mind sharing your tcprules files and smtp/smtps run scripts?

Eric


On 8/16/2018 3:03 PM, Andrew Swartz wrote:

Eric,

I already had smtps installed.  The new package seems to have
overwritten the prior files.

However, that was minimally problematic because I have smtps configured
a little differently than standard.  I have supervise/smtps/run specify
a separate tcprules.d file for smtps. This allows me to have a much
stricter cipherlist for mail submission than for relay.  The rationale
being that I can mandate that submission clients are up to date and
using TLSv1.2.  But for relay, I have to support all the old servers
(like qmail on centos-5) having an inability to do anything better than
SSLv3.

I'm not wild about the cipherlist which installed, but that was easy to
change.  My understanding is that the order of the ciphers in the list
is important in that openssl interprets the list in a most-preferred to
least-preferred order.  The list which installed has several SSLv3
ciphers very early in the list.

While one can specify exact ciphers, openssl also allows specifying the
cipher "suites" instead
(https://www.openssl.org/docs/manmaster/man1/ciphers.html).  I think
this is much more intuitive. I'm currently playing around with 'openssl
cipherlist' to get my preferred content and order correct.  I'm
currently leaning toward:

'TLSv1.2:SSLv3:!eNULL:!aNULL'   for smtp

and

'TLSv1.2:!eNULL:!aNULL' for smtps

The important effect of my smtp list is that all of the TLSv1.2 ciphers
are preferred/attempted before reverting to SSLv3 ciphers.

Here is a paste-able command with human readable output to see the
content and order of the results (you will need to widen the terminal
window to see it correctly):

openssl ciphers -v 'TLSv1.2:SSLv3:!eNULL:!aNULL' | awk '{ printf "%-29s
%-9s  %-13s  %-10s  %-17s  %-s\n",$1,$2,$3,$4,$5,$6 }'

Playing with this has taught me some interesting things (which I do
vaguely remember reading elsewhere at some point).  First, there are no
TLSv1.1 ciphers.  Also, the TLSv1 ciphers are the same ciphers as SSLv3.
  Therefore listing 'TLSv1:!SSLv3' yields no ciphers. The take-home
message is that you either get TLSv1.2 or SSLv3; there is no in-between
for the ciphers.  That's why my above lists omit TLSv1.1 and TLSv1. My
understanding is that TLSv1 and TLSv1.1 had improvements in the protocol
but not the ciphers.

I refuse to use ALL, LOW, etc for creating the cipher list because they
are extremely opaque.  If a notice comes out saying "no one should use
SSLv3", these vague terms do not tell me if I'm using that.  I see no
downside to explicitly specifying the cipher suites.  If you want to be
insecure, you could specify SSLv2.  When the new openssl 1.1.1 comes out
and supports TLSv1.3 (which should happen any day), then I'll explicitly
add that to my cipherlist. If nothing else, it will prompt me to review
the list occasionally.

That merely addresses the ciphers.  There is also significance to the
SSL and TLS protocols, but there appears to be no qmail setting for
those.  It would be far better to use TLSv1 protocol than SSLv3 protocol
even though the ciphers are identical.  I'm gonna do some testing with
changing my qmail cipherlist and connecting via s_client with explicit
protocols and see how much effect the specified cipherlist has upon the
protocol.

This was intended to be a short email.  Sorry.  "I'm sorry this letter
is so long, I didn't have time to compose a short one."

I've had a lot of time this last week to work on this, but I now have
very little time until next week.  I'll consider testing 1.03-3.1 when I
get another chunk of time.

-Andy



On 8/16/2018 9:35 AM, Eric Broch wrote:

Thanks, Andy.

It installed SMTPS, correct?

If you felt bold, I needed some folks to test 1.03-3.1. ;-)

Eric


On 8/16/2018 11:28 AM, Andrew Swartz wrote:

Eric,

Thanks for the help.  I installed qmail-1.03-3.qt.el7.x86_64.rpm without
difficulty and it seems to be fully functional.

-Andy


On 8/15/2018 9:01 AM, Eric Broch wrote:

I ran this 1.03-3 version for several months with no issues, and haven't
heard anything from the community on it.

I personally upgraded to 1.03-3.1 (in the development tree) now on my
own production machine. In this version I take all the patches (below),
carrying over some, updating some and adding extras, and apply them in
an orderly fashion instead of using one big patch because IMHO opinion
patching will be easier to maintain this way. I'm going to create
1.03-3.2 in which I'll add to qmail-smtpd more extensive logging mainly
to indicate a message's having been queued. And, I'd also like to
possibly add logging to qmail-remote.

I was motivated to update/add patches by the work of

Roberto Puzzanghera ,


Erwin Hoffmann ,

Frederik Vermeulen 

Manvendra Bhangui 

Kyle Wheeler 

Re: [qmailtoaster] status of qmail-1.03-3 CentOS 7 ?

2018-08-16 Thread Andrew Swartz
Eric,

I already had smtps installed.  The new package seems to have
overwritten the prior files.

However, that was minimally problematic because I have smtps configured
a little differently than standard.  I have supervise/smtps/run specify
a separate tcprules.d file for smtps. This allows me to have a much
stricter cipherlist for mail submission than for relay.  The rationale
being that I can mandate that submission clients are up to date and
using TLSv1.2.  But for relay, I have to support all the old servers
(like qmail on centos-5) having an inability to do anything better than
SSLv3.

I'm not wild about the cipherlist which installed, but that was easy to
change.  My understanding is that the order of the ciphers in the list
is important in that openssl interprets the list in a most-preferred to
least-preferred order.  The list which installed has several SSLv3
ciphers very early in the list.

While one can specify exact ciphers, openssl also allows specifying the
cipher "suites" instead
(https://www.openssl.org/docs/manmaster/man1/ciphers.html).  I think
this is much more intuitive. I'm currently playing around with 'openssl
cipherlist' to get my preferred content and order correct.  I'm
currently leaning toward:

'TLSv1.2:SSLv3:!eNULL:!aNULL'   for smtp

and

'TLSv1.2:!eNULL:!aNULL' for smtps

The important effect of my smtp list is that all of the TLSv1.2 ciphers
are preferred/attempted before reverting to SSLv3 ciphers.

Here is a paste-able command with human readable output to see the
content and order of the results (you will need to widen the terminal
window to see it correctly):

openssl ciphers -v 'TLSv1.2:SSLv3:!eNULL:!aNULL' | awk '{ printf "%-29s
%-9s  %-13s  %-10s  %-17s  %-s\n",$1,$2,$3,$4,$5,$6 }'

Playing with this has taught me some interesting things (which I do
vaguely remember reading elsewhere at some point).  First, there are no
TLSv1.1 ciphers.  Also, the TLSv1 ciphers are the same ciphers as SSLv3.
 Therefore listing 'TLSv1:!SSLv3' yields no ciphers. The take-home
message is that you either get TLSv1.2 or SSLv3; there is no in-between
for the ciphers.  That's why my above lists omit TLSv1.1 and TLSv1. My
understanding is that TLSv1 and TLSv1.1 had improvements in the protocol
but not the ciphers.

I refuse to use ALL, LOW, etc for creating the cipher list because they
are extremely opaque.  If a notice comes out saying "no one should use
SSLv3", these vague terms do not tell me if I'm using that.  I see no
downside to explicitly specifying the cipher suites.  If you want to be
insecure, you could specify SSLv2.  When the new openssl 1.1.1 comes out
and supports TLSv1.3 (which should happen any day), then I'll explicitly
add that to my cipherlist. If nothing else, it will prompt me to review
the list occasionally.

That merely addresses the ciphers.  There is also significance to the
SSL and TLS protocols, but there appears to be no qmail setting for
those.  It would be far better to use TLSv1 protocol than SSLv3 protocol
even though the ciphers are identical.  I'm gonna do some testing with
changing my qmail cipherlist and connecting via s_client with explicit
protocols and see how much effect the specified cipherlist has upon the
protocol.

This was intended to be a short email.  Sorry.  "I'm sorry this letter
is so long, I didn't have time to compose a short one."

I've had a lot of time this last week to work on this, but I now have
very little time until next week.  I'll consider testing 1.03-3.1 when I
get another chunk of time.

-Andy



On 8/16/2018 9:35 AM, Eric Broch wrote:
> Thanks, Andy.
> 
> It installed SMTPS, correct?
> 
> If you felt bold, I needed some folks to test 1.03-3.1. ;-)
> 
> Eric
> 
> 
> On 8/16/2018 11:28 AM, Andrew Swartz wrote:
>> Eric,
>>
>> Thanks for the help.  I installed qmail-1.03-3.qt.el7.x86_64.rpm without
>> difficulty and it seems to be fully functional.
>>
>> -Andy
>>
>>
>> On 8/15/2018 9:01 AM, Eric Broch wrote:
>>> I ran this 1.03-3 version for several months with no issues, and haven't
>>> heard anything from the community on it.
>>>
>>> I personally upgraded to 1.03-3.1 (in the development tree) now on my
>>> own production machine. In this version I take all the patches (below),
>>> carrying over some, updating some and adding extras, and apply them in
>>> an orderly fashion instead of using one big patch because IMHO opinion
>>> patching will be easier to maintain this way. I'm going to create
>>> 1.03-3.2 in which I'll add to qmail-smtpd more extensive logging mainly
>>> to indicate a message's having been queued. And, I'd also like to
>>> possibly add logging to qmail-remote.
>>>
>>> I was motivated to update/add patches by the work of
>>>
>>> Roberto Puzzanghera ,
>>> 
>>>
>>> Erwin Hoffmann ,
>>>
>>> Frederik Vermeulen 
>>>
>>> Manvendra Bhangui 
>>>
>>> Kyle Wheeler 

Re: [qmailtoaster] status of qmail-1.03-3 CentOS 7 ?

2018-08-16 Thread Remo Mattei
I will try on my other qmail 7 server.

Let you know. 

 dal mio iPhone X

> Il giorno 16 ago 2018, alle ore 10:35, Eric Broch  
> ha scritto:
> 
> Thanks, Andy.
> 
> It installed SMTPS, correct?
> 
> If you felt bold, I needed some folks to test 1.03-3.1. ;-)
> 
> Eric
> 
> 
>> On 8/16/2018 11:28 AM, Andrew Swartz wrote:
>> Eric,
>> 
>> Thanks for the help.  I installed qmail-1.03-3.qt.el7.x86_64.rpm without
>> difficulty and it seems to be fully functional.
>> 
>> -Andy
>> 
>> 
>>> On 8/15/2018 9:01 AM, Eric Broch wrote:
>>> I ran this 1.03-3 version for several months with no issues, and haven't
>>> heard anything from the community on it.
>>> 
>>> I personally upgraded to 1.03-3.1 (in the development tree) now on my
>>> own production machine. In this version I take all the patches (below),
>>> carrying over some, updating some and adding extras, and apply them in
>>> an orderly fashion instead of using one big patch because IMHO opinion
>>> patching will be easier to maintain this way. I'm going to create
>>> 1.03-3.2 in which I'll add to qmail-smtpd more extensive logging mainly
>>> to indicate a message's having been queued. And, I'd also like to
>>> possibly add logging to qmail-remote.
>>> 
>>> I was motivated to update/add patches by the work of
>>> 
>>> Roberto Puzzanghera ,
>>> 
>>> 
>>> Erwin Hoffmann ,
>>> 
>>> Frederik Vermeulen 
>>> 
>>> Manvendra Bhangui 
>>> 
>>> Kyle Wheeler 
>>> 
>>> among others.
>>> 
>>> 
>>> 
>>> Patches
>>> 01 - netqmail-1.06 patch (Change qmail-1.03 to netqmail-1.06,
>>> http://www.qmail.org/netqmail/) - update
>>> 02 - chkuser 2.09 patch (Check 'mail from' and 'rcpt to',
>>> http://opensource.interazioni.it/qmail/chkuser/download.html) - carryover
>>> 03 - change location of vpopmail development libraries - carryover
>>> 04 - big concurrency (allows greater number of deliveries by qmail,
>>> above 255) - new
>>> 05 - big concurrency fix (fixes compiler error if number of
>>> concurrencies is set above 509) - new
>>> 06 - custom patch (adds error logging to simscan) - carryover
>>> 07 - maildir++ patch (adds quota support to qmail-pop3d and qmail-local)
>>> - carryover
>>> 08 - tap extended (Email Archive) - update
>>> 09 - spf (Security Policy Framework) - carryover
>>> 10 - warlord (Filter Windows Executables) - carryover
>>> 11 - canonical rcpt patch (log real evelope recipient) - carryover
>>> 12 - qregex (pattern, badhelo and etc..., matching) - carryover
>>> 13 - tls patch 20160918v - (SMTP SSL/TLS) Frederik Vermeulen - carryover
>>> 14 - auth 0.83 - Erwin Hoffmann (SMTP Authentication) - update
>>> 15 - force tls patch - Marcel Telka (Force TLS before authentication) - new
>>> 16 - chkusr patch (Extends chkusr functionality) - carryover
>>> 17 - smtpd spf qq reject logging (Extended logging for SMTP message
>>> failure...spf, looping, bad mime, and etc...) - carryover
>>> 18 - srs patch, most recent (Sender Rewriting Scheme) - update
>>> 19 - big dns patch (Large DNS packets) - carryover
>>> 20 - smtp line feed patch (Accept email terminated with lf in addition
>>> to standard crlf) - carryover
>>> 21 - eMPF patch (eMail Messaging Policy Framework) - carryover
>>> 22 - uids patch (Adds uids to log) - carryover
>>> 23 - remove cname lookup from qmail-remote
>>> (https://lists.gt.net/qmail/users/138190) - carryover
>>> 24 - maildir++ fix patch (fixes quota calculation) - new
>>> 25 - smtp addparse
>>> (http://qmail.cr.yp.narkive.com/kBry6GJl/bug-in-qmail-smtpd-c-addrparse-function)
>>> - new
>>> 26 - exttodo patch (Silly Qmail Syndrome) - new
>>> 27 - qmail remote rfc2821 compliance
>>> (http://www.memoryhole.net/qmail/#rfc2821) - new
>>> 28 - qmail smtpd 502 to 500 rfc2821 compliance
>>> (http://www.memoryhole.net/qmail/#rfc2821) - new
>>> 29 - qmail remote crlf (http://opensource.sf-tec.de/qmail/) - new
>>> 30 - reread concurrency
>>> (http://notes.sagredo.eu/en/qmail-notes-185/patching-qmail-82.html#reread)
>>> new
>>> 31 - smtpd pidqplog (Logs pid so you can track transaction in log,
>>> http://iain.cx/qmail/patches.html#smtpd_pidqp) - new
>>> 32 - smtpd relay reject (http://qmail.org/qmail-smtpd-relay-reject) - new
>>> 33 - double bounce trim (http://qmail.org/doublebounce-trim.patch) - new
>>> 34 - qmail inject null sender -
>>> (http://notes.sagredo.eu/qmail-notes-185/qmail-inject-sieve-vacationreject-messages-trouble-133.html)
>>> - new
>>> 
>>> 
 On 8/15/2018 10:18 AM, Andrew Swartz wrote:
 Eric,
 
 Thanks.
 
 What is the proper destination folder for the rpm (to allow the 'yum
 localupdate' command)?
 
 -Andy
 
 
> On 8/15/2018 7:25 AM, Eric Broch wrote:
> wget https://www.qmailtoaster.org/qmail-1.03-3.qt.el7.x86_64.rpm
> 
> yum localupdate qmail-1.03-3.qt.el7.x86_64.rpm
> 
> 
>> On 8/15/2018 9:22 AM, Andrew Swartz 

Re: [qmailtoaster] status of qmail-1.03-3 CentOS 7 ?

2018-08-15 Thread Eric Broch
I ran this 1.03-3 version for several months with no issues, and haven't 
heard anything from the community on it.


I personally upgraded to 1.03-3.1 (in the development tree) now on my 
own production machine. In this version I take all the patches (below), 
carrying over some, updating some and adding extras, and apply them in 
an orderly fashion instead of using one big patch because IMHO opinion 
patching will be easier to maintain this way. I'm going to create 
1.03-3.2 in which I'll add to qmail-smtpd more extensive logging mainly 
to indicate a message's having been queued. And, I'd also like to 
possibly add logging to qmail-remote.


I was motivated to update/add patches by the work of

Roberto Puzzanghera ,


Erwin Hoffmann ,

Frederik Vermeulen 

Manvendra Bhangui 

Kyle Wheeler 

among others.



Patches
01 - netqmail-1.06 patch (Change qmail-1.03 to netqmail-1.06, 
http://www.qmail.org/netqmail/) - update
02 - chkuser 2.09 patch (Check 'mail from' and 'rcpt to', 
http://opensource.interazioni.it/qmail/chkuser/download.html) - carryover

03 - change location of vpopmail development libraries - carryover
04 - big concurrency (allows greater number of deliveries by qmail, 
above 255) - new
05 - big concurrency fix (fixes compiler error if number of 
concurrencies is set above 509) - new

06 - custom patch (adds error logging to simscan) - carryover
07 - maildir++ patch (adds quota support to qmail-pop3d and qmail-local) 
- carryover

08 - tap extended (Email Archive) - update
09 - spf (Security Policy Framework) - carryover
10 - warlord (Filter Windows Executables) - carryover
11 - canonical rcpt patch (log real evelope recipient) - carryover
12 - qregex (pattern, badhelo and etc..., matching) - carryover
13 - tls patch 20160918v - (SMTP SSL/TLS) Frederik Vermeulen - carryover
14 - auth 0.83 - Erwin Hoffmann (SMTP Authentication) - update
15 - force tls patch - Marcel Telka (Force TLS before authentication) - new
16 - chkusr patch (Extends chkusr functionality) - carryover
17 - smtpd spf qq reject logging (Extended logging for SMTP message 
failure...spf, looping, bad mime, and etc...) - carryover

18 - srs patch, most recent (Sender Rewriting Scheme) - update
19 - big dns patch (Large DNS packets) - carryover
20 - smtp line feed patch (Accept email terminated with lf in addition 
to standard crlf) - carryover

21 - eMPF patch (eMail Messaging Policy Framework) - carryover
22 - uids patch (Adds uids to log) - carryover
23 - remove cname lookup from qmail-remote 
(https://lists.gt.net/qmail/users/138190) - carryover

24 - maildir++ fix patch (fixes quota calculation) - new
25 - smtp addparse 
(http://qmail.cr.yp.narkive.com/kBry6GJl/bug-in-qmail-smtpd-c-addrparse-function) 
- new

26 - exttodo patch (Silly Qmail Syndrome) - new
27 - qmail remote rfc2821 compliance 
(http://www.memoryhole.net/qmail/#rfc2821) - new
28 - qmail smtpd 502 to 500 rfc2821 compliance 
(http://www.memoryhole.net/qmail/#rfc2821) - new

29 - qmail remote crlf (http://opensource.sf-tec.de/qmail/) - new
30 - reread concurrency 
(http://notes.sagredo.eu/en/qmail-notes-185/patching-qmail-82.html#reread) 
new
31 - smtpd pidqplog (Logs pid so you can track transaction in log, 
http://iain.cx/qmail/patches.html#smtpd_pidqp) - new

32 - smtpd relay reject (http://qmail.org/qmail-smtpd-relay-reject) - new
33 - double bounce trim (http://qmail.org/doublebounce-trim.patch) - new
34 - qmail inject null sender - 
(http://notes.sagredo.eu/qmail-notes-185/qmail-inject-sieve-vacationreject-messages-trouble-133.html) 
- new



On 8/15/2018 10:18 AM, Andrew Swartz wrote:

Eric,

Thanks.

What is the proper destination folder for the rpm (to allow the 'yum
localupdate' command)?

-Andy


On 8/15/2018 7:25 AM, Eric Broch wrote:

wget https://www.qmailtoaster.org/qmail-1.03-3.qt.el7.x86_64.rpm

yum localupdate qmail-1.03-3.qt.el7.x86_64.rpm


On 8/15/2018 9:22 AM, Andrew Swartz wrote:

I just realized that the qt-install script did not install qmail-1.03-3
on my new centos-7 toaster.

Does anyone have experience with the qmail-1.03-3 update?

-Andy






--
Eric Broch
White Horse Technical Consulting (WHTC)



Re: [qmailtoaster] status of qmail-1.03-3 CentOS 7 ?

2018-08-15 Thread Eric Broch
It doesn't really matter. I usually do everything as root (probably not 
a good idea) in /root.



On 8/15/2018 10:18 AM, Andrew Swartz wrote:

Eric,

Thanks.

What is the proper destination folder for the rpm (to allow the 'yum
localupdate' command)?

-Andy


On 8/15/2018 7:25 AM, Eric Broch wrote:

wget https://www.qmailtoaster.org/qmail-1.03-3.qt.el7.x86_64.rpm

yum localupdate qmail-1.03-3.qt.el7.x86_64.rpm


On 8/15/2018 9:22 AM, Andrew Swartz wrote:

I just realized that the qt-install script did not install qmail-1.03-3
on my new centos-7 toaster.

Does anyone have experience with the qmail-1.03-3 update?

-Andy






--
Eric Broch
White Horse Technical Consulting (WHTC)


-
To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com



Re: [qmailtoaster] status of qmail-1.03-3 CentOS 7 ?

2018-08-15 Thread Andrew Swartz
Eric,

Thanks.

What is the proper destination folder for the rpm (to allow the 'yum
localupdate' command)?

-Andy


On 8/15/2018 7:25 AM, Eric Broch wrote:
> wget https://www.qmailtoaster.org/qmail-1.03-3.qt.el7.x86_64.rpm
> 
> yum localupdate qmail-1.03-3.qt.el7.x86_64.rpm
> 
> 
> On 8/15/2018 9:22 AM, Andrew Swartz wrote:
>> I just realized that the qt-install script did not install qmail-1.03-3
>> on my new centos-7 toaster.
>>
>> Does anyone have experience with the qmail-1.03-3 update?
>>
>> -Andy
>>
> 





smime.p7s
Description: S/MIME Cryptographic Signature


Re: [qmailtoaster] status of qmail-1.03-3 CentOS 7 ?

2018-08-15 Thread Eric Broch

wget https://www.qmailtoaster.org/qmail-1.03-3.qt.el7.x86_64.rpm

yum localupdate qmail-1.03-3.qt.el7.x86_64.rpm


On 8/15/2018 9:22 AM, Andrew Swartz wrote:

I just realized that the qt-install script did not install qmail-1.03-3
on my new centos-7 toaster.

Does anyone have experience with the qmail-1.03-3 update?

-Andy



--
Eric Broch
White Horse Technical Consulting (WHTC)


-
To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com



[qmailtoaster] status of qmail-1.03-3 CentOS 7 ?

2018-08-15 Thread Andrew Swartz
I just realized that the qt-install script did not install qmail-1.03-3
on my new centos-7 toaster.

Does anyone have experience with the qmail-1.03-3 update?

-Andy



smime.p7s
Description: S/MIME Cryptographic Signature