I have the default one here it is.. should I add the TLS one like you mention 
below?

: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”


> On Aug 13, 2018, at 22:43, Andrew Swartz <[email protected]> wrote:
> 
> Remo,
> 
> I don't think the order matters in tlsserverciphers.  I cat'd the cert, the 
> key, and the chain into my file, in that order, and it works fine.
> 
> Nice bug catch on the cipher list.  I made the script on the latest centos-7 
> toaster which installs with a cipher list of "DH:!LOW:!MEDIUM" in tcp.smtp.  
> The sed command merely replaces it.  If it's not present, or different, 
> nothing happens (i.e. it fails gracefully).  It did not seem to affect your 
> connection, as that was just a cert verify problem.
> 
> Do you have a TLSCIPHERS environ. variable in tcp.smtp?  In my file, the line 
> for remote mail ends with:
> TLSCIPHERS="ECDHE:DHE:ECDH:DH:AES:!SSLv2!SSLv3"
> 
> I just checked a centos-5 installation, and there is no TLSCIPHERS variable 
> in tcp.smtp.  I just connected to that machine with s_client and it 
> established a TLSv1.0 connection, so apparently there is a default cipher 
> list present in qmail-smtpd (I confirmed that port 587 does not go through 
> spamdyke).
> 
> Specifying ciphers is merely due to my over paranoia.  99.999% of people will 
> likely be happy with the defaults.
> 
> -Andy
> 
> 
> 
> On 8/13/2018 9:25 PM, Remo Mattei wrote:
>> I think I need to add the intermediary cert. looks like.. trying to figure 
>> that out now.. not sure which order they go.
>> 
>> Andrew Swartz wrote on 8/13/18 22:24:
>>> Remo,
>>> 
>>> I just did this:
>>> 
>>> openssl s_client -starttls smtp -crlf -connect qmail.rm.ht:587
>>> 
>>> and got the same result.
>>> 
>>> Therefore you've probably had this problem for a while.
>>> 
>>> Are you using the cert with the "full chain"?  Apparently bare certs
>>> rarely verify, and I've read several recommendations to provide the
>>> server with the pem file containing the full chain.
>>> 
>>> If you read the stuff at the "STARTTLS Everywhere" site, they state that
>>> most mail servers to not require (or even attempt) cert verification,
>>> and changing this is one of their goals.
>>> 
>>> -Andy
>>> 
>>> 
>>> 
>>> On 8/13/2018 8:56 PM, Remo Mattei wrote:
>>>> Any suggestions on this Andy?
>>>> 
>>>> openssl s_client -crlf -connect qmail.rm.ht:465
>>>> CONNECTED(00000005)
>>>> depth=0 OU = Domain Control Validated, OU = PositiveSSL, CN = qmail.rm.ht
>>>> verify error:num=20:unable to get local issuer certificate
>>>> verify return:1
>>>> depth=0 OU = Domain Control Validated, OU = PositiveSSL, CN = qmail.rm.ht
>>>> verify error:num=27:certificate not trusted
>>>> verify return:1
>>>> depth=0 OU = Domain Control Validated, OU = PositiveSSL, CN = qmail.rm.ht
>>>> verify error:num=21:unable to verify the first certificate
>>>> verify return:1
>>>> ---
>>>> Certificate chain
>>>>  0 s:/OU=Domain Control Validated/OU=PositiveSSL/CN=qmail.rm.ht
>>>>    i:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO
>>>> RSA Domain Validation Secure Server CA
>>>> ---
>>>> 
>>>> 
>>>> I do have a valid cert as you can see it’s from COMODO. But not sure
>>>> about the first few lines
>>>> 
>>>> Remo
>>>> 
>>>>> On Aug 13, 2018, at 21:42, Andrew Swartz <[email protected] 
>>>>> <mailto:[email protected]>
>>>>> <mailto:[email protected]> <mailto:[email protected]>> wrote:
>>>>> 
>>>>> I just realized that the plain text line-wrapped the script, so here
>>>>> is an unwrapped version in case anyone else wants to use it. Also, I
>>>>> made it multiline so you can cut and paste it into a terminal and
>>>>> accomplish this in about 3 seconds with netstat confirming success (it
>>>>> should print a single line showing tcpserver listening on 465).
>>>>> 
>>>>> rfc8314 <https://tools.ietf.org/html/rfc8314> 
>>>>> <https://tools.ietf.org/html/rfc8314> in Jan of this year
>>>>> reinstates port 465/tls because starttls (port 587) is broken beyond
>>>>> repair (from a security perspective). So eventually everyone may
>>>>> eventually need to go back to port 465.  But since servers get to
>>>>> dictate setting to their clients without creating interoperability
>>>>> issues, it will likely be many years before this occurs.
>>>>> 
>>>>> The critical flaw in starttls is that some ISP's and/or governments
>>>>> have been caught filtering out the STARTTLS packet and thus preventing
>>>>> the initiation of encryption (a "starttls downgrade attack").  In that
>>>>> case, the client's username and password are sent in the clear.  And
>>>>> if an eavesdropper gets those, they can wreak havoc on your your life
>>>>> (i.e. by resetting the password for your bank or other online
>>>>> accounts, etc).  With port 465/tls, the client connection either
>>>>> establishes encryption or fails; it cannot be tricked into using
>>>>> clear-text.
>>>>> 
>>>>> Anyway, here is the paste-able script:
>>>>> 
>>>>> qmailctl stop; \
>>>>> cp  -r /var/qmail/supervise/submission /var/qmail/supervise/smtps; \
>>>>> chown -R qmaill:qmail /var/qmail/supervise/smtps; \
>>>>> sed -i 's/REQUIRE_AUTH=1/REQUIRE_AUTH=1\nexport SMTPS=1/'
>>>>> /var/qmail/supervise/smtps/run; \
>>>>> sed -i 's/587/465/' /var/qmail/supervise/smtps/run; \
>>>>> sed -i 's/submission/smtps/' /var/qmail/supervise/smtps/log/run; \
>>>>> sed -i 's/DH:!LOW:!MEDIUM/ECDHE:DHE:ECDH:DH:AES:!SSLv2:!SSLv3/'
>>>>> /etc/tcprules.d/tcp.smtp; \
>>>>> qmailctl cdb; \
>>>>> qmailctl start; \
>>>>> netstat -lnp | grep 465
>>>>> 
>>>>> 
>>>>> -Andy
>>>>> 
>>>>> PS: If old clients cannot connect, then remove the "!SSLv3" from the
>>>>> cipher list in tcp.smtp
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> On 8/13/2018 7:32 PM, Remo Mattei wrote:
>>>>>> Cool! I remember I did it like Eric described but the bottom line is
>>>>>> it works either way. I do not offer 465 any longer :)
>>>>>> 
>>>>>>  *dal mio iPhone X*
>>>>>> 
>>>>>> Il giorno 13 ago 2018, alle ore 20:25, Andrew Swartz
>>>>>> <[email protected] <mailto:[email protected]> 
>>>>>> <mailto:[email protected]> <mailto:[email protected]>> ha 
>>>>>> scritto:
>>>>>> 
>>>>>>> I eventually figured this out, and accomplished the same result though I
>>>>>>> went about it slightly differently.  It is now fully functional.  Below
>>>>>>> is the script which I created and accomplishes this in very few lines.
>>>>>>> It copies the supervise/smtp directory to supervise/smtps and it then
>>>>>>> edits a few values in two files files (plus editing the cipher list in
>>>>>>> tcp.smtp).
>>>>>>> 
>>>>>>> 
>>>>>>> qmailctl stop
>>>>>>> cp  -r /var/qmail/supervise/submission /var/qmail/supervise/smtps
>>>>>>> chown -R qmaill:qmail /var/qmail/supervise/smtps
>>>>>>> sed -i 's/REQUIRE_AUTH=1/REQUIRE_AUTH=1\nexport SMTPS=1/'
>>>>>>> /var/qmail/supervise/smtps/run
>>>>>>> sed -i 's/587/465/' /var/qmail/supervise/smtps/run
>>>>>>> sed -i 's/submission/smtps/' /var/qmail/supervise/smtps/log/run
>>>>>>> sed -i 's/DH:!LOW:!MEDIUM/ECDHE:DHE:ECDH:DH:AES:!SSLv2/'
>>>>>>> /etc/tcprules.d/tcp.smtp
>>>>>>> qmailctl cdb
>>>>>>> qmailctl start
>>>>>>> 
>>>>>>> 
>>>>>>> Thanks for confirming that I did it right,
>>>>>>> Andy
>>>>>>> 
>>>>>>> 
>>>>>>> On 8/13/2018 7:06 PM, Eric Broch wrote:
>>>>>>>> Stock CentOS 7 does not have SMTPS standard. You must create the
>>>>>>>> supervise scripts.
>>>>>>>> 
>>>>>>>> You could stop qmail
>>>>>>>> 
>>>>>>>> # qmailctl stop
>>>>>>>> 
>>>>>>>> and copy smtp supervise scripts to smtps (make sure qmail is stopped or
>>>>>>>> else you'll have a mess):
>>>>>>>> 
>>>>>>>> # cp -Rp /var/qmail/supervise/smtp /var/qmail/supervise/smtps
>>>>>>>> 
>>>>>>>> Then change two files:
>>>>>>>> 
>>>>>>>> /var/qmail/supervise/smtps/run
>>>>>>>> 
>>>>>>>> <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.smtp.cdb"
>>>>>>>> HOSTNAME=`hostname`
>>>>>>>> VCHKPW="/home/vpopmail/bin/vchkpw"
>>>>>>>> export SMTPS=1
>>>>>>>> 
>>>>>>>> exec /usr/bin/softlimit -m 128000000 \
>>>>>>>>     /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
>>>>>>>> 
>>>>>>>> </run>
>>>>>>>> 
>>>>>>>> &
>>>>>>>> 
>>>>>>>> /var/qmail/supervise/smtps/log/run
>>>>>>>> 
>>>>>>>> <run>
>>>>>>>> 
>>>>>>>> #!/bin/sh
>>>>>>>> LOGSIZE=`cat /var/qmail/control/logsize`
>>>>>>>> LOGCOUNT=`cat /var/qmail/control/logcount`
>>>>>>>> exec /usr/bin/setuidgid qmaill /usr/bin/multilog \
>>>>>>>>     t s$LOGSIZE n$LOGCOUNT /var/log/qmail/smtps 2>&1
>>>>>>>> 
>>>>>>>> </run>
>>>>>>>> 
>>>>>>>> Start qmail (# qmailctl start)
>>>>>>>> 
>>>>>>>> 
>>>>>>>> On 8/11/2018 6:36 PM, Andrew Swartz wrote:
>>>>>>>>> I just installed qmailtoaster onto CentOS-7.  The qt_install script
>>>>>>>>> opened port 465 on the firewall.  However, s_client cannot connect to
>>>>>>>>> port 465 and netstat shows that nothing is listening on port 465.
>>>>>>>>> 
>>>>>>>>> Can anyone point me at appropriate instructions for setting up
>>>>>>>>> listening
>>>>>>>>> on port 465 which are specific (or applicable) to qmailtoaster?  I
>>>>>>>>> searched wiki.qmailtoaster.com <http://wiki.qmailtoaster.com/> 
>>>>>>>>> <http://wiki.qmailtoaster.com/> and
>>>>>>>>> found nothing. I did some general
>>>>>>>>> googling and found several somewhat conflicting descriptions but I'm
>>>>>>>>> unsure which apply to the configuration used in qmailtoaster.
>>>>>>>>> 
>>>>>>>>> My interest is because 465 has been reinstated (in Jan 2018) as the
>>>>>>>>> preferred submission port due to security problems with STARTTLS
>>>>>>>>> (https://tools.ietf.org/html/rfc8314 
>>>>>>>>> <https://tools.ietf.org/html/rfc8314>).
>>>>>>>>> 
>>>>>>>>> Thanks,
>>>>>>>>> -Andy
>>>>>>>>> 
>>>>>>>>> 
>>>>>>> --
>>>>>>> Andrew W. Swartz, MD
>>>>>>> Departments of Emergency Medicine, Family Medicine, and Surgery
>>>>>>> Yukon-Kuskokwim Delta Regional Hospital
>>>>>>> Bethel, Alaska
>>>>>>> 
>>>>> --
>>>>> Andrew W. Swartz, MD
>>>>> Departments of Emergency Medicine, Family Medicine, and Surgery
>>>>> Yukon-Kuskokwim Delta Regional Hospital
>>>>> Bethel, Alaska
>> 
>> --
>> Sent from Postbox <https://www.postbox-inc.com/>
> --
> Andrew W. Swartz, MD
> Departments of Emergency Medicine, Family Medicine, and Surgery
> Yukon-Kuskokwim Delta Regional Hospital
> Bethel, Alaska

Attachment: signature.asc
Description: Message signed with OpenPGP

Reply via email to