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 <awswa...@acsalaska.net> 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 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) >>>>>>>> >>> >> > >
signature.asc
Description: Message signed with OpenPGP
