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 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 >> >> >> 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 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 <https://notes.sagredo.eu/>, >>>>>>> <https://www.fehcom.de/> >>>>>>> >>>>>>> Erwin Hoffmann <https://www.fehcom.de/>, >>>>>>> >>>>>>> Frederik Vermeulen <http://inoa.net/qmail-tls/> >>>>>>> >>>>>>> Manvendra Bhangui <http://www.indimail.org/> >>>>>>> >>>>>>> Kyle Wheeler <http://www.memoryhole.net/qmail/> >>>>>>> >>>>>>> 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) >>>>>>> >> >
smime.p7s
Description: S/MIME Cryptographic Signature
