Re: [qmailtoaster] forwarding to gmail address fails because of hard spf check
Hi, I don't know which email/headers caused it as I had to get the server up and running as fast as possible. That was just my guess for the cause after googling a bit. Some kind of a monitoring script might work as a workaround like Philip suggested: try to detect the error, rename srs_domain, wait for a while, rename srs_domain back What would be the best way to monitor the log file, any recommendations? The best solution would be if someone knowledgeable enough could fix the patch: if the error is encountered, the problem msg would be skipped for SRS processing instead of logging and trying again. Best, Peter On Fri, Feb 24, 2023 at 4:24 AM あいざわひろし wrote: > Hi Peter, > > What kind of malformed header cause it? > > I wonder whether I can drop such mail in > /var/qmail/alias/.qmail-srs-default . > -- > AIZAWA Hiroshi > > 2023年2月23日(木) 20:32 Peter Peltonen : > > > > Ok good. > > > > I actually ran into a SRS related problem yesterday: i think a malformed > headers in spam msg caused to SRS to fail which put my qmail send process > in a loop with error > > > > No user in SRS0 address > > > > Qmail spawned more and more processes until my server got unresponsive > and I had to reboot the server. After qmail had started, the same thing > happened again. > > > > I had to disable SRS to get everything working. > > > > Very unfortunate, everything had worked so well until now. > > > > Peter > > > > to 23. helmik. 2023 klo 11.38 あいざわひろし kirjoitti: > >> > >> Hi guys > >> > >> Thanks to this thread, gmail.com now receives forwarded message from > >> my mailserver . > >> > >> I noticed that mx.google.com says 'spf=neutral' in the header > >> ARC-Authentication-Results > >> I created SPF record for domain srs (in this example, srs.xyz.com) > and now > >> mx.google.com says 'spf=pass'. > >> > >> I think it is better to make the spf record for srs domain. > >> > >> -- > >> AIZAWA Hiroshi > >> > >> 2023年1月3日(火) 18:23 Peter Peltonen : > >> > > >> > Googling "srs qmailtoaster" gave me this link: > >> > > >> > > http://wiki.qmailtoaster.net/index.php/Configuring_SRS_on_Toaster_1.03-1.3.13%2B > >> > > >> > which does not work, it seems qmailtoaster.com should be used > instead of .net > >> > > >> > Okay now we have the instructions I guess I could try to test it, I > have a spare registered domain I could test with. Does this sound ok > procedure: > >> > > >> > setup domain xyz.com with SPF with hard fail (-all) and the toaster > as the MX > >> > send email from xyz.com to GMail through our toaster: should pass ok > >> > setup forwarding from xyz.com to GMail > >> > send email to xyz.com: should fail because GMail does not accept > >> > setup SRS at toaster: > >> > > >> > create NS record for domain srs.xyz.com with MX pointing to our > toaster > >> > echo srs.xyz.com > /var/qmail/control/srs_domain > >> > mkpasswd -l 32 > /var/qmail/control/srs_secrets > >> > mkpasswd -l 32 >> /var/qmail/control/srs_secrets > >> > (repeat mkpasswd as many times you need, not sure how many is really > needed?) > >> > echo 7 > /var/qmail/control/srs_maxage > >> > echo 8 > /var/qmail/control/srs_hashlength > >> > qmailctl restart > >> > echo srs.xyz.com >> /var/qmail/control/rcpthosts > >> > echo srs.xyz.com:srs >> /var/qmail/control/virtualdomains > >> > echo "| /var/qmail/bin/srsfilter" > > /var/qmail/alias/.qmail-srs-default > >> > (ownershp of other alias files on my server are user alias group > nofiles, so probably this should be changed to the same?) > >> > > >> > send email to xyz.com: should pass ok > >> > > >> > > >> > What do you think Angus? > >> > > >> > Best, > >> > Peter > >> > > >> > > >> > On Mon, Jan 2, 2023 at 7:52 PM Angus McIntyre > wrote: > >> >> > >> >> > >> >> > >> >> Peter Peltonen wrote on 1/2/23 11:57 AM: > >> >> > Some of my toaster users have their email forwarded to Gmail ... > Some > >> >> > googling around tells me that SRS could be the solution for this > >> >> > problem. > &g
Re: [qmailtoaster] forwarding to gmail address fails because of hard spf check
Ok good. I actually ran into a SRS related problem yesterday: i think a malformed headers in spam msg caused to SRS to fail which put my qmail send process in a loop with error No user in SRS0 address Qmail spawned more and more processes until my server got unresponsive and I had to reboot the server. After qmail had started, the same thing happened again. I had to disable SRS to get everything working. Very unfortunate, everything had worked so well until now. Peter to 23. helmik. 2023 klo 11.38 あいざわひろし kirjoitti: > Hi guys > > Thanks to this thread, gmail.com now receives forwarded message from > my mailserver . > > I noticed that mx.google.com says 'spf=neutral' in the header > ARC-Authentication-Results > I created SPF record for domain srs (in this example, srs.xyz.com) and > now > mx.google.com says 'spf=pass'. > > I think it is better to make the spf record for srs domain. > > -- > AIZAWA Hiroshi > > 2023年1月3日(火) 18:23 Peter Peltonen : > > > > Googling "srs qmailtoaster" gave me this link: > > > > > http://wiki.qmailtoaster.net/index.php/Configuring_SRS_on_Toaster_1.03-1.3.13%2B > > > > which does not work, it seems qmailtoaster.com should be used instead > of .net > > > > Okay now we have the instructions I guess I could try to test it, I have > a spare registered domain I could test with. Does this sound ok procedure: > > > > setup domain xyz.com with SPF with hard fail (-all) and the toaster as > the MX > > send email from xyz.com to GMail through our toaster: should pass ok > > setup forwarding from xyz.com to GMail > > send email to xyz.com: should fail because GMail does not accept > > setup SRS at toaster: > > > > create NS record for domain srs.xyz.com with MX pointing to our toaster > > echo srs.xyz.com > /var/qmail/control/srs_domain > > mkpasswd -l 32 > /var/qmail/control/srs_secrets > > mkpasswd -l 32 >> /var/qmail/control/srs_secrets > > (repeat mkpasswd as many times you need, not sure how many is really > needed?) > > echo 7 > /var/qmail/control/srs_maxage > > echo 8 > /var/qmail/control/srs_hashlength > > qmailctl restart > > echo srs.xyz.com >> /var/qmail/control/rcpthosts > > echo srs.xyz.com:srs >> /var/qmail/control/virtualdomains > > echo "| /var/qmail/bin/srsfilter" > /var/qmail/alias/.qmail-srs-default > > (ownershp of other alias files on my server are user alias group > nofiles, so probably this should be changed to the same?) > > > > send email to xyz.com: should pass ok > > > > > > What do you think Angus? > > > > Best, > > Peter > > > > > > On Mon, Jan 2, 2023 at 7:52 PM Angus McIntyre wrote: > >> > >> > >> > >> Peter Peltonen wrote on 1/2/23 11:57 AM: > >> > Some of my toaster users have their email forwarded to Gmail ... Some > >> > googling around tells me that SRS could be the solution for this > >> > problem. > >> > > >> > There is info on this at Qmailtoaster Wiki, but the site seems to be > >> > somehow broken. > >> > >> Which page are you looking at, and in what way does it seem broken? > >> > >> > >> > http://wiki.qmailtoaster.com/index.php/Configuring_SRS_on_Toaster_1.03-1.3.13%2B > >> > >> currently loads fine for me, and looks as if it has good information. > >> > >> I should stress that I haven't tried this yet. I didn't know about SRS > >> until you posted this (thank you!) but I'm having the same issue as you > >> and it sounds as if this might be just what I need. > >> > >> Would anyone who's actually implemented this care to comment? > >> > >> Angus > >> > >> > >> - > >> To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com > >> For additional commands, e-mail: > qmailtoaster-list-h...@qmailtoaster.com > >> > > - > To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com > For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com > >
Re: [qmailtoaster] forwarding to gmail address fails because of hard spf check
Actually, I think I was wrong: Even though I had not configured SRS for a particular domain, I can see from the headers of the message forwarded to Gmail that it used the SRS setup for the domain configured in /var/qmail/control/srs_domain And adding multiple domains to /var/qmail/control/srs_domain does not seem to do anything: the first domain listed there is always used. If someone else tries this out, please correct me if I'm wrong! Best, Peter On Fri, Jan 13, 2023 at 3:11 PM Peter Peltonen wrote: > Hi Andreas, > > Unfortunately it needs to be done for every domain that forwards email > outside the toaster. > > Best, > Peter > > On Wed, Jan 4, 2023 at 11:08 PM Andreas wrote: > >> Hi Peter, >> >> Did you do that for every domain separatly or once just for the server? >> >> Andreas >> >> Am 04.01.23 um 18:18 schrieb Peter Peltonen: >> >> Okay I tested this setup and it seems to work, mail gets through and I >> get spf=pass for it in Gmail. >> >> The only difference to the procedure I posted earlier were: >> >> - needed to add srs.xyz.com to morercpthosts and not to rcpthosts as I >> have more than 50 domains hosted >> - at the end I ran qmailctl cdb and qmailctl restart, not sure if needed >> >> Best, >> Peter >> >> >> >> On Tue, Jan 3, 2023 at 11:22 AM Peter Peltonen >> wrote: >> >>> Googling "srs qmailtoaster" gave me this link: >>> >>> >>> http://wiki.qmailtoaster.net/index.php/Configuring_SRS_on_Toaster_1.03-1.3.13%2B >>> >>> which does not work, it seems qmailtoaster.com should be used instead >>> of .net >>> >>> Okay now we have the instructions I guess I could try to test it, I have >>> a spare registered domain I could test with. Does this sound ok procedure: >>> >>> >>>- setup domain xyz.com with SPF with hard fail (-all) and the >>>toaster as the MX >>>- send email from xyz.com to GMail through our toaster: should pass >>>ok >>>- setup forwarding from xyz.com to GMail >>>- send email to xyz.com: should fail because GMail does not accept >>>- setup SRS at toaster: >>> >>> >>>1. create NS record for domain srs.xyz.com with MX pointing to our >>>toaster >>>2. echo srs.xyz.com > /var/qmail/control/srs_domain >>>3. mkpasswd -l 32 > /var/qmail/control/srs_secrets >>>4. mkpasswd -l 32 >> /var/qmail/control/srs_secrets >>>5. (repeat mkpasswd as many times you need, not sure how many is >>>really needed?) >>>6. echo 7 > /var/qmail/control/srs_maxage >>>7. echo 8 > /var/qmail/control/srs_hashlength >>>8. qmailctl restart >>>9. echo srs.xyz.com >> /var/qmail/control/rcpthosts >>>10. echo srs.xyz.com:srs >> /var/qmail/control/virtualdomains >>>11. echo "| /var/qmail/bin/srsfilter" > >>>/var/qmail/alias/.qmail-srs-default >>>(ownershp of other alias files on my server are user alias group >>>nofiles, so probably this should be changed to the same?) >>> >>> >>>- send email to xyz.com: should pass ok >>> >>> >>> What do you think Angus? >>> >>> Best, >>> Peter >>> >>> >>> On Mon, Jan 2, 2023 at 7:52 PM Angus McIntyre wrote: >>> >>>> >>>> >>>> Peter Peltonen wrote on 1/2/23 11:57 AM: >>>> > Some of my toaster users have their email forwarded to Gmail ... Some >>>> > googling around tells me that SRS could be the solution for this >>>> > problem. >>>> > >>>> > There is info on this at Qmailtoaster Wiki, but the site seems to be >>>> > somehow broken. >>>> >>>> Which page are you looking at, and in what way does it seem broken? >>>> >>>> >>>> >>>> http://wiki.qmailtoaster.com/index.php/Configuring_SRS_on_Toaster_1.03-1.3.13%2B >>>> >>>> currently loads fine for me, and looks as if it has good information. >>>> >>>> I should stress that I haven't tried this yet. I didn't know about SRS >>>> until you posted this (thank you!) but I'm having the same issue as you >>>> and it sounds as if this might be just what I need. >>>> >>>> Would anyone who's actually implemented this care to comment? >>>> >>>> Angus >>>> >>>> >>>> - >>>> To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com >>>> For additional commands, e-mail: >>>> qmailtoaster-list-h...@qmailtoaster.com >>>> >>>> >>
Re: [qmailtoaster] forwarding to gmail address fails because of hard spf check
Hi Andreas, Unfortunately it needs to be done for every domain that forwards email outside the toaster. Best, Peter On Wed, Jan 4, 2023 at 11:08 PM Andreas wrote: > Hi Peter, > > Did you do that for every domain separatly or once just for the server? > > Andreas > > Am 04.01.23 um 18:18 schrieb Peter Peltonen: > > Okay I tested this setup and it seems to work, mail gets through and I get > spf=pass for it in Gmail. > > The only difference to the procedure I posted earlier were: > > - needed to add srs.xyz.com to morercpthosts and not to rcpthosts as I > have more than 50 domains hosted > - at the end I ran qmailctl cdb and qmailctl restart, not sure if needed > > Best, > Peter > > > > On Tue, Jan 3, 2023 at 11:22 AM Peter Peltonen > wrote: > >> Googling "srs qmailtoaster" gave me this link: >> >> >> http://wiki.qmailtoaster.net/index.php/Configuring_SRS_on_Toaster_1.03-1.3.13%2B >> >> which does not work, it seems qmailtoaster.com should be used instead of >> .net >> >> Okay now we have the instructions I guess I could try to test it, I have >> a spare registered domain I could test with. Does this sound ok procedure: >> >> >>- setup domain xyz.com with SPF with hard fail (-all) and the toaster >>as the MX >>- send email from xyz.com to GMail through our toaster: should pass ok >>- setup forwarding from xyz.com to GMail >>- send email to xyz.com: should fail because GMail does not accept >>- setup SRS at toaster: >> >> >>1. create NS record for domain srs.xyz.com with MX pointing to our >>toaster >>2. echo srs.xyz.com > /var/qmail/control/srs_domain >>3. mkpasswd -l 32 > /var/qmail/control/srs_secrets >>4. mkpasswd -l 32 >> /var/qmail/control/srs_secrets >>5. (repeat mkpasswd as many times you need, not sure how many is >>really needed?) >>6. echo 7 > /var/qmail/control/srs_maxage >>7. echo 8 > /var/qmail/control/srs_hashlength >>8. qmailctl restart >>9. echo srs.xyz.com >> /var/qmail/control/rcpthosts >>10. echo srs.xyz.com:srs >> /var/qmail/control/virtualdomains >>11. echo "| /var/qmail/bin/srsfilter" > >>/var/qmail/alias/.qmail-srs-default >>(ownershp of other alias files on my server are user alias group >>nofiles, so probably this should be changed to the same?) >> >> >>- send email to xyz.com: should pass ok >> >> >> What do you think Angus? >> >> Best, >> Peter >> >> >> On Mon, Jan 2, 2023 at 7:52 PM Angus McIntyre wrote: >> >>> >>> >>> Peter Peltonen wrote on 1/2/23 11:57 AM: >>> > Some of my toaster users have their email forwarded to Gmail ... Some >>> > googling around tells me that SRS could be the solution for this >>> > problem. >>> > >>> > There is info on this at Qmailtoaster Wiki, but the site seems to be >>> > somehow broken. >>> >>> Which page are you looking at, and in what way does it seem broken? >>> >>> >>> >>> http://wiki.qmailtoaster.com/index.php/Configuring_SRS_on_Toaster_1.03-1.3.13%2B >>> >>> currently loads fine for me, and looks as if it has good information. >>> >>> I should stress that I haven't tried this yet. I didn't know about SRS >>> until you posted this (thank you!) but I'm having the same issue as you >>> and it sounds as if this might be just what I need. >>> >>> Would anyone who's actually implemented this care to comment? >>> >>> Angus >>> >>> >>> - >>> To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com >>> For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com >>> >>> >
Re: [qmailtoaster] forwarding to gmail address fails because of hard spf check
Thanks Jeff for the info. Do you know if qmailctl cdb / restart is needed when adding info to rcpthosts, morercpthosts or virtualdomains? Best, Peter On Wed, Jan 4, 2023 at 7:24 PM Jeff Koch wrote: > Peter - I don't think it matters whether the domain is added to rcpthosts > or morercpthosts - the toaster will generally add additional domains to > morercpthosts but it should work fine either way. > > Jeff > > On 1/4/2023 12:18 PM, Peter Peltonen wrote: > > Okay I tested this setup and it seems to work, mail gets through and I get > spf=pass for it in Gmail. > > The only difference to the procedure I posted earlier were: > > - needed to add srs.xyz.com to morercpthosts and not to rcpthosts as I > have more than 50 domains hosted > - at the end I ran qmailctl cdb and qmailctl restart, not sure if needed > > Best, > Peter > > > > On Tue, Jan 3, 2023 at 11:22 AM Peter Peltonen > wrote: > >> Googling "srs qmailtoaster" gave me this link: >> >> >> http://wiki.qmailtoaster.net/index.php/Configuring_SRS_on_Toaster_1.03-1.3.13%2B >> >> which does not work, it seems qmailtoaster.com should be used instead of >> .net >> >> Okay now we have the instructions I guess I could try to test it, I have >> a spare registered domain I could test with. Does this sound ok procedure: >> >> >>- setup domain xyz.com with SPF with hard fail (-all) and the toaster >>as the MX >>- send email from xyz.com to GMail through our toaster: should pass ok >>- setup forwarding from xyz.com to GMail >>- send email to xyz.com: should fail because GMail does not accept >>- setup SRS at toaster: >> >> >>1. create NS record for domain srs.xyz.com with MX pointing to our >>toaster >>2. echo srs.xyz.com > /var/qmail/control/srs_domain >>3. mkpasswd -l 32 > /var/qmail/control/srs_secrets >>4. mkpasswd -l 32 >> /var/qmail/control/srs_secrets >>5. (repeat mkpasswd as many times you need, not sure how many is >>really needed?) >>6. echo 7 > /var/qmail/control/srs_maxage >>7. echo 8 > /var/qmail/control/srs_hashlength >>8. qmailctl restart >>9. echo srs.xyz.com >> /var/qmail/control/rcpthosts >>10. echo srs.xyz.com:srs >> /var/qmail/control/virtualdomains >>11. echo "| /var/qmail/bin/srsfilter" > >>/var/qmail/alias/.qmail-srs-default >>(ownershp of other alias files on my server are user alias group >>nofiles, so probably this should be changed to the same?) >> >> >>- send email to xyz.com: should pass ok >> >> >> What do you think Angus? >> >> Best, >> Peter >> >> >> On Mon, Jan 2, 2023 at 7:52 PM Angus McIntyre wrote: >> >>> >>> >>> Peter Peltonen wrote on 1/2/23 11:57 AM: >>> > Some of my toaster users have their email forwarded to Gmail ... Some >>> > googling around tells me that SRS could be the solution for this >>> > problem. >>> > >>> > There is info on this at Qmailtoaster Wiki, but the site seems to be >>> > somehow broken. >>> >>> Which page are you looking at, and in what way does it seem broken? >>> >>> >>> >>> http://wiki.qmailtoaster.com/index.php/Configuring_SRS_on_Toaster_1.03-1.3.13%2B >>> >>> currently loads fine for me, and looks as if it has good information. >>> >>> I should stress that I haven't tried this yet. I didn't know about SRS >>> until you posted this (thank you!) but I'm having the same issue as you >>> and it sounds as if this might be just what I need. >>> >>> Would anyone who's actually implemented this care to comment? >>> >>> Angus >>> >>> >>> - >>> To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com >>> For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com >>> >>> >
Re: [qmailtoaster] forwarding to gmail address fails because of hard spf check
Okay I tested this setup and it seems to work, mail gets through and I get spf=pass for it in Gmail. The only difference to the procedure I posted earlier were: - needed to add srs.xyz.com to morercpthosts and not to rcpthosts as I have more than 50 domains hosted - at the end I ran qmailctl cdb and qmailctl restart, not sure if needed Best, Peter On Tue, Jan 3, 2023 at 11:22 AM Peter Peltonen wrote: > Googling "srs qmailtoaster" gave me this link: > > > http://wiki.qmailtoaster.net/index.php/Configuring_SRS_on_Toaster_1.03-1.3.13%2B > > which does not work, it seems qmailtoaster.com should be used instead of > .net > > Okay now we have the instructions I guess I could try to test it, I have a > spare registered domain I could test with. Does this sound ok procedure: > > >- setup domain xyz.com with SPF with hard fail (-all) and the toaster >as the MX >- send email from xyz.com to GMail through our toaster: should pass ok >- setup forwarding from xyz.com to GMail >- send email to xyz.com: should fail because GMail does not accept >- setup SRS at toaster: > > >1. create NS record for domain srs.xyz.com with MX pointing to our >toaster >2. echo srs.xyz.com > /var/qmail/control/srs_domain >3. mkpasswd -l 32 > /var/qmail/control/srs_secrets >4. mkpasswd -l 32 >> /var/qmail/control/srs_secrets >5. (repeat mkpasswd as many times you need, not sure how many is >really needed?) >6. echo 7 > /var/qmail/control/srs_maxage >7. echo 8 > /var/qmail/control/srs_hashlength >8. qmailctl restart >9. echo srs.xyz.com >> /var/qmail/control/rcpthosts >10. echo srs.xyz.com:srs >> /var/qmail/control/virtualdomains >11. echo "| /var/qmail/bin/srsfilter" > >/var/qmail/alias/.qmail-srs-default >(ownershp of other alias files on my server are user alias group >nofiles, so probably this should be changed to the same?) > > >- send email to xyz.com: should pass ok > > > What do you think Angus? > > Best, > Peter > > > On Mon, Jan 2, 2023 at 7:52 PM Angus McIntyre wrote: > >> >> >> Peter Peltonen wrote on 1/2/23 11:57 AM: >> > Some of my toaster users have their email forwarded to Gmail ... Some >> > googling around tells me that SRS could be the solution for this >> > problem. >> > >> > There is info on this at Qmailtoaster Wiki, but the site seems to be >> > somehow broken. >> >> Which page are you looking at, and in what way does it seem broken? >> >> >> >> http://wiki.qmailtoaster.com/index.php/Configuring_SRS_on_Toaster_1.03-1.3.13%2B >> >> currently loads fine for me, and looks as if it has good information. >> >> I should stress that I haven't tried this yet. I didn't know about SRS >> until you posted this (thank you!) but I'm having the same issue as you >> and it sounds as if this might be just what I need. >> >> Would anyone who's actually implemented this care to comment? >> >> Angus >> >> >> - >> To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com >> For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com >> >>
Re: [qmailtoaster] forwarding to gmail address fails because of hard spf check
Googling "srs qmailtoaster" gave me this link: http://wiki.qmailtoaster.net/index.php/Configuring_SRS_on_Toaster_1.03-1.3.13%2B which does not work, it seems qmailtoaster.com should be used instead of .net Okay now we have the instructions I guess I could try to test it, I have a spare registered domain I could test with. Does this sound ok procedure: - setup domain xyz.com with SPF with hard fail (-all) and the toaster as the MX - send email from xyz.com to GMail through our toaster: should pass ok - setup forwarding from xyz.com to GMail - send email to xyz.com: should fail because GMail does not accept - setup SRS at toaster: 1. create NS record for domain srs.xyz.com with MX pointing to our toaster 2. echo srs.xyz.com > /var/qmail/control/srs_domain 3. mkpasswd -l 32 > /var/qmail/control/srs_secrets 4. mkpasswd -l 32 >> /var/qmail/control/srs_secrets 5. (repeat mkpasswd as many times you need, not sure how many is really needed?) 6. echo 7 > /var/qmail/control/srs_maxage 7. echo 8 > /var/qmail/control/srs_hashlength 8. qmailctl restart 9. echo srs.xyz.com >> /var/qmail/control/rcpthosts 10. echo srs.xyz.com:srs >> /var/qmail/control/virtualdomains 11. echo "| /var/qmail/bin/srsfilter" > /var/qmail/alias/.qmail-srs-default (ownershp of other alias files on my server are user alias group nofiles, so probably this should be changed to the same?) - send email to xyz.com: should pass ok What do you think Angus? Best, Peter On Mon, Jan 2, 2023 at 7:52 PM Angus McIntyre wrote: > > > Peter Peltonen wrote on 1/2/23 11:57 AM: > > Some of my toaster users have their email forwarded to Gmail ... Some > > googling around tells me that SRS could be the solution for this > > problem. > > > > There is info on this at Qmailtoaster Wiki, but the site seems to be > > somehow broken. > > Which page are you looking at, and in what way does it seem broken? > > > > http://wiki.qmailtoaster.com/index.php/Configuring_SRS_on_Toaster_1.03-1.3.13%2B > > currently loads fine for me, and looks as if it has good information. > > I should stress that I haven't tried this yet. I didn't know about SRS > until you posted this (thank you!) but I'm having the same issue as you > and it sounds as if this might be just what I need. > > Would anyone who's actually implemented this care to comment? > > Angus > > > - > To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com > For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com > >
[qmailtoaster] forwarding to gmail address fails because of hard spf check
Some of my toaster users have their email forwarded to Gmail. Earlier this has worked fine, but now there have a been a couple of following cases: 1) user from external domain abc.com with hard SPF fail policy sends an email to xyz.com that is hosted on my toaster 2) my toaster tries forward the email to gmail but fails: Gmail complains with 550-5.7.26 that the sending domain abc.com fails the hard SPF check Some googling around tells me that SRS could be the solution for this problem. There is info on this at Qmailtoaster Wiki, but the site seems to be somehow broken. All pointers how to move forward from here are welcome. Best, Peter
Re: [qmailtoaster] Is it safe to block port 465/smtps and how to prevent brute force guessing
Hi, I received a private reply that the correct logpath is /var/log/qmail/smtpt*/current so that should work. Below are some stats from my server. In the end, I did not disable smpts, as there were a few users using the port and it seems to be a difficult task to change the port in Outlook (requires deleting and adding the account again). What I notice now after a few days (see stats below) following the logs is that there are a lot of failed attempts but only a few get banned because they come from different IPs. So it is very difficult if the attempts are initiated from a botnet with lots of IPs... What I could try to do, is to allow attempts based on IP geo location and then block the rest. Does anyone know if such a configuration could be done easily with some existing tool? Either at qmail or iptables level. # ./f2bstat Status for the jail: qmail-submission-passfail |- Filter | |- Currently failed: 4 | |- Total failed: 8 | `- File list:/var/log/maillog `- Actions |- Currently banned: 0 |- Total banned: 1 `- Banned IP list: Status for the jail: qmail-submission-usernotfound |- Filter | |- Currently failed: 14 | |- Total failed: 177 | `- File list:/var/log/maillog `- Actions |- Currently banned: 4 |- Total banned: 4 `- Banned IP list: 185.28.39.139 185.232.21.210 2.58.46.186 91.103.252.239 Status for the jail: qmail-smtps-passfail |- Filter | |- Currently failed: 1276 | |- Total failed: 3646 | `- File list:/var/log/maillog `- Actions |- Currently banned: 10 |- Total banned: 27 `- Banned IP list: 117.123.14.7 103.249.77.2 220.255.216.14 189.109.236.166 122.252.192.22 136.169.210.132 189.108.147.210 172.245.92.101 192.227.246.107 219.255.134.98 Status for the jail: qmail-smtps-usernotfound |- Filter | |- Currently failed: 685 | |- Total failed: 6302 | `- File list:/var/log/maillog `- Actions |- Currently banned: 11 |- Total banned: 16 `- Banned IP list: 60.174.192.240 76.82.169.64 201.63.178.141 177.86.158.78 41.170.13.250 98.143.104.200 68.55.3.234 211.196.236.250 124.165.66.186 183.99.76.78 67.204.24.218 On Wed, Nov 2, 2022 at 10:13 PM Peter Peltonen wrote: > Thanks and yes, submission has been hacked also of course, but for some > reason, I see the brute force attempts directed only against smtps (at > least during the past days). As I don't use it, it's better to disable it > as then I need only to monitor submission. Changing passwords has been of > course done. > > When following the fail2ban instructions one command failed: > > # cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.conf.bak-`date` > cp: target '2022' is not a directory > > Also in the qmail-smtp-authnotavail filter I see the following entry: > > logpath = /var/log/qmail/smtptx/current > > -> I don't have a such log file, is there a typo in the path? > > I had to disable that filter as fail2ban refuses to start with it. > > Best, > > Peter > > > > On Wed, Nov 2, 2022 at 5:27 AM Eric Broch wrote: > >> And, the instruction on fail2ban should work fine. Submit questions to >> list. >> On 11/1/2022 8:38 PM, Remo Mattei wrote: >> >> I would change all the passwords. >> >> Remo >> >> -- >> Mandato da iPhone >> >> On martedì, nov 01, 2022 at 14:44, Eric Broch >> wrote: >> # qmailctl stop >> >> # touch /var/qmail/supervise/smtps/log/down >> >> # touch /var/qmail/supervise/smtps/down >> >> # qmailctl start >> >> # qmailctl stat >> >> But, if they've hacked smtps then they've also hacked submission; right? >> >> >> On 11/1/2022 1:10 PM, Peter Peltonen wrote: >> >> Hi, >> >> I had an email account password guessed through auth attempts via smtps. >> >> I did not realize this as I had forgotten I had it enabled at all. I >> was looking at the submission log and scratching my head not >> understanding how messages got to the remote queue without anything in >> the submission log, until I realized smpts was enabled and it was >> logging to /var/log/maillog and not to any log under /var/log/qmail... >> >> My first question: is it safe to disable smtps, I guess I don't need >> it for anything as all my users should be using 587/submission instead? >> >> Second question: How do I disable it? Should I just >> remove /var/qmail/supervise/smtps/run file? And/or block it at >> firewall level? >> >> Third question: to prevent brute force attacks, is fail2ban the best >> option to do it? I just follow the instructions at >> http://www.qmailtoaster.com/fail2ban.html ? >> >> Best, >> Peter >> >> >> >> - >> To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com >> For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com >> >>
Re: [qmailtoaster] Is it safe to block port 465/smtps and how to prevent brute force guessing
Thanks and yes, submission has been hacked also of course, but for some reason, I see the brute force attempts directed only against smtps (at least during the past days). As I don't use it, it's better to disable it as then I need only to monitor submission. Changing passwords has been of course done. When following the fail2ban instructions one command failed: # cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.conf.bak-`date` cp: target '2022' is not a directory Also in the qmail-smtp-authnotavail filter I see the following entry: logpath = /var/log/qmail/smtptx/current -> I don't have a such log file, is there a typo in the path? I had to disable that filter as fail2ban refuses to start with it. Best, Peter On Wed, Nov 2, 2022 at 5:27 AM Eric Broch wrote: > And, the instruction on fail2ban should work fine. Submit questions to > list. > On 11/1/2022 8:38 PM, Remo Mattei wrote: > > I would change all the passwords. > > Remo > > -- > Mandato da iPhone > > On martedì, nov 01, 2022 at 14:44, Eric Broch > wrote: > # qmailctl stop > > # touch /var/qmail/supervise/smtps/log/down > > # touch /var/qmail/supervise/smtps/down > > # qmailctl start > > # qmailctl stat > > But, if they've hacked smtps then they've also hacked submission; right? > > > On 11/1/2022 1:10 PM, Peter Peltonen wrote: > > Hi, > > I had an email account password guessed through auth attempts via smtps. > > I did not realize this as I had forgotten I had it enabled at all. I > was looking at the submission log and scratching my head not > understanding how messages got to the remote queue without anything in > the submission log, until I realized smpts was enabled and it was > logging to /var/log/maillog and not to any log under /var/log/qmail... > > My first question: is it safe to disable smtps, I guess I don't need > it for anything as all my users should be using 587/submission instead? > > Second question: How do I disable it? Should I just > remove /var/qmail/supervise/smtps/run file? And/or block it at > firewall level? > > Third question: to prevent brute force attacks, is fail2ban the best > option to do it? I just follow the instructions at > http://www.qmailtoaster.com/fail2ban.html ? > > Best, > Peter > > > > - > To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com > For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com > >
[qmailtoaster] Is it safe to block port 465/smtps and how to prevent brute force guessing
Hi, I had an email account password guessed through auth attempts via smtps. I did not realize this as I had forgotten I had it enabled at all. I was looking at the submission log and scratching my head not understanding how messages got to the remote queue without anything in the submission log, until I realized smpts was enabled and it was logging to /var/log/maillog and not to any log under /var/log/qmail... My first question: is it safe to disable smtps, I guess I don't need it for anything as all my users should be using 587/submission instead? Second question: How do I disable it? Should I just remove /var/qmail/supervise/smtps/run file? And/or block it at firewall level? Third question: to prevent brute force attacks, is fail2ban the best option to do it? I just follow the instructions at http://www.qmailtoaster.com/fail2ban.html ? Best, Peter
Re: [qmailtoaster] TLS connection failed: ciphersuite wrong
27;ve found the > > solution. It seems that the function in the newest version of OpenSSL > > used in qmail-remote to load ciphers suits from the control directory > > has been replaced so the default ciphers are loaded instead of the one > > in the control directory. I've made changes to qmail-remote for the > > latest OpenSSL to support TLS 1.3 and am using the proper function to > > load the ciphers. It has been compiled on my Rocky8 box and I've > > successfully used it to send emails. I can create and new RPM or make > > available the qmail-remote executable for download and testing. Let me > > know which you'd prefer. > > > > Eric > > > > On 3/2/2022 1:02 AM, Peter Peltonen wrote: > >> Any ideas how to solve the TLS connect errors? > >> > >> A bit of a hack that comes to my mind would be to have a cron job to > >> switch back to LEGACY, process the queue and then switch back to > >> DEFAULT? > >> > >> But a more elegant solution would be preferable :) > >> > >> Best, > >> Peter > >> > >> On Tue, Mar 1, 2022 at 9:13 AM Peter Peltonen > >> wrote: > >>> Now after monitoring 36h after the change no cipher related errors, > >>> but a few servers apparently have problems with higher TLS versions: > >>> > >>> TLS_connect_failed:_error:1425F102:SSL_routines:ssl_choose_client_version:unsupported_protocol > >>> > >>> > >>> I assume that this is due to these > >>> /etc/crypto-policies/back-ends/opensslcnf.config settings: > >>> > >>> TLS.MinProtocol = TLSv1.2 > >>> TLS.MaxProtocol = TLSv1.3 > >>> DTLS.MinProtocol = DTLSv1.2 > >>> DTLS.MaxProtocol = DTLSv1.2 > >>> > >>> If I lower MinProtocol to TLSv1.0 would that enable access to those > >>> servers but use the higher protocol version for the rest of the world? > >>> > >>> Best, > >>> Peter > >>> > >>> > >>> On Mon, Feb 28, 2022 at 1:44 AM Eric Broch > >>> wrote: > >>>> I'd like to implement this programmatically so that we can set > >>>> parameters in a /var/qmail/control/sslconf file > >>>> > >>>> On 2/27/2022 2:25 PM, Peter Peltonen wrote: > >>>>> Hi Eric, > >>>>> > >>>>> Okay my crypto-policy is now DEFAULT again and in > >>>>> opensslcnf.config I now have: > >>>>> > >>>>> CipherString = > >>>>> DEFAULT@SECLEVEL=1:kEECDH:kRSA:kEDH:kPSK:kDHEPSK:kECDHEPSK:-aDSS:-3DES:!DES:!RC4:!RC2:!IDEA:-SEED:!eNULL:!aNULL:!MD5:-SHA384:-CAMELLIA:-ARIA:-AESCCM8 > >>>>> > >>>>> I am grepping ssl from qmail/send log. Let's see how it goes. > >>>>> > >>>>> Best, > >>>>> Peter > >>>>> > >>>>> On Thu, Feb 24, 2022 at 7:36 PM Eric Broch > >>>>> wrote: > >>>>>> Peter, > >>>>>> > >>>>>> Can you try something with your server to get mail delivery to > >>>>>> normal. > >>>>>> Run command: > >>>>>> > >>>>>> update-crypto-policies --set DEFAULT > >>>>>> > >>>>>> Edit file /etc/crypto-policies/back-ends/opensslcnf.config > >>>>>> particularly > >>>>>> setting > >>>>>> > >>>>>> CipherString = @SECLEVEL=2 > >>>>>> > >>>>>> change to > >>>>>> > >>>>>> CipherString = DEFAULT@SECLEVEL=1 > >>>>>> > >>>>>> Watch logs > >>>>>> > >>>>>> Eric > >>>>>> > >>>>>> On 2/23/2022 8:53 AM, Peter Peltonen wrote: > >>>>>>> You mean my server with qmail-1.03-3.3.1.qt.md.el8.x86_64 (not > >>>>>>> qmail-1.03-2.2.1) with the LEGACY setting? > >>>>>>> > >>>>>>> As far as I know the only problem I am having is with the > >>>>>>> hornetsecurity.com servers. But to be honest I have not really been > >>>>>>> monitoring the logs that carefully, that's the only server I've > >>>>>>> received a complain about. I now tried sending them email with > >&
Re: [qmailtoaster] TLS connection failed: ciphersuite wrong
Any ideas how to solve the TLS connect errors? A bit of a hack that comes to my mind would be to have a cron job to switch back to LEGACY, process the queue and then switch back to DEFAULT? But a more elegant solution would be preferable :) Best, Peter On Tue, Mar 1, 2022 at 9:13 AM Peter Peltonen wrote: > > Now after monitoring 36h after the change no cipher related errors, > but a few servers apparently have problems with higher TLS versions: > > TLS_connect_failed:_error:1425F102:SSL_routines:ssl_choose_client_version:unsupported_protocol > > I assume that this is due to these > /etc/crypto-policies/back-ends/opensslcnf.config settings: > > TLS.MinProtocol = TLSv1.2 > TLS.MaxProtocol = TLSv1.3 > DTLS.MinProtocol = DTLSv1.2 > DTLS.MaxProtocol = DTLSv1.2 > > If I lower MinProtocol to TLSv1.0 would that enable access to those > servers but use the higher protocol version for the rest of the world? > > Best, > Peter > > > On Mon, Feb 28, 2022 at 1:44 AM Eric Broch wrote: > > > > I'd like to implement this programmatically so that we can set > > parameters in a /var/qmail/control/sslconf file > > > > On 2/27/2022 2:25 PM, Peter Peltonen wrote: > > > Hi Eric, > > > > > > Okay my crypto-policy is now DEFAULT again and in opensslcnf.config I now > > > have: > > > > > > CipherString = > > > DEFAULT@SECLEVEL=1:kEECDH:kRSA:kEDH:kPSK:kDHEPSK:kECDHEPSK:-aDSS:-3DES:!DES:!RC4:!RC2:!IDEA:-SEED:!eNULL:!aNULL:!MD5:-SHA384:-CAMELLIA:-ARIA:-AESCCM8 > > > > > > I am grepping ssl from qmail/send log. Let's see how it goes. > > > > > > Best, > > > Peter > > > > > > On Thu, Feb 24, 2022 at 7:36 PM Eric Broch > > > wrote: > > >> Peter, > > >> > > >> Can you try something with your server to get mail delivery to normal. > > >> Run command: > > >> > > >> update-crypto-policies --set DEFAULT > > >> > > >> Edit file /etc/crypto-policies/back-ends/opensslcnf.config particularly > > >> setting > > >> > > >> CipherString = @SECLEVEL=2 > > >> > > >> change to > > >> > > >> CipherString = DEFAULT@SECLEVEL=1 > > >> > > >> Watch logs > > >> > > >> Eric > > >> > > >> On 2/23/2022 8:53 AM, Peter Peltonen wrote: > > >>> You mean my server with qmail-1.03-3.3.1.qt.md.el8.x86_64 (not > > >>> qmail-1.03-2.2.1) with the LEGACY setting? > > >>> > > >>> As far as I know the only problem I am having is with the > > >>> hornetsecurity.com servers. But to be honest I have not really been > > >>> monitoring the logs that carefully, that's the only server I've > > >>> received a complain about. I now tried sending them email with > > >>> unencrypted connection and it failed. > > >>> > > >>> So I think I will now leave it to LEGACY, accept that I cannot deliver > > >>> mail to the hornet serers and keep monitoring now more closely for TLS > > >>> errors in the logs: if more turn up then I might consider again > > >>> switching to DEFAULT and then adding those servers to notlshosts/ > > >>> although that looks like a nonendint task. > > >>> > > >>> If someone comes up with a solution how I could have the best of both > > >>> worlds (= support everyone), let me know? > > >>> > > >>> Best, > > >>> Peter > > >>> > > >>> On Wed, Feb 23, 2022 at 5:08 PM Eric Broch > > >>> wrote: > > >>>> Does your legacy server qmail-1.03-2.2.1 send to all? > > >>>> > > >>>> On 2/23/2022 8:03 AM, Peter Peltonen wrote: > > >>>>> Here is another error I have now seen qmail/send log about 10 times in > > >>>>> the recent hour: > > >>>>> > > >>>>> TLS_connect_failed:_error:141A318A:SSL_routines:tls_process_ske_dhe:dh_key_too_small > > >>>>> > > >>>>> And this has now happened with two pretty big local service provider's > > >>>>> servers as well. I don't think I can continue with the DEFAULT > > >>>>> setting. I will now try to fall back to LEGACY and see if > > >>>>> hornetsecurity.com accepts unencrypted connections. And I really do > > >>>>> not understand the co
Re: [qmailtoaster] TLS connection failed: ciphersuite wrong
Now after monitoring 36h after the change no cipher related errors, but a few servers apparently have problems with higher TLS versions: TLS_connect_failed:_error:1425F102:SSL_routines:ssl_choose_client_version:unsupported_protocol I assume that this is due to these /etc/crypto-policies/back-ends/opensslcnf.config settings: TLS.MinProtocol = TLSv1.2 TLS.MaxProtocol = TLSv1.3 DTLS.MinProtocol = DTLSv1.2 DTLS.MaxProtocol = DTLSv1.2 If I lower MinProtocol to TLSv1.0 would that enable access to those servers but use the higher protocol version for the rest of the world? Best, Peter On Mon, Feb 28, 2022 at 1:44 AM Eric Broch wrote: > > I'd like to implement this programmatically so that we can set > parameters in a /var/qmail/control/sslconf file > > On 2/27/2022 2:25 PM, Peter Peltonen wrote: > > Hi Eric, > > > > Okay my crypto-policy is now DEFAULT again and in opensslcnf.config I now > > have: > > > > CipherString = > > DEFAULT@SECLEVEL=1:kEECDH:kRSA:kEDH:kPSK:kDHEPSK:kECDHEPSK:-aDSS:-3DES:!DES:!RC4:!RC2:!IDEA:-SEED:!eNULL:!aNULL:!MD5:-SHA384:-CAMELLIA:-ARIA:-AESCCM8 > > > > I am grepping ssl from qmail/send log. Let's see how it goes. > > > > Best, > > Peter > > > > On Thu, Feb 24, 2022 at 7:36 PM Eric Broch wrote: > >> Peter, > >> > >> Can you try something with your server to get mail delivery to normal. > >> Run command: > >> > >> update-crypto-policies --set DEFAULT > >> > >> Edit file /etc/crypto-policies/back-ends/opensslcnf.config particularly > >> setting > >> > >> CipherString = @SECLEVEL=2 > >> > >> change to > >> > >> CipherString = DEFAULT@SECLEVEL=1 > >> > >> Watch logs > >> > >> Eric > >> > >> On 2/23/2022 8:53 AM, Peter Peltonen wrote: > >>> You mean my server with qmail-1.03-3.3.1.qt.md.el8.x86_64 (not > >>> qmail-1.03-2.2.1) with the LEGACY setting? > >>> > >>> As far as I know the only problem I am having is with the > >>> hornetsecurity.com servers. But to be honest I have not really been > >>> monitoring the logs that carefully, that's the only server I've > >>> received a complain about. I now tried sending them email with > >>> unencrypted connection and it failed. > >>> > >>> So I think I will now leave it to LEGACY, accept that I cannot deliver > >>> mail to the hornet serers and keep monitoring now more closely for TLS > >>> errors in the logs: if more turn up then I might consider again > >>> switching to DEFAULT and then adding those servers to notlshosts/ > >>> although that looks like a nonendint task. > >>> > >>> If someone comes up with a solution how I could have the best of both > >>> worlds (= support everyone), let me know? > >>> > >>> Best, > >>> Peter > >>> > >>> On Wed, Feb 23, 2022 at 5:08 PM Eric Broch > >>> wrote: > >>>> Does your legacy server qmail-1.03-2.2.1 send to all? > >>>> > >>>> On 2/23/2022 8:03 AM, Peter Peltonen wrote: > >>>>> Here is another error I have now seen qmail/send log about 10 times in > >>>>> the recent hour: > >>>>> > >>>>> TLS_connect_failed:_error:141A318A:SSL_routines:tls_process_ske_dhe:dh_key_too_small > >>>>> > >>>>> And this has now happened with two pretty big local service provider's > >>>>> servers as well. I don't think I can continue with the DEFAULT > >>>>> setting. I will now try to fall back to LEGACY and see if > >>>>> hornetsecurity.com accepts unencrypted connections. And I really do > >>>>> not understand the core of this problem: why cannot my server just > >>>>> have the whole range of ciphers and protocols in use and apply the > >>>>> most secure / appropriate one that the other party supports? > >>>>> > >>>>> Best, > >>>>> Peter > >>>>> > >>>>> On Wed, Feb 23, 2022 at 4:29 PM Eric Broch > >>>>> wrote: > >>>>>> If I remember correctly it had something to do with Dovecot > >>>>>> On Feb 23, 2022, at 2:25 AM, Peter Peltonen > >>>>>> wrote: > >>>>>>> Hello, > >>>>>>> > >>>>>>> Okay I now tested:: > >>>&
Re: [qmailtoaster] TLS connection failed: ciphersuite wrong
Hi Eric, Okay my crypto-policy is now DEFAULT again and in opensslcnf.config I now have: CipherString = DEFAULT@SECLEVEL=1:kEECDH:kRSA:kEDH:kPSK:kDHEPSK:kECDHEPSK:-aDSS:-3DES:!DES:!RC4:!RC2:!IDEA:-SEED:!eNULL:!aNULL:!MD5:-SHA384:-CAMELLIA:-ARIA:-AESCCM8 I am grepping ssl from qmail/send log. Let's see how it goes. Best, Peter On Thu, Feb 24, 2022 at 7:36 PM Eric Broch wrote: > > Peter, > > Can you try something with your server to get mail delivery to normal. > Run command: > > update-crypto-policies --set DEFAULT > > Edit file /etc/crypto-policies/back-ends/opensslcnf.config particularly > setting > > CipherString = @SECLEVEL=2 > > change to > > CipherString = DEFAULT@SECLEVEL=1 > > Watch logs > > Eric > > On 2/23/2022 8:53 AM, Peter Peltonen wrote: > > You mean my server with qmail-1.03-3.3.1.qt.md.el8.x86_64 (not > > qmail-1.03-2.2.1) with the LEGACY setting? > > > > As far as I know the only problem I am having is with the > > hornetsecurity.com servers. But to be honest I have not really been > > monitoring the logs that carefully, that's the only server I've > > received a complain about. I now tried sending them email with > > unencrypted connection and it failed. > > > > So I think I will now leave it to LEGACY, accept that I cannot deliver > > mail to the hornet serers and keep monitoring now more closely for TLS > > errors in the logs: if more turn up then I might consider again > > switching to DEFAULT and then adding those servers to notlshosts/ > > although that looks like a nonendint task. > > > > If someone comes up with a solution how I could have the best of both > > worlds (= support everyone), let me know? > > > > Best, > > Peter > > > > On Wed, Feb 23, 2022 at 5:08 PM Eric Broch wrote: > >> Does your legacy server qmail-1.03-2.2.1 send to all? > >> > >> On 2/23/2022 8:03 AM, Peter Peltonen wrote: > >>> Here is another error I have now seen qmail/send log about 10 times in > >>> the recent hour: > >>> > >>> TLS_connect_failed:_error:141A318A:SSL_routines:tls_process_ske_dhe:dh_key_too_small > >>> > >>> And this has now happened with two pretty big local service provider's > >>> servers as well. I don't think I can continue with the DEFAULT > >>> setting. I will now try to fall back to LEGACY and see if > >>> hornetsecurity.com accepts unencrypted connections. And I really do > >>> not understand the core of this problem: why cannot my server just > >>> have the whole range of ciphers and protocols in use and apply the > >>> most secure / appropriate one that the other party supports? > >>> > >>> Best, > >>> Peter > >>> > >>> On Wed, Feb 23, 2022 at 4:29 PM Eric Broch > >>> wrote: > >>>> If I remember correctly it had something to do with Dovecot > >>>> On Feb 23, 2022, at 2:25 AM, Peter Peltonen > >>>> wrote: > >>>>> Hello, > >>>>> > >>>>> Okay I now tested:: > >>>>> > >>>>> With LEGACY (which I had earlier) I get the > >>>>> SSL_routines:set_client_ciphesuite:wrong_cipher_returned error in > >>>>> qmail/send log: > >>>>> > >>>>> But with DEFAULT I get Remote_host_said:_250_2.0.0_OK_accept as the > >>>>> result > >>>>> > >>>>> And I did the test without rebooting nor restarting qmail. > >>>>> > >>>>> So apparently this command did the trick like Eric suggested: > >>>>> > >>>>> update-crypto-policies --set DEFAULT > >>>>> > >>>>> Now I wonder if this has some other consequences, what legacy stuff is > >>>>> now incompatible...? > >>>>> > >>>>> Best, > >>>>> Peter > >>>>> > >>>>> > >>>>> ma 21. helmik. 2022 klo 17.55 Eric Broch < ebr...@whitehorsetc.com> > >>>>> kirjoitti: > >>>>>> reboot > >>>>>> > >>>>>> On 2/21/2022 8:30 AM, Peter Peltonen wrote: > >>>>>>> Thanks Eric for the update. Here is what I see: > >>>>>>> > >>>>>>> [root@mail ~]# update-crypto-policies --show > >>>>>>> LEGACY > >>>>>>> [root@mail ~]# update-c
Re: [qmailtoaster] TLS connection failed: ciphersuite wrong
You mean my server with qmail-1.03-3.3.1.qt.md.el8.x86_64 (not qmail-1.03-2.2.1) with the LEGACY setting? As far as I know the only problem I am having is with the hornetsecurity.com servers. But to be honest I have not really been monitoring the logs that carefully, that's the only server I've received a complain about. I now tried sending them email with unencrypted connection and it failed. So I think I will now leave it to LEGACY, accept that I cannot deliver mail to the hornet serers and keep monitoring now more closely for TLS errors in the logs: if more turn up then I might consider again switching to DEFAULT and then adding those servers to notlshosts/ although that looks like a nonendint task. If someone comes up with a solution how I could have the best of both worlds (= support everyone), let me know? Best, Peter On Wed, Feb 23, 2022 at 5:08 PM Eric Broch wrote: > > Does your legacy server qmail-1.03-2.2.1 send to all? > > On 2/23/2022 8:03 AM, Peter Peltonen wrote: > > Here is another error I have now seen qmail/send log about 10 times in > > the recent hour: > > > > TLS_connect_failed:_error:141A318A:SSL_routines:tls_process_ske_dhe:dh_key_too_small > > > > And this has now happened with two pretty big local service provider's > > servers as well. I don't think I can continue with the DEFAULT > > setting. I will now try to fall back to LEGACY and see if > > hornetsecurity.com accepts unencrypted connections. And I really do > > not understand the core of this problem: why cannot my server just > > have the whole range of ciphers and protocols in use and apply the > > most secure / appropriate one that the other party supports? > > > > Best, > > Peter > > > > On Wed, Feb 23, 2022 at 4:29 PM Eric Broch wrote: > >> If I remember correctly it had something to do with Dovecot > >> On Feb 23, 2022, at 2:25 AM, Peter Peltonen > >> wrote: > >>> Hello, > >>> > >>> Okay I now tested:: > >>> > >>> With LEGACY (which I had earlier) I get the > >>> SSL_routines:set_client_ciphesuite:wrong_cipher_returned error in > >>> qmail/send log: > >>> > >>> But with DEFAULT I get Remote_host_said:_250_2.0.0_OK_accept as the result > >>> > >>> And I did the test without rebooting nor restarting qmail. > >>> > >>> So apparently this command did the trick like Eric suggested: > >>> > >>> update-crypto-policies --set DEFAULT > >>> > >>> Now I wonder if this has some other consequences, what legacy stuff is > >>> now incompatible...? > >>> > >>> Best, > >>> Peter > >>> > >>> > >>> ma 21. helmik. 2022 klo 17.55 Eric Broch < ebr...@whitehorsetc.com> > >>> kirjoitti: > >>>> reboot > >>>> > >>>> On 2/21/2022 8:30 AM, Peter Peltonen wrote: > >>>>> Thanks Eric for the update. Here is what I see: > >>>>> > >>>>> [root@mail ~]# update-crypto-policies --show > >>>>> LEGACY > >>>>> [root@mail ~]# update-crypto-policies --set DEFAULT > >>>>> Setting system policy to DEFAULT > >>>>> Note: System-wide crypto policies are applied on application start-up. > >>>>> It is recommended to restart the system for the change of policies > >>>>> to fully take place. > >>>>> > >>>>> Is restarting qmail enough or should I even reboot? > >>>>> > >>>>> And is there some difference between DEFAULT and FUTURE or are they the > >>>>> same? > >>>>> > >>>>> Best, > >>>>> Peter > >>>>> > >>>>> On Mon, Feb 21, 2022 at 4:39 PM Eric Broch < ebr...@whitehorsetc.com> > >>>>> wrote: > >>>>>> Upon further reflection, at the end of the qt/cos8 install script there > >>>>>> is a command, 'update-crypto-policies --set LEGACY' intended for old > >>>>>> email clients I don't wonder if this change between cos7 and cos8 might > >>>>>> caused the problem. Have a look here: > >>>>>> > >>>>>> https://www.redhat.com/en/blog/how-customize-crypto-policies-rhel-82 > >>>>>> > >>>>>> If you've change it to 'update-crypto-policies --set DEFAULT' or > >>>>>> 'update-crypto-policie
Re: [qmailtoaster] TLS connection failed: ciphersuite wrong
Here is another error I have now seen qmail/send log about 10 times in the recent hour: TLS_connect_failed:_error:141A318A:SSL_routines:tls_process_ske_dhe:dh_key_too_small And this has now happened with two pretty big local service provider's servers as well. I don't think I can continue with the DEFAULT setting. I will now try to fall back to LEGACY and see if hornetsecurity.com accepts unencrypted connections. And I really do not understand the core of this problem: why cannot my server just have the whole range of ciphers and protocols in use and apply the most secure / appropriate one that the other party supports? Best, Peter On Wed, Feb 23, 2022 at 4:29 PM Eric Broch wrote: > > If I remember correctly it had something to do with Dovecot > On Feb 23, 2022, at 2:25 AM, Peter Peltonen wrote: >> >> Hello, >> >> Okay I now tested:: >> >> With LEGACY (which I had earlier) I get the >> SSL_routines:set_client_ciphesuite:wrong_cipher_returned error in qmail/send >> log: >> >> But with DEFAULT I get Remote_host_said:_250_2.0.0_OK_accept as the result >> >> And I did the test without rebooting nor restarting qmail. >> >> So apparently this command did the trick like Eric suggested: >> >> update-crypto-policies --set DEFAULT >> >> Now I wonder if this has some other consequences, what legacy stuff is now >> incompatible...? >> >> Best, >> Peter >> >> >> ma 21. helmik. 2022 klo 17.55 Eric Broch < ebr...@whitehorsetc.com> >> kirjoitti: >>> >>> reboot >>> >>> On 2/21/2022 8:30 AM, Peter Peltonen wrote: >>> > Thanks Eric for the update. Here is what I see: >>> > >>> > [root@mail ~]# update-crypto-policies --show >>> > LEGACY >>> > [root@mail ~]# update-crypto-policies --set DEFAULT >>> > Setting system policy to DEFAULT >>> > Note: System-wide crypto policies are applied on application start-up. >>> > It is recommended to restart the system for the change of policies >>> > to fully take place. >>> > >>> > Is restarting qmail enough or should I even reboot? >>> > >>> > And is there some difference between DEFAULT and FUTURE or are they the >>> > same? >>> > >>> > Best, >>> > Peter >>> > >>> > On Mon, Feb 21, 2022 at 4:39 PM Eric Broch < ebr...@whitehorsetc.com> >>> > wrote: >>> >> Upon further reflection, at the end of the qt/cos8 install script there >>> >> is a command, 'update-crypto-policies --set LEGACY' intended for old >>> >> email clients I don't wonder if this change between cos7 and cos8 might >>> >> caused the problem. Have a look here: >>> >> >>> >> https://www.redhat.com/en/blog/how-customize-crypto-policies-rhel-82 >>> >> >>> >> If you've change it to 'update-crypto-policies --set DEFAULT' or >>> >> 'update-crypto-policies --set FUTURE' and are still having issue ask >>> >> hornet security if we can see the actual smtp transaction. >>> >> >>> >> In my earlier email I was saying that there was not much difference >>> >> between the old code and the new code for remote delivery and it was not >>> >> immediately obvious why we would be having a problem. >>> >> >>> >> Eric >>> >> >>> >> >>> >> On 2/21/2022 7:17 AM, Peter Peltonen wrote: >>> >>> Hi, >>> >>> >>> >>> Is there something I can test? I didn't quite understand from Eric's >>> >>> earlier msg what I should try... >>> >>> >>> >>> One email address producing this error for me is >>> >>> supp...@hornetsecurity.com -> If you like Eric, you could try emailing >>> >>> themselves asking for more details (either they reply to you or you >>> >>> will face the same error). If you don't face the same error then we >>> >>> could try figuring out what is different in our setups? >>> >>> >>> >>> Best, >>> >>> Peter >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> On Sat, Feb 19, 2022 at 6:29 PM Eric Broch < ebr...@whitehorsetc.com> >>> >>> wrote: >>> >>>> Looking through the function tls_init() in th
Re: [qmailtoaster] TLS connection failed: ciphersuite wrong
I've been now monitoring my qmail/send log and there has been now two instances of a new error: TLS_connect_failed:_error:1425F102:SSL_routines:ssl_choose_client_version:unsupported_protocol The other one was my own very old qmail box that can do only TLSv1.0/TLSv1.1. So apparently the new setting will break compatibility with the older servers, but I guess that is the expected behaviour with the DEFAULT setting. For now I will just monitor the send log and if I see problematic behaviour I will just add the hostnames to /var/qmail/control/notlshosts/ Best, Peter On Wed, Feb 23, 2022 at 11:25 AM Peter Peltonen wrote: > > Hello, > > Okay I now tested:: > > With LEGACY (which I had earlier) I get the > SSL_routines:set_client_ciphesuite:wrong_cipher_returned error in qmail/send > log: > > But with DEFAULT I get Remote_host_said:_250_2.0.0_OK_accept as the result > > And I did the test without rebooting nor restarting qmail. > > So apparently this command did the trick like Eric suggested: > > update-crypto-policies --set DEFAULT > > Now I wonder if this has some other consequences, what legacy stuff is now > incompatible...? > > Best, > Peter > > > ma 21. helmik. 2022 klo 17.55 Eric Broch kirjoitti: >> >> reboot >> >> On 2/21/2022 8:30 AM, Peter Peltonen wrote: >> > Thanks Eric for the update. Here is what I see: >> > >> > [root@mail ~]# update-crypto-policies --show >> > LEGACY >> > [root@mail ~]# update-crypto-policies --set DEFAULT >> > Setting system policy to DEFAULT >> > Note: System-wide crypto policies are applied on application start-up. >> > It is recommended to restart the system for the change of policies >> > to fully take place. >> > >> > Is restarting qmail enough or should I even reboot? >> > >> > And is there some difference between DEFAULT and FUTURE or are they the >> > same? >> > >> > Best, >> > Peter >> > >> > On Mon, Feb 21, 2022 at 4:39 PM Eric Broch wrote: >> >> Upon further reflection, at the end of the qt/cos8 install script there >> >> is a command, 'update-crypto-policies --set LEGACY' intended for old >> >> email clients I don't wonder if this change between cos7 and cos8 might >> >> caused the problem. Have a look here: >> >> >> >> https://www.redhat.com/en/blog/how-customize-crypto-policies-rhel-82 >> >> >> >> If you've change it to 'update-crypto-policies --set DEFAULT' or >> >> 'update-crypto-policies --set FUTURE' and are still having issue ask >> >> hornet security if we can see the actual smtp transaction. >> >> >> >> In my earlier email I was saying that there was not much difference >> >> between the old code and the new code for remote delivery and it was not >> >> immediately obvious why we would be having a problem. >> >> >> >> Eric >> >> >> >> >> >> On 2/21/2022 7:17 AM, Peter Peltonen wrote: >> >>> Hi, >> >>> >> >>> Is there something I can test? I didn't quite understand from Eric's >> >>> earlier msg what I should try... >> >>> >> >>> One email address producing this error for me is >> >>> supp...@hornetsecurity.com -> If you like Eric, you could try emailing >> >>> themselves asking for more details (either they reply to you or you >> >>> will face the same error). If you don't face the same error then we >> >>> could try figuring out what is different in our setups? >> >>> >> >>> Best, >> >>> Peter >> >>> >> >>> >> >>> >> >>> >> >>> On Sat, Feb 19, 2022 at 6:29 PM Eric Broch >> >>> wrote: >> >>>> Looking through the function tls_init() in the code for qmail-remote.c >> >>>> >> >>>> I don't see much that it could be, they're almost identical between >> >>>> 2.2.1 and 3.3.5 >> >>>> >> >>>> Will continue looking... >> >>>> >> >>>> On 2/18/2022 1:54 PM, Andreas Galatis wrote: >> >>>>> Hi Finn, >> >>>>> >> >>>>> >> >>>>> I have tested with the tlsserverciphers of my older server, completed >> >>>>> with some of the ciphers from the new file and my mails came through. &
Re: [qmailtoaster] TLS connection failed: ciphersuite wrong
Hello, Okay I now tested:: With LEGACY (which I had earlier) I get the SSL_routines:set_client_ciphesuite:wrong_cipher_returned error in qmail/send log: But with DEFAULT I get Remote_host_said:_250_2.0.0_OK_accept as the result And I did the test without rebooting nor restarting qmail. So apparently this command did the trick like Eric suggested: update-crypto-policies --set DEFAULT Now I wonder if this has some other consequences, what legacy stuff is now incompatible...? Best, Peter ma 21. helmik. 2022 klo 17.55 Eric Broch kirjoitti: > reboot > > On 2/21/2022 8:30 AM, Peter Peltonen wrote: > > Thanks Eric for the update. Here is what I see: > > > > [root@mail ~]# update-crypto-policies --show > > LEGACY > > [root@mail ~]# update-crypto-policies --set DEFAULT > > Setting system policy to DEFAULT > > Note: System-wide crypto policies are applied on application start-up. > > It is recommended to restart the system for the change of policies > > to fully take place. > > > > Is restarting qmail enough or should I even reboot? > > > > And is there some difference between DEFAULT and FUTURE or are they the > same? > > > > Best, > > Peter > > > > On Mon, Feb 21, 2022 at 4:39 PM Eric Broch > wrote: > >> Upon further reflection, at the end of the qt/cos8 install script there > >> is a command, 'update-crypto-policies --set LEGACY' intended for old > >> email clients I don't wonder if this change between cos7 and cos8 might > >> caused the problem. Have a look here: > >> > >> https://www.redhat.com/en/blog/how-customize-crypto-policies-rhel-82 > >> > >> If you've change it to 'update-crypto-policies --set DEFAULT' or > >> 'update-crypto-policies --set FUTURE' and are still having issue ask > >> hornet security if we can see the actual smtp transaction. > >> > >> In my earlier email I was saying that there was not much difference > >> between the old code and the new code for remote delivery and it was not > >> immediately obvious why we would be having a problem. > >> > >> Eric > >> > >> > >> On 2/21/2022 7:17 AM, Peter Peltonen wrote: > >>> Hi, > >>> > >>> Is there something I can test? I didn't quite understand from Eric's > >>> earlier msg what I should try... > >>> > >>> One email address producing this error for me is > >>> supp...@hornetsecurity.com -> If you like Eric, you could try emailing > >>> themselves asking for more details (either they reply to you or you > >>> will face the same error). If you don't face the same error then we > >>> could try figuring out what is different in our setups? > >>> > >>> Best, > >>> Peter > >>> > >>> > >>> > >>> > >>> On Sat, Feb 19, 2022 at 6:29 PM Eric Broch > wrote: > >>>> Looking through the function tls_init() in the code for qmail-remote.c > >>>> > >>>> I don't see much that it could be, they're almost identical between > >>>> 2.2.1 and 3.3.5 > >>>> > >>>> Will continue looking... > >>>> > >>>> On 2/18/2022 1:54 PM, Andreas Galatis wrote: > >>>>> Hi Finn, > >>>>> > >>>>> > >>>>> I have tested with the tlsserverciphers of my older server, completed > >>>>> with some of the ciphers from the new file and my mails came through. > >>>>> > >>>>> > >>>>> Thanks a lot for your tip, Finn, I didn't find it in the code > >>>>> > >>>>> > >>>>> Andreas > >>>>> > >>>>> > >>>>> Am 18.02.22 um 16:56 schrieb Qmail: > >>>>>> Hi Andreas. > >>>>>> > >>>>>> In qmail You're properly using /var/qmail/control/tlsclientciphers > >>>>>> (that are a link to tlcserverciphers) > >>>>>> > >>>>>> According to what I read at the Nginx forum, the problem there is > >>>>>> because some of the included ciphers are with underscore '_' and not > >>>>>> hyphen '-' - I don't know if changing that in the tlsservercipher > >>>>>> file will solve the problem. > >>>>>> > >>>>>> > >>&g
Re: [qmailtoaster] TLS connection failed: ciphersuite wrong
Thanks Eric for the update. Here is what I see: [root@mail ~]# update-crypto-policies --show LEGACY [root@mail ~]# update-crypto-policies --set DEFAULT Setting system policy to DEFAULT Note: System-wide crypto policies are applied on application start-up. It is recommended to restart the system for the change of policies to fully take place. Is restarting qmail enough or should I even reboot? And is there some difference between DEFAULT and FUTURE or are they the same? Best, Peter On Mon, Feb 21, 2022 at 4:39 PM Eric Broch wrote: > > Upon further reflection, at the end of the qt/cos8 install script there > is a command, 'update-crypto-policies --set LEGACY' intended for old > email clients I don't wonder if this change between cos7 and cos8 might > caused the problem. Have a look here: > > https://www.redhat.com/en/blog/how-customize-crypto-policies-rhel-82 > > If you've change it to 'update-crypto-policies --set DEFAULT' or > 'update-crypto-policies --set FUTURE' and are still having issue ask > hornet security if we can see the actual smtp transaction. > > In my earlier email I was saying that there was not much difference > between the old code and the new code for remote delivery and it was not > immediately obvious why we would be having a problem. > > Eric > > > On 2/21/2022 7:17 AM, Peter Peltonen wrote: > > Hi, > > > > Is there something I can test? I didn't quite understand from Eric's > > earlier msg what I should try... > > > > One email address producing this error for me is > > supp...@hornetsecurity.com -> If you like Eric, you could try emailing > > themselves asking for more details (either they reply to you or you > > will face the same error). If you don't face the same error then we > > could try figuring out what is different in our setups? > > > > Best, > > Peter > > > > > > > > > > On Sat, Feb 19, 2022 at 6:29 PM Eric Broch wrote: > >> Looking through the function tls_init() in the code for qmail-remote.c > >> > >> I don't see much that it could be, they're almost identical between > >> 2.2.1 and 3.3.5 > >> > >> Will continue looking... > >> > >> On 2/18/2022 1:54 PM, Andreas Galatis wrote: > >>> Hi Finn, > >>> > >>> > >>> I have tested with the tlsserverciphers of my older server, completed > >>> with some of the ciphers from the new file and my mails came through. > >>> > >>> > >>> Thanks a lot for your tip, Finn, I didn't find it in the code > >>> > >>> > >>> Andreas > >>> > >>> > >>> Am 18.02.22 um 16:56 schrieb Qmail: > >>>> Hi Andreas. > >>>> > >>>> In qmail You're properly using /var/qmail/control/tlsclientciphers > >>>> (that are a link to tlcserverciphers) > >>>> > >>>> According to what I read at the Nginx forum, the problem there is > >>>> because some of the included ciphers are with underscore '_' and not > >>>> hyphen '-' - I don't know if changing that in the tlsservercipher > >>>> file will solve the problem. > >>>> > >>>> > >>>> /Finn > >>>> > >>>> Den 18-02-2022 kl. 16:29 skrev Andreas: > >>>>> I cannot find any file where those ciphers could be adjust. > >>>>> Is that compiled in? > >>>>> > >>>>> Me too, I have clients not beeing reachable with the new server > >>>>> (qmail-1.03-3.3.5), but my old server running qmail-1.03.2.2.1.qt. > >>>>> Did anyone find a solution? > >>>>> > >>>>> Andreas > >>>>> > >>>>> Am 17.02.22 um 20:28 schrieb Qmail: > >>>>>> Hi. > >>>>>> > >>>>>> Not sure it is related, but I just read in the Nginx forum that > >>>>>> some have issues (failed (SSL: error:0AB9:SSL routines::no > >>>>>> cipher match)) using Mozillas 'modern' 5.5 ciphers, but everything > >>>>>> works with Mozillas 'modern' ciphers 4.0. > >>>>>> (found testing the Nginx config) > >>>>>> > >>>>>> The 5.5 list contains : > >>>>>> > >>>>>> ssl_ciphers'TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA
Re: [qmailtoaster] TLS connection failed: ciphersuite wrong
Hi, Is there something I can test? I didn't quite understand from Eric's earlier msg what I should try... One email address producing this error for me is supp...@hornetsecurity.com -> If you like Eric, you could try emailing themselves asking for more details (either they reply to you or you will face the same error). If you don't face the same error then we could try figuring out what is different in our setups? Best, Peter On Sat, Feb 19, 2022 at 6:29 PM Eric Broch wrote: > > Looking through the function tls_init() in the code for qmail-remote.c > > I don't see much that it could be, they're almost identical between > 2.2.1 and 3.3.5 > > Will continue looking... > > On 2/18/2022 1:54 PM, Andreas Galatis wrote: > > Hi Finn, > > > > > > I have tested with the tlsserverciphers of my older server, completed > > with some of the ciphers from the new file and my mails came through. > > > > > > Thanks a lot for your tip, Finn, I didn't find it in the code > > > > > > Andreas > > > > > > Am 18.02.22 um 16:56 schrieb Qmail: > >> Hi Andreas. > >> > >> In qmail You're properly using /var/qmail/control/tlsclientciphers > >> (that are a link to tlcserverciphers) > >> > >> According to what I read at the Nginx forum, the problem there is > >> because some of the included ciphers are with underscore '_' and not > >> hyphen '-' - I don't know if changing that in the tlsservercipher > >> file will solve the problem. > >> > >> > >> /Finn > >> > >> Den 18-02-2022 kl. 16:29 skrev Andreas: > >>> I cannot find any file where those ciphers could be adjust. > >>> Is that compiled in? > >>> > >>> Me too, I have clients not beeing reachable with the new server > >>> (qmail-1.03-3.3.5), but my old server running qmail-1.03.2.2.1.qt. > >>> Did anyone find a solution? > >>> > >>> Andreas > >>> > >>> Am 17.02.22 um 20:28 schrieb Qmail: > >>>> Hi. > >>>> > >>>> Not sure it is related, but I just read in the Nginx forum that > >>>> some have issues (failed (SSL: error:0AB9:SSL routines::no > >>>> cipher match)) using Mozillas 'modern' 5.5 ciphers, but everything > >>>> works with Mozillas 'modern' ciphers 4.0. > >>>> (found testing the Nginx config) > >>>> > >>>> The 5.5 list contains : > >>>> > >>>> ssl_ciphers'TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256'; > >>>> > >>>> > >>>> The 4.0 list contains: > >>>> > >>>> ssl_ciphers'ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256'; > >>>> > >>>> > >>>> > >>>> These are matched against the openssl ciphers that are located on > >>>> the server but are more or less same as the tlsclientciphers used > >>>> in qmail. > >>>> > >>>> Nginx can be setup as a MAIL proxy and therefore may be the reason > >>>> for Your issue ?? > >>>> > >>>> or maybe it's just a coincidence ? > >>>> > >>>> Regards, > >>>> Finn > >>>> > >>>> > >>>> > >>>> Den 17-02-2022 kl. 08:14 skrev Andreas: > >>>>> Hi list, > >>>>> I have the same failure-mails with some servers, my version of > >>>>> qmail is > >>>>> qmail-1.03-3.3.5.qt.md.el8.x86_64 > >>>>> > >>>>> TLS connect failed: error:1421C105:SSL > >>>>> routines:set_client_ciphersuite:wrong > >>>>> cipher returnedZConnected to 83.246.65.85 but connection died. > >>>>> > >>>>> With my old server (qmail-1.03-2.2.1.qt.el7.x86_64) I can send > >>>>> emails to the same recipients. > >>>>> Andreas > >>>>> > >>>>> Am 15.02.22 um 09:39 schrieb Peter Peltonen: > >>>>>> What I have installed is qmail-1.03-3.3.1.qt.md.el8.x86_64 > >>>>>> > >>>>>>
Re: [qmailtoaster] TLS connection failed: ciphersuite wrong
What I have installed is qmail-1.03-3.3.1.qt.md.el8.x86_64 Any reason to update? Best, Peter On Sun, Feb 13, 2022 at 5:15 PM Eric Broch wrote: > > What version of qmail ? > > On 2/12/2022 12:56 PM, Peter Peltonen wrote: > > Finally got an answer from them (see list below). I see some matching > > siphers on their and on my own list. Any idea how I could debug this > > more so I can find out why mail is not being delivered to their > > server? > > > > best, > > Peter > > > > " > > OPTON > > All ciphers > > > > DESCRIPTION > > TLS encryption is only possible with ciphers that are considered as > > secure by the German Federal Office for Information Security. A TLS > > connection is only established if the email server of the > > communication partner supports one of the following ciphers: > > > > • ECDHE-RSA-AES256-GCM-SHA384 > > • ECDHE-RSA-AES256-SHA384 > > • ECDHE-RSA-AES256-SHA > > • DHE-RSA-AES256-GCM-SHA384 > > • DHE-RSA-AES256-SHA256 > > • DHE-RSA-AES256-SHA > > • AES256-GCM-SHA384 > > • AES256-SHA256 > > • AES256-SHA > > • ECDHE-RSA-DES-CBC3-SHA > > • EDH-RSA-DES-CBC3-SHA > > • DES-CBC3-SHA > > > > OPTION > > Secure ciphers > > > > DESCRIPTION > > Secure ciphers TLS encryption is only possible with ciphers that are > > considered as secure by the German Federal Office for Information > > Security. A TLS connection is only established if the email > > server of the communication partner supports one of the following ciphers: > > > > • ECDHE-RSA-AES256-GCM-SHA384 > > • ECDHE-RSA-AES256-SHA384 > > • DHE-RSA-AES256-GCM-SHA384 > > • DHE-RSA-AES256-SHA256 > > • ECDHE-RSA-AES128-GCM-SHA256 > > • ECDHE-RSA-AES128-SHA256 > > • DHE-RSA-AES128-GCM-SHA256 > > • DHE-RSA-AES128-SHA256 > > " > > > > > > On Mon, Feb 7, 2022 at 4:08 PM Eric Broch wrote: > >> Is there a way to contact them and find out what obscure B.S. they want? > >> > >> On 2/7/2022 12:26 AM, Peter Peltonen wrote: > >>> When trying to deliver email to a domain that is using spam protection > >>> from antispameurope.com I get the following error: > >>> > >>> deferral: > >>> TLS_connect_failed:_error:1421C105:SSL_routines:set_client_ciphersuite:wrong_cipher_returnedZConnected_to_83.246.65.85_but_connection_died._(#4.4.2)/ > >>> > >>> So am I missing something here: > >>> > >>> [root@mail ~]# cat /var/qmail/control/tlsclientciphers > >>> TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256:TLS_AES_128_CCM_SHA256:DHE-RSA-SEED-SHA:DHE-DSS-SEED-SHA:ADH-SEED-SHA:SEED-SHA:IDEA-CBC-SHA:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-DSS-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES256-CCM8:ECDHE-ECDSA-AES256-CCM:DHE-RSA-AES256-CCM8:DHE-RSA-AES256-CCM:ECDHE-ECDSA-ARIA256-GCM-SHA384:ECDHE-ARIA256-GCM-SHA384:DHE-DSS-ARIA256-GCM-SHA384:DHE-RSA-ARIA256-GCM-SHA384:ADH-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:DHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-CCM8:ECDHE-ECDSA-AES128-CCM:DHE-RSA-AES128-CCM8:DHE-RSA-AES128-CCM:ECDHE-ECDSA-ARIA128-GCM-SHA256:ECDHE-ARIA128-GCM-SHA256:DHE-DSS-ARIA128-GCM-SHA256:DHE-RSA-ARIA128-GCM-SHA256:ADH-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA256:ECDHE-ECDSA-CAMELLIA256-SHA384:ECDHE-RSA-CAMELLIA256-SHA384:DHE-RSA-CAMELLIA256-SHA256:DHE-DSS-CAMELLIA256-SHA256:ADH-AES256-SHA256:ADH-CAMELLIA256-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA256:DHE-DSS-AES128-SHA256:ECDHE-ECDSA-CAMELLIA128-SHA256:ECDHE-RSA-CAMELLIA128-SHA256:DHE-RSA-CAMELLIA128-SHA256:DHE-DSS-CAMELLIA128-SHA256:ADH-AES128-SHA256:ADH-CAMELLIA128-SHA256:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES256-SHA:DHE-DSS-AES256-SHA:DHE-RSA-CAMELLIA256-SHA:DHE-DSS-CAMELLIA256-SHA:AECDH-AES256-SHA:ADH-AES256-SHA:ADH-CAMELLIA256-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA:DHE-RSA-CAMELLIA128-SHA:DHE-DSS-CAMELLIA128-SHA:AECDH-AES128-SHA:ADH-AES128-SHA:ADH-CAMELLIA128-SHA:RSA-PSK-AES256-GCM-SHA384:DHE-PSK-AES256-GCM-SHA384:RSA-PSK-CHACHA20-POLY1305:DHE-PSK-CHACHA20-POLY1305:ECDHE-PSK-CHACHA20-POLY1305:DHE-PSK-AES256-CCM8:DHE-PSK-AES256-CCM:RSA-PSK-ARIA256-GCM-SHA384:DHE-PSK-ARIA256-GCM-SHA384:AES256-GCM-SHA384:AES256-CCM8:AES256-CCM:ARIA256-GCM-SHA384:PSK-AES256-GCM-SHA384:PSK-CHACHA20-POLY1305:PSK-AES256-CCM8:PSK-AES256-CCM:PSK-ARIA256-GCM-SHA384:RSA-PSK-AES128-GCM-S
Re: [qmailtoaster] TLS connection failed: ciphersuite wrong
Finally got an answer from them (see list below). I see some matching siphers on their and on my own list. Any idea how I could debug this more so I can find out why mail is not being delivered to their server? best, Peter " OPTON All ciphers DESCRIPTION TLS encryption is only possible with ciphers that are considered as secure by the German Federal Office for Information Security. A TLS connection is only established if the email server of the communication partner supports one of the following ciphers: • ECDHE-RSA-AES256-GCM-SHA384 • ECDHE-RSA-AES256-SHA384 • ECDHE-RSA-AES256-SHA • DHE-RSA-AES256-GCM-SHA384 • DHE-RSA-AES256-SHA256 • DHE-RSA-AES256-SHA • AES256-GCM-SHA384 • AES256-SHA256 • AES256-SHA • ECDHE-RSA-DES-CBC3-SHA • EDH-RSA-DES-CBC3-SHA • DES-CBC3-SHA OPTION Secure ciphers DESCRIPTION Secure ciphers TLS encryption is only possible with ciphers that are considered as secure by the German Federal Office for Information Security. A TLS connection is only established if the email server of the communication partner supports one of the following ciphers: • ECDHE-RSA-AES256-GCM-SHA384 • ECDHE-RSA-AES256-SHA384 • DHE-RSA-AES256-GCM-SHA384 • DHE-RSA-AES256-SHA256 • ECDHE-RSA-AES128-GCM-SHA256 • ECDHE-RSA-AES128-SHA256 • DHE-RSA-AES128-GCM-SHA256 • DHE-RSA-AES128-SHA256 " On Mon, Feb 7, 2022 at 4:08 PM Eric Broch wrote: > > Is there a way to contact them and find out what obscure B.S. they want? > > On 2/7/2022 12:26 AM, Peter Peltonen wrote: > > When trying to deliver email to a domain that is using spam protection > > from antispameurope.com I get the following error: > > > > deferral: > > TLS_connect_failed:_error:1421C105:SSL_routines:set_client_ciphersuite:wrong_cipher_returnedZConnected_to_83.246.65.85_but_connection_died._(#4.4.2)/ > > > > So am I missing something here: > > > > [root@mail ~]# cat /var/qmail/control/tlsclientciphers > > TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256:TLS_AES_128_CCM_SHA256:DHE-RSA-SEED-SHA:DHE-DSS-SEED-SHA:ADH-SEED-SHA:SEED-SHA:IDEA-CBC-SHA:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-DSS-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES256-CCM8:ECDHE-ECDSA-AES256-CCM:DHE-RSA-AES256-CCM8:DHE-RSA-AES256-CCM:ECDHE-ECDSA-ARIA256-GCM-SHA384:ECDHE-ARIA256-GCM-SHA384:DHE-DSS-ARIA256-GCM-SHA384:DHE-RSA-ARIA256-GCM-SHA384:ADH-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:DHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-CCM8:ECDHE-ECDSA-AES128-CCM:DHE-RSA-AES128-CCM8:DHE-RSA-AES128-CCM:ECDHE-ECDSA-ARIA128-GCM-SHA256:ECDHE-ARIA128-GCM-SHA256:DHE-DSS-ARIA128-GCM-SHA256:DHE-RSA-ARIA128-GCM-SHA256:ADH-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA256:ECDHE-ECDSA-CAMELLIA256-SHA384:ECDHE-RSA-CAMELLIA256-SHA384:DHE-RSA-CAMELLIA256-SHA256:DHE-DSS-CAMELLIA256-SHA256:ADH-AES256-SHA256:ADH-CAMELLIA256-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA256:DHE-DSS-AES128-SHA256:ECDHE-ECDSA-CAMELLIA128-SHA256:ECDHE-RSA-CAMELLIA128-SHA256:DHE-RSA-CAMELLIA128-SHA256:DHE-DSS-CAMELLIA128-SHA256:ADH-AES128-SHA256:ADH-CAMELLIA128-SHA256:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES256-SHA:DHE-DSS-AES256-SHA:DHE-RSA-CAMELLIA256-SHA:DHE-DSS-CAMELLIA256-SHA:AECDH-AES256-SHA:ADH-AES256-SHA:ADH-CAMELLIA256-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA:DHE-RSA-CAMELLIA128-SHA:DHE-DSS-CAMELLIA128-SHA:AECDH-AES128-SHA:ADH-AES128-SHA:ADH-CAMELLIA128-SHA:RSA-PSK-AES256-GCM-SHA384:DHE-PSK-AES256-GCM-SHA384:RSA-PSK-CHACHA20-POLY1305:DHE-PSK-CHACHA20-POLY1305:ECDHE-PSK-CHACHA20-POLY1305:DHE-PSK-AES256-CCM8:DHE-PSK-AES256-CCM:RSA-PSK-ARIA256-GCM-SHA384:DHE-PSK-ARIA256-GCM-SHA384:AES256-GCM-SHA384:AES256-CCM8:AES256-CCM:ARIA256-GCM-SHA384:PSK-AES256-GCM-SHA384:PSK-CHACHA20-POLY1305:PSK-AES256-CCM8:PSK-AES256-CCM:PSK-ARIA256-GCM-SHA384:RSA-PSK-AES128-GCM-SHA256:DHE-PSK-AES128-GCM-SHA256:DHE-PSK-AES128-CCM8:DHE-PSK-AES128-CCM:RSA-PSK-ARIA128-GCM-SHA256:DHE-PSK-ARIA128-GCM-SHA256:AES128-GCM-SHA256:AES128-CCM8:AES128-CCM:ARIA128-GCM-SHA256:PSK-AES128-GCM-SHA256:PSK-AES128-CCM8:PSK-AES128-CCM:PSK-ARIA128-GCM-SHA256:AES256-SHA256:CAMELLIA256-SHA256:AES128-SHA256:CAMELLIA128-SHA256:ECDHE-PSK-AES256-CBC-SHA384:ECDHE-PSK-AES256-CBC-SHA:SRP-DSS-AES-256-CBC-SHA:SRP-RSA-AES-256-CBC-SHA:SRP-AES-256-CBC-SHA:RSA-PSK-AES256-CBC-SHA384:DHE-PSK-AES256-CBC-SHA384:RSA-PSK-AES256-CBC-SHA:DHE-PSK-AES256-CBC-SHA:ECDHE-PSK-CAMELLIA256-SHA384:RSA-PSK-CAMELLIA256-SHA384:DHE-PSK-CAMELLIA256-SHA384:AES256-SHA:CAMELLIA256-SHA:PSK-AES256-CBC-SHA384:PSK-AES256-CBC-SHA:PSK-CAMELLIA256-SHA384:ECDHE-PSK-AES128-CBC-SHA256:ECDHE-PSK-AES128-CBC-SHA:SRP-DSS-AES-128-CBC-SHA:SRP-RSA-AES-128-CBC-SHA:SRP-AES-128-CBC-SHA:RSA-PSK-AES
[qmailtoaster] TLS connection failed: ciphersuite wrong
When trying to deliver email to a domain that is using spam protection from antispameurope.com I get the following error: deferral: TLS_connect_failed:_error:1421C105:SSL_routines:set_client_ciphersuite:wrong_cipher_returnedZConnected_to_83.246.65.85_but_connection_died._(#4.4.2)/ So am I missing something here: [root@mail ~]# cat /var/qmail/control/tlsclientciphers TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256:TLS_AES_128_CCM_SHA256:DHE-RSA-SEED-SHA:DHE-DSS-SEED-SHA:ADH-SEED-SHA:SEED-SHA:IDEA-CBC-SHA:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-DSS-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES256-CCM8:ECDHE-ECDSA-AES256-CCM:DHE-RSA-AES256-CCM8:DHE-RSA-AES256-CCM:ECDHE-ECDSA-ARIA256-GCM-SHA384:ECDHE-ARIA256-GCM-SHA384:DHE-DSS-ARIA256-GCM-SHA384:DHE-RSA-ARIA256-GCM-SHA384:ADH-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:DHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-CCM8:ECDHE-ECDSA-AES128-CCM:DHE-RSA-AES128-CCM8:DHE-RSA-AES128-CCM:ECDHE-ECDSA-ARIA128-GCM-SHA256:ECDHE-ARIA128-GCM-SHA256:DHE-DSS-ARIA128-GCM-SHA256:DHE-RSA-ARIA128-GCM-SHA256:ADH-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA256:ECDHE-ECDSA-CAMELLIA256-SHA384:ECDHE-RSA-CAMELLIA256-SHA384:DHE-RSA-CAMELLIA256-SHA256:DHE-DSS-CAMELLIA256-SHA256:ADH-AES256-SHA256:ADH-CAMELLIA256-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA256:DHE-DSS-AES128-SHA256:ECDHE-ECDSA-CAMELLIA128-SHA256:ECDHE-RSA-CAMELLIA128-SHA256:DHE-RSA-CAMELLIA128-SHA256:DHE-DSS-CAMELLIA128-SHA256:ADH-AES128-SHA256:ADH-CAMELLIA128-SHA256:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES256-SHA:DHE-DSS-AES256-SHA:DHE-RSA-CAMELLIA256-SHA:DHE-DSS-CAMELLIA256-SHA:AECDH-AES256-SHA:ADH-AES256-SHA:ADH-CAMELLIA256-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA:DHE-RSA-CAMELLIA128-SHA:DHE-DSS-CAMELLIA128-SHA:AECDH-AES128-SHA:ADH-AES128-SHA:ADH-CAMELLIA128-SHA:RSA-PSK-AES256-GCM-SHA384:DHE-PSK-AES256-GCM-SHA384:RSA-PSK-CHACHA20-POLY1305:DHE-PSK-CHACHA20-POLY1305:ECDHE-PSK-CHACHA20-POLY1305:DHE-PSK-AES256-CCM8:DHE-PSK-AES256-CCM:RSA-PSK-ARIA256-GCM-SHA384:DHE-PSK-ARIA256-GCM-SHA384:AES256-GCM-SHA384:AES256-CCM8:AES256-CCM:ARIA256-GCM-SHA384:PSK-AES256-GCM-SHA384:PSK-CHACHA20-POLY1305:PSK-AES256-CCM8:PSK-AES256-CCM:PSK-ARIA256-GCM-SHA384:RSA-PSK-AES128-GCM-SHA256:DHE-PSK-AES128-GCM-SHA256:DHE-PSK-AES128-CCM8:DHE-PSK-AES128-CCM:RSA-PSK-ARIA128-GCM-SHA256:DHE-PSK-ARIA128-GCM-SHA256:AES128-GCM-SHA256:AES128-CCM8:AES128-CCM:ARIA128-GCM-SHA256:PSK-AES128-GCM-SHA256:PSK-AES128-CCM8:PSK-AES128-CCM:PSK-ARIA128-GCM-SHA256:AES256-SHA256:CAMELLIA256-SHA256:AES128-SHA256:CAMELLIA128-SHA256:ECDHE-PSK-AES256-CBC-SHA384:ECDHE-PSK-AES256-CBC-SHA:SRP-DSS-AES-256-CBC-SHA:SRP-RSA-AES-256-CBC-SHA:SRP-AES-256-CBC-SHA:RSA-PSK-AES256-CBC-SHA384:DHE-PSK-AES256-CBC-SHA384:RSA-PSK-AES256-CBC-SHA:DHE-PSK-AES256-CBC-SHA:ECDHE-PSK-CAMELLIA256-SHA384:RSA-PSK-CAMELLIA256-SHA384:DHE-PSK-CAMELLIA256-SHA384:AES256-SHA:CAMELLIA256-SHA:PSK-AES256-CBC-SHA384:PSK-AES256-CBC-SHA:PSK-CAMELLIA256-SHA384:ECDHE-PSK-AES128-CBC-SHA256:ECDHE-PSK-AES128-CBC-SHA:SRP-DSS-AES-128-CBC-SHA:SRP-RSA-AES-128-CBC-SHA:SRP-AES-128-CBC-SHA:RSA-PSK-AES128-CBC-SHA256:DHE-PSK-AES128-CBC-SHA256:RSA-PSK-AES128-CBC-SHA:DHE-PSK-AES128-CBC-SHA:ECDHE-PSK-CAMELLIA128-SHA256:RSA-PSK-CAMELLIA128-SHA256:DHE-PSK-CAMELLIA128-SHA256:AES128-SHA:CAMELLIA128-SHA:PSK-AES128-CBC-SHA256:PSK-AES128-CBC-SHA:PSK-CAMELLIA128-SHA256 ? Best, Peter - To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
Re: [qmailtoaster] Squirrelmail charset problem
Thanks Eric, with the updated rpm now utf8 characters are shown correctly. One issue though: earlier versions of squirrelmail had a link to qmailadmin to change password / set vacation msg under Squirrelmail's options. Now that link is gone. Is there an easy fix to get that back? Best, Peter On Tue, Feb 9, 2021 at 1:06 AM Eric Broch wrote: > > This is a better link > > http://repo.whitehorsetc.com/8/testing/mysql/x86_64/squirrelmail-1.4.23-1.qt.el8.20190710.noarch.rpm > > On 2/8/2021 4:05 PM, Eric Broch wrote: > > Peter, > > I think I have this solved. It worked on my COS 7 system because I had the > EPEL squirrelmail-1.4.23-1 installed w/php-5.4 > > I built this for COS 8 and it is in the my repo. Not sure how long it will > take to propagate across all repos > > Anyway it's here, and it seemed to work with php 7.4, so, not a php issue it > seems but a SM issue. SM has been discontinued for CentOS 8 it seems. > > ftp://ftp.qmailtoaster.org/pub/repo/qmt/CentOS/8/testing/mysql/x86_64/squirrelmail-1.4.23-1.qt.el8.20190710.noarch.rpm > > Eric > > On 2/1/2021 2:37 PM, Peter Peltonen wrote: > > Next some umlaut characters äää <- those characters do not show up > in Squirrelmail - To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
Re: [qmailtoaster] Squirrelmail charset problem
Thanks Eric for testing. What Squirrelmail + PHP version are you using? The problems I am encountering and reports of similar issues I've read happen with PHP 7.4. Best, Peter On Mon, Feb 1, 2021 at 3:53 PM Eric Broch wrote: > Peter, > > Here's a message I sent to myself with the suggested characters: > > On 2/1/2021 6:31 AM, Peter Peltonen wrote: > > Nobody else has this issue with Squirrelmail? You can easily check by > copypasting the following text to both as Subject and Body of the > message, sending the msg to yourself and then trying to view it in > Squirrelmail: > > Next some umlaut characters äää <- those characters do not show up > in Squirrelmail > > Best, > Peter > > On Mon, Jan 25, 2021 at 10:09 PM Peter Peltonen > wrote: > > I got those errors when reloading the INBOX message view with messages > having scandinavian characters (ä ö) in their subjects. > > The characters are not visible either. > > Same thing happens when viewing one of those messages. > > Rainloop webmail shows the messages without any problem. > > Best, > Peter > > On Mon, Jan 25, 2021 at 4:22 PM Eric Broch > wrote: > > I'm not seeing this error. I have two sd linux 8 hosts, one fresh > install and one migrated from centos 8. Is there a certain page with > squirrelmail? > > Eric > > On 1/25/2021 5:59 AM, Peter Peltonen wrote: > > After migrating to SDL8 + latest QMT with > squirrelmail-1.4.22-3.qt.el8.x86_64 I noticed that Squirrelmail cannot > show utf8 characters like a with dots (ä) > > There are errors like this in the php log: > PHP Warning: preg_replace(): The /e modifier is no longer supported, > use preg_replace_callback instead in > /usr/share/squirrelmail/functions/mime.php on line 706 > > This is maybe because the Squirrelmail installed is not compatible with PHP > 7.4? > > I noticed that on the Squirrelmail download page there is a newer > version available: > Stable version snapshots (1.4.23-svn) > squirrelmail-20210125_0200-SVN.stable.tar.gz > > -> quickly browsing this version has different utf8.php and mime.php > functions files than the old version we have. > > I also found some patches from > Github:https://github.com/hannob/squirrelpatches > > What would be the best way to proceed to get these into my Toaster? > > Best, > Peter > > - > To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com > For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com > > - > To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com > For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com > > - > To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com > For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com > >
Re: [qmailtoaster] Squirrelmail charset problem
Nobody else has this issue with Squirrelmail? You can easily check by copypasting the following text to both as Subject and Body of the message, sending the msg to yourself and then trying to view it in Squirrelmail: Next some umlaut characters äää <- those characters do not show up in Squirrelmail Best, Peter On Mon, Jan 25, 2021 at 10:09 PM Peter Peltonen wrote: > > I got those errors when reloading the INBOX message view with messages > having scandinavian characters (ä ö) in their subjects. > > The characters are not visible either. > > Same thing happens when viewing one of those messages. > > Rainloop webmail shows the messages without any problem. > > Best, > Peter > > On Mon, Jan 25, 2021 at 4:22 PM Eric Broch wrote: > > > > I'm not seeing this error. I have two sd linux 8 hosts, one fresh > > install and one migrated from centos 8. Is there a certain page with > > squirrelmail? > > > > Eric > > > > On 1/25/2021 5:59 AM, Peter Peltonen wrote: > > > After migrating to SDL8 + latest QMT with > > > squirrelmail-1.4.22-3.qt.el8.x86_64 I noticed that Squirrelmail cannot > > > show utf8 characters like a with dots (ä) > > > > > > There are errors like this in the php log: > > > PHP Warning: preg_replace(): The /e modifier is no longer supported, > > > use preg_replace_callback instead in > > > /usr/share/squirrelmail/functions/mime.php on line 706 > > > > > > This is maybe because the Squirrelmail installed is not compatible with > > > PHP 7.4? > > > > > > I noticed that on the Squirrelmail download page there is a newer > > > version available: > > > Stable version snapshots (1.4.23-svn) > > > squirrelmail-20210125_0200-SVN.stable.tar.gz > > > > > > -> quickly browsing this version has different utf8.php and mime.php > > > functions files than the old version we have. > > > > > > I also found some patches from Github: > > > https://github.com/hannob/squirrelpatches > > > > > > What would be the best way to proceed to get these into my Toaster? > > > > > > Best, > > > Peter > > > > > > - > > > To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com > > > For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com > > > > > > > - > > To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com > > For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com > > - To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
Re: [qmailtoaster] Squirrelmail charset problem
I got those errors when reloading the INBOX message view with messages having scandinavian characters (ä ö) in their subjects. The characters are not visible either. Same thing happens when viewing one of those messages. Rainloop webmail shows the messages without any problem. Best, Peter On Mon, Jan 25, 2021 at 4:22 PM Eric Broch wrote: > > I'm not seeing this error. I have two sd linux 8 hosts, one fresh > install and one migrated from centos 8. Is there a certain page with > squirrelmail? > > Eric > > On 1/25/2021 5:59 AM, Peter Peltonen wrote: > > After migrating to SDL8 + latest QMT with > > squirrelmail-1.4.22-3.qt.el8.x86_64 I noticed that Squirrelmail cannot > > show utf8 characters like a with dots (ä) > > > > There are errors like this in the php log: > > PHP Warning: preg_replace(): The /e modifier is no longer supported, > > use preg_replace_callback instead in > > /usr/share/squirrelmail/functions/mime.php on line 706 > > > > This is maybe because the Squirrelmail installed is not compatible with PHP > > 7.4? > > > > I noticed that on the Squirrelmail download page there is a newer > > version available: > > Stable version snapshots (1.4.23-svn) > > squirrelmail-20210125_0200-SVN.stable.tar.gz > > > > -> quickly browsing this version has different utf8.php and mime.php > > functions files than the old version we have. > > > > I also found some patches from Github: > > https://github.com/hannob/squirrelpatches > > > > What would be the best way to proceed to get these into my Toaster? > > > > Best, > > Peter > > > > - > > To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com > > For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com > > > > - > To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com > For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com > - To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
[qmailtoaster] Squirrelmail charset problem
After migrating to SDL8 + latest QMT with squirrelmail-1.4.22-3.qt.el8.x86_64 I noticed that Squirrelmail cannot show utf8 characters like a with dots (ä) There are errors like this in the php log: PHP Warning: preg_replace(): The /e modifier is no longer supported, use preg_replace_callback instead in /usr/share/squirrelmail/functions/mime.php on line 706 This is maybe because the Squirrelmail installed is not compatible with PHP 7.4? I noticed that on the Squirrelmail download page there is a newer version available: Stable version snapshots (1.4.23-svn) squirrelmail-20210125_0200-SVN.stable.tar.gz -> quickly browsing this version has different utf8.php and mime.php functions files than the old version we have. I also found some patches from Github: https://github.com/hannob/squirrelpatches What would be the best way to proceed to get these into my Toaster? Best, Peter - To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
Re: [qmailtoaster] Re: Cannot access Qmailadmin from Squirrelmail from new SDL8 toaster
Hi, I can confirm it works at least for me. I would of course confirm this first in your default setup before making a change that affects the setup procedure. Best, Peter On Fri, Jan 15, 2021 at 12:25 AM Eric Broch wrote: > > If it works I'll change it. > > On 1/14/2021 3:22 PM, Peter Peltonen wrote: > > Okay just after posting I found an old msg from the list saying I should > > change > > > > # vi /usr/share/squirrelmail/plugins/qmailadmin_login/config_default.php > > comment 2, and create 1) > > 1) $qmlogin_cgi_url='/qmailadmin'; > > 2) #$qmlogin_cgi_url='/cgi-bin/qmailadmin'; > > > > Should this be changed in the default configuration perhaps? > > > > Best, > > Peter > > > > On Thu, Jan 14, 2021 at 11:54 PM Peter Peltonen > > wrote: > >> I can access Qmailadmin via http://mytoaster/qmailadmin > >> > >> But when I login to Squirrelmail and go to Options > Account > >> Administration and then enter my password I get > >> > >> Not Found > >> The requested URL was not found on this server. > >> > >> And in the Apache error log: > >> > >> AH01264: script not found or unable to stat: > >> /var/www/cgi-bin/qmailadmin, referer: > >> http://mytoaster/squirrelmail/plugins/qmailadmin_login/qmlogin_iframe.php > >> > >> Any ideas what is wrong in my setup / how to resolve the issue? > >> > >> Best, > >> Peter > > - > > To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com > > For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com > > > > - > To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com > For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com > - To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
[qmailtoaster] Re: Cannot access Qmailadmin from Squirrelmail from new SDL8 toaster
Okay just after posting I found an old msg from the list saying I should change # vi /usr/share/squirrelmail/plugins/qmailadmin_login/config_default.php comment 2, and create 1) 1) $qmlogin_cgi_url='/qmailadmin'; 2) #$qmlogin_cgi_url='/cgi-bin/qmailadmin'; Should this be changed in the default configuration perhaps? Best, Peter On Thu, Jan 14, 2021 at 11:54 PM Peter Peltonen wrote: > > I can access Qmailadmin via http://mytoaster/qmailadmin > > But when I login to Squirrelmail and go to Options > Account > Administration and then enter my password I get > > Not Found > The requested URL was not found on this server. > > And in the Apache error log: > > AH01264: script not found or unable to stat: > /var/www/cgi-bin/qmailadmin, referer: > http://mytoaster/squirrelmail/plugins/qmailadmin_login/qmlogin_iframe.php > > Any ideas what is wrong in my setup / how to resolve the issue? > > Best, > Peter - To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
[qmailtoaster] Cannot access Qmailadmin from Squirrelmail from new SDL8 toaster
I can access Qmailadmin via http://mytoaster/qmailadmin But when I login to Squirrelmail and go to Options > Account Administration and then enter my password I get Not Found The requested URL was not found on this server. And in the Apache error log: AH01264: script not found or unable to stat: /var/www/cgi-bin/qmailadmin, referer: http://mytoaster/squirrelmail/plugins/qmailadmin_login/qmlogin_iframe.php Any ideas what is wrong in my setup / how to resolve the issue? Best, Peter - To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
Re: [qmailtoaster] Re: SDL8 test install hiccups
Regarding migrating domains and emails from old toaster to the new one I ran into an issue: - In the old toaster in the vpopmail db I have a separate table for each domain. - In the new toaster all domain info go to the same table named vpopmail. Has anyone created a migration script to copy data from old separate tables to the new multi-domain table? Best, Peter On Thu, Dec 31, 2020 at 10:59 PM Peter Peltonen wrote: > > These commands were posted to the CentOS mailing list earlier and they > worked for me: > > curl -O > "https://springdale.math.ias.edu/data/puias/7/x86_64/os/RPM-GPG-KEY-puias"; > > rpm --import RPM-GPG-KEY-puias > > curl -O > "https://springdale.math.ias.edu/data/puias/8/x86_64/os/BaseOS/Packages/springdale-release-8.3-0.42.el8.x86_64.rpm"; > > curl -O > "https://springdale.math.ias.edu/data/puias/8/x86_64/os/BaseOS/Packages/springdale-appstream-8-0.sdl8.2.noarch.rpm"; > > curl -O > "https://springdale.math.ias.edu/data/puias/8/x86_64/os/BaseOS/Packages/springdale-core-8-0.sdl8.2.noarch.rpm"; > > rpm -K springdale-* |grep "digests signatures OK" > > rpm --nodeps -ev centos-linux-release-8.3-1.2011.el8.noarch > centos-linux-repos-8-2.el8.noarch > > yum --releasever 8 localinstall spring* > > yum clean all > > yum distrosync > > reboot > > On Thu, Dec 31, 2020 at 4:32 PM Eric Broch wrote: > > > > Thanks, Peter. > > > > Can you post the migration notes the list? > > > > I'll make it a script. > > > > Eric > > > > On 12/31/2020 3:52 AM, Peter Peltonen wrote: > > > HI, > > > > > > SDL 8 has the same EOL as RHEL 8: May, 2029. > > > > > > SDL existed before CentOS, it's provided by a university, so it should > > > be a good option for the next eight years. > > > > > > Migrating from CentOS 8 to SDL 8 was pretty straightforward, not that > > > many commands. I can provide the migration notes if someone is > > > interested. > > > > > > Best, > > > Peter > > > > > > > > > On Thu, Dec 31, 2020 at 7:29 AM Eric Broch > > > wrote: > > >> Yes, I would recommend staying with CentOS 7 for the time being... > > >> > > >> But, Springdale promises longevity and stability. I was hoping to have > > >> the bases covered. > > >> > > >> The makers of Rocky are predicting having an OS out before next year. > > >> This is the direction I'd really like to head. > > >> > > >> I'm still going to try to get a Debian/Devaun version going as well. > > >> > > >> There is an OpenSUSE version of QMT out now, just trying to keep options > > >> open. > > >> > > >> --Eric > > >> > > >> On 12/30/2020 3:17 PM, r...@mattei.org wrote: > > >> > > >> So the question here is CentOS 8 eol is 2021 not sure it’s even worth > > >> that route. Anyhow that could be a totally diff topic but CentOS 7 looks > > >> to have a longer support life now. > > >> > > >> Il giorno 30 dic 2020, alle ore 12:08, Peter Peltonen > > >> ha scritto: > > >> > > >> Ok it appears my second problem was due to having php74 (and not php) > > >> from remi's repo installed before running the script. > > >> > > >> Removing mariadb-server and php74 and then rerunning the install > > >> script seems to have done the trick. > > >> > > >> Next step to migrate domains from old cos5 server... > > >> > > >> Peter > > >> > > >> On Wed, Dec 30, 2020 at 5:07 PM Peter Peltonen > > >> wrote: > > >> > > >> Hi, > > >> > > >> I tried installing latest QMT using Eric's qt_install_cos8.sh script. > > >> > > >> I have a CentOS 8 VM that I had converted to Springdale Linux 8. > > >> > > >> > > >> I ran into a few issues: > > >> > > >> 1) MariaDB password setup failed somehow. Maybe because I had MariaDB > > >> already installed on this server? I could not access the mariadb > > >> server after this failure, and needed to start the server without > > >> grant tables and then disable "plugin authentication" (I also defined > > >> the pw again just in case): > > >> > > >> service mariadb stop > > >> mysqld_safe --skip-grant-tables &
Re: [qmailtoaster] Re: SDL8 test install hiccups
These commands were posted to the CentOS mailing list earlier and they
worked for me:
curl -O
"https://springdale.math.ias.edu/data/puias/7/x86_64/os/RPM-GPG-KEY-puias";
rpm --import RPM-GPG-KEY-puias
curl -O
"https://springdale.math.ias.edu/data/puias/8/x86_64/os/BaseOS/Packages/springdale-release-8.3-0.42.el8.x86_64.rpm";
curl -O
"https://springdale.math.ias.edu/data/puias/8/x86_64/os/BaseOS/Packages/springdale-appstream-8-0.sdl8.2.noarch.rpm";
curl -O
"https://springdale.math.ias.edu/data/puias/8/x86_64/os/BaseOS/Packages/springdale-core-8-0.sdl8.2.noarch.rpm";
rpm -K springdale-* |grep "digests signatures OK"
rpm --nodeps -ev centos-linux-release-8.3-1.2011.el8.noarch
centos-linux-repos-8-2.el8.noarch
yum --releasever 8 localinstall spring*
yum clean all
yum distrosync
reboot
On Thu, Dec 31, 2020 at 4:32 PM Eric Broch wrote:
>
> Thanks, Peter.
>
> Can you post the migration notes the list?
>
> I'll make it a script.
>
> Eric
>
> On 12/31/2020 3:52 AM, Peter Peltonen wrote:
> > HI,
> >
> > SDL 8 has the same EOL as RHEL 8: May, 2029.
> >
> > SDL existed before CentOS, it's provided by a university, so it should
> > be a good option for the next eight years.
> >
> > Migrating from CentOS 8 to SDL 8 was pretty straightforward, not that
> > many commands. I can provide the migration notes if someone is
> > interested.
> >
> > Best,
> > Peter
> >
> >
> > On Thu, Dec 31, 2020 at 7:29 AM Eric Broch wrote:
> >> Yes, I would recommend staying with CentOS 7 for the time being...
> >>
> >> But, Springdale promises longevity and stability. I was hoping to have the
> >> bases covered.
> >>
> >> The makers of Rocky are predicting having an OS out before next year. This
> >> is the direction I'd really like to head.
> >>
> >> I'm still going to try to get a Debian/Devaun version going as well.
> >>
> >> There is an OpenSUSE version of QMT out now, just trying to keep options
> >> open.
> >>
> >> --Eric
> >>
> >> On 12/30/2020 3:17 PM, r...@mattei.org wrote:
> >>
> >> So the question here is CentOS 8 eol is 2021 not sure it’s even worth that
> >> route. Anyhow that could be a totally diff topic but CentOS 7 looks to
> >> have a longer support life now.
> >>
> >> Il giorno 30 dic 2020, alle ore 12:08, Peter Peltonen
> >> ha scritto:
> >>
> >> Ok it appears my second problem was due to having php74 (and not php)
> >> from remi's repo installed before running the script.
> >>
> >> Removing mariadb-server and php74 and then rerunning the install
> >> script seems to have done the trick.
> >>
> >> Next step to migrate domains from old cos5 server...
> >>
> >> Peter
> >>
> >> On Wed, Dec 30, 2020 at 5:07 PM Peter Peltonen
> >> wrote:
> >>
> >> Hi,
> >>
> >> I tried installing latest QMT using Eric's qt_install_cos8.sh script.
> >>
> >> I have a CentOS 8 VM that I had converted to Springdale Linux 8.
> >>
> >>
> >> I ran into a few issues:
> >>
> >> 1) MariaDB password setup failed somehow. Maybe because I had MariaDB
> >> already installed on this server? I could not access the mariadb
> >> server after this failure, and needed to start the server without
> >> grant tables and then disable "plugin authentication" (I also defined
> >> the pw again just in case):
> >>
> >> service mariadb stop
> >> mysqld_safe --skip-grant-tables &
> >> sudo mysql -u root
> >> [mysql] use mysql;
> >> [mysql] update user set plugin='' where User='root';
> >> [mysql] UPDATE user SET password=PASSWORD("my_password") WHERE user="root";
> >> [mysql] flush privileges;
> >> CTRL+D
> >> mysqladmin -u root -p shutdown
> >> service mariadb start
> >>
> >> I then rerun the part:
> >>
> >> credfile=~/sql.cnf
> >> echo "Creating vpopmail database..."
> >> mysqladmin --defaults-extra-file=$credfile reload
> >> mysqladmin --defaults-extra-file=$credfile refresh
> >> mysqladmin --defaults-extra-file=$credfile create vpopmail
> >> mysqladmin --defaults-extra-file=$credfile reload
> >> mysqladmin --defaults-extra-file=$credfile refresh
> >> echo "Adding vpopmail users and privileges..."
> >> mysql --de
Re: [qmailtoaster] Re: SDL8 test install hiccups
HI,
SDL 8 has the same EOL as RHEL 8: May, 2029.
SDL existed before CentOS, it's provided by a university, so it should
be a good option for the next eight years.
Migrating from CentOS 8 to SDL 8 was pretty straightforward, not that
many commands. I can provide the migration notes if someone is
interested.
Best,
Peter
On Thu, Dec 31, 2020 at 7:29 AM Eric Broch wrote:
>
> Yes, I would recommend staying with CentOS 7 for the time being...
>
> But, Springdale promises longevity and stability. I was hoping to have the
> bases covered.
>
> The makers of Rocky are predicting having an OS out before next year. This is
> the direction I'd really like to head.
>
> I'm still going to try to get a Debian/Devaun version going as well.
>
> There is an OpenSUSE version of QMT out now, just trying to keep options open.
>
> --Eric
>
> On 12/30/2020 3:17 PM, r...@mattei.org wrote:
>
> So the question here is CentOS 8 eol is 2021 not sure it’s even worth that
> route. Anyhow that could be a totally diff topic but CentOS 7 looks to have a
> longer support life now.
>
> Il giorno 30 dic 2020, alle ore 12:08, Peter Peltonen
> ha scritto:
>
> Ok it appears my second problem was due to having php74 (and not php)
> from remi's repo installed before running the script.
>
> Removing mariadb-server and php74 and then rerunning the install
> script seems to have done the trick.
>
> Next step to migrate domains from old cos5 server...
>
> Peter
>
> On Wed, Dec 30, 2020 at 5:07 PM Peter Peltonen
> wrote:
>
> Hi,
>
> I tried installing latest QMT using Eric's qt_install_cos8.sh script.
>
> I have a CentOS 8 VM that I had converted to Springdale Linux 8.
>
>
> I ran into a few issues:
>
> 1) MariaDB password setup failed somehow. Maybe because I had MariaDB
> already installed on this server? I could not access the mariadb
> server after this failure, and needed to start the server without
> grant tables and then disable "plugin authentication" (I also defined
> the pw again just in case):
>
> service mariadb stop
> mysqld_safe --skip-grant-tables &
> sudo mysql -u root
> [mysql] use mysql;
> [mysql] update user set plugin='' where User='root';
> [mysql] UPDATE user SET password=PASSWORD("my_password") WHERE user="root";
> [mysql] flush privileges;
> CTRL+D
> mysqladmin -u root -p shutdown
> service mariadb start
>
> I then rerun the part:
>
> credfile=~/sql.cnf
> echo "Creating vpopmail database..."
> mysqladmin --defaults-extra-file=$credfile reload
> mysqladmin --defaults-extra-file=$credfile refresh
> mysqladmin --defaults-extra-file=$credfile create vpopmail
> mysqladmin --defaults-extra-file=$credfile reload
> mysqladmin --defaults-extra-file=$credfile refresh
> echo "Adding vpopmail users and privileges..."
> mysql --defaults-extra-file=$credfile -e "CREATE USER
> vpopmail@localhost IDENTIFIED BY 'SsEeCcRrEeTt'"
> mysql --defaults-extra-file=$credfile -e "GRANT ALL PRIVILEGES ON
> vpopmail.* TO vpopmail@localhost"
> mysqladmin --defaults-extra-file=$credfile reload
> mysqladmin --defaults-extra-file=$credfile refresh
> echo "Done with vpopmail database..."
>
> BTW should the vpopmail mysql pw be changed to something else or is
> the default pw used somewhere else?
>
>
> 2) Some issues at the end of the script with clamav:
>
> Starting QMT...
> ./qt_install_cos8.sh: line 124: qmailctl: command not found
> Starting clamd freshclam dovecot spamassassin httpd chronyd acpid atd
> autofs smartd named, this may take a while...
> Failed to enable unit: Unit file clamd@scan.service does not exist.
> --2020-12-30 16:47:51--
> https://raw.githubusercontent.com/qmtoaster/scripts/master/toaststat.cos8
> Resolving raw.githubusercontent.com (raw.githubusercontent.com)...
> 151.101.0.133, 151.101.64.133, 151.101.128.133, ...
> Connecting to raw.githubusercontent.com
> (raw.githubusercontent.com)|151.101.0.133|:443... connected.
> HTTP request sent, awaiting response... 200 OK
> Length: 1436 (1.4K) [text/plain]
> Saving to: '/usr/bin/toaststat'
> /usr/bin/toaststat 100%
> Status of toaster services
> cat: /etc/vsftpd/vsftpd.conf: No such file or directory
> mariadb mariadb
> systemd service: clamd@scan.service: [ FAILED ]
> systemd service: clamav-freshclam: [ FAILED ]
> systemd service: spamassassin: [ FAILED ]
> systemd service: dovecot: [ FAILED ]
> systemd service: mariadb: [ OK ]
> systemd service:
[qmailtoaster] Re: SDL8 test install hiccups
Ok it appears my second problem was due to having php74 (and not php)
from remi's repo installed before running the script.
Removing mariadb-server and php74 and then rerunning the install
script seems to have done the trick.
Next step to migrate domains from old cos5 server...
Peter
On Wed, Dec 30, 2020 at 5:07 PM Peter Peltonen wrote:
>
> Hi,
>
> I tried installing latest QMT using Eric's qt_install_cos8.sh script.
>
> I have a CentOS 8 VM that I had converted to Springdale Linux 8.
>
>
> I ran into a few issues:
>
> 1) MariaDB password setup failed somehow. Maybe because I had MariaDB
> already installed on this server? I could not access the mariadb
> server after this failure, and needed to start the server without
> grant tables and then disable "plugin authentication" (I also defined
> the pw again just in case):
>
> service mariadb stop
> mysqld_safe --skip-grant-tables &
> sudo mysql -u root
> [mysql] use mysql;
> [mysql] update user set plugin='' where User='root';
> [mysql] UPDATE user SET password=PASSWORD("my_password") WHERE user="root";
> [mysql] flush privileges;
> CTRL+D
> mysqladmin -u root -p shutdown
> service mariadb start
>
> I then rerun the part:
>
> credfile=~/sql.cnf
> echo "Creating vpopmail database..."
> mysqladmin --defaults-extra-file=$credfile reload
> mysqladmin --defaults-extra-file=$credfile refresh
> mysqladmin --defaults-extra-file=$credfile create vpopmail
> mysqladmin --defaults-extra-file=$credfile reload
> mysqladmin --defaults-extra-file=$credfile refresh
> echo "Adding vpopmail users and privileges..."
> mysql --defaults-extra-file=$credfile -e "CREATE USER
> vpopmail@localhost IDENTIFIED BY 'SsEeCcRrEeTt'"
> mysql --defaults-extra-file=$credfile -e "GRANT ALL PRIVILEGES ON
> vpopmail.* TO vpopmail@localhost"
> mysqladmin --defaults-extra-file=$credfile reload
> mysqladmin --defaults-extra-file=$credfile refresh
> echo "Done with vpopmail database..."
>
> BTW should the vpopmail mysql pw be changed to something else or is
> the default pw used somewhere else?
>
>
> 2) Some issues at the end of the script with clamav:
>
> Starting QMT...
> ./qt_install_cos8.sh: line 124: qmailctl: command not found
> Starting clamd freshclam dovecot spamassassin httpd chronyd acpid atd
> autofs smartd named, this may take a while...
> Failed to enable unit: Unit file clamd@scan.service does not exist.
> --2020-12-30 16:47:51--
> https://raw.githubusercontent.com/qmtoaster/scripts/master/toaststat.cos8
> Resolving raw.githubusercontent.com (raw.githubusercontent.com)...
> 151.101.0.133, 151.101.64.133, 151.101.128.133, ...
> Connecting to raw.githubusercontent.com
> (raw.githubusercontent.com)|151.101.0.133|:443... connected.
> HTTP request sent, awaiting response... 200 OK
> Length: 1436 (1.4K) [text/plain]
> Saving to: '/usr/bin/toaststat'
> /usr/bin/toaststat 100%
> Status of toaster services
> cat: /etc/vsftpd/vsftpd.conf: No such file or directory
> mariadb mariadb
> systemd service: clamd@scan.service: [ FAILED ]
> systemd service: clamav-freshclam: [ FAILED ]
> systemd service: spamassassin: [ FAILED ]
> systemd service: dovecot: [ FAILED ]
> systemd service: mariadb: [ OK ]
> systemd service:httpd: [ OK ]
> systemd service: chronyd: [ OK ]
> systemd service: sshd: [ OK ]
> systemd service:crond: [ OK ]
> systemd service: vsftpd: [ FAILED ]
> systemd service:acpid: [ FAILED ]
> systemd service: atd: [ OK ]
> systemd service: autofs: [ FAILED ]
> systemd service: smartd: [ OK ]
> systemd service: irqbalance: [ OK ]
>
>
> Not sure what went wrong and if I should start debugging or try to do
> a fresh install?
>
>
> Best,
> Peter
-
To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
[qmailtoaster] SDL8 test install hiccups
Hi,
I tried installing latest QMT using Eric's qt_install_cos8.sh script.
I have a CentOS 8 VM that I had converted to Springdale Linux 8.
I ran into a few issues:
1) MariaDB password setup failed somehow. Maybe because I had MariaDB
already installed on this server? I could not access the mariadb
server after this failure, and needed to start the server without
grant tables and then disable "plugin authentication" (I also defined
the pw again just in case):
service mariadb stop
mysqld_safe --skip-grant-tables &
sudo mysql -u root
[mysql] use mysql;
[mysql] update user set plugin='' where User='root';
[mysql] UPDATE user SET password=PASSWORD("my_password") WHERE user="root";
[mysql] flush privileges;
CTRL+D
mysqladmin -u root -p shutdown
service mariadb start
I then rerun the part:
credfile=~/sql.cnf
echo "Creating vpopmail database..."
mysqladmin --defaults-extra-file=$credfile reload
mysqladmin --defaults-extra-file=$credfile refresh
mysqladmin --defaults-extra-file=$credfile create vpopmail
mysqladmin --defaults-extra-file=$credfile reload
mysqladmin --defaults-extra-file=$credfile refresh
echo "Adding vpopmail users and privileges..."
mysql --defaults-extra-file=$credfile -e "CREATE USER
vpopmail@localhost IDENTIFIED BY 'SsEeCcRrEeTt'"
mysql --defaults-extra-file=$credfile -e "GRANT ALL PRIVILEGES ON
vpopmail.* TO vpopmail@localhost"
mysqladmin --defaults-extra-file=$credfile reload
mysqladmin --defaults-extra-file=$credfile refresh
echo "Done with vpopmail database..."
BTW should the vpopmail mysql pw be changed to something else or is
the default pw used somewhere else?
2) Some issues at the end of the script with clamav:
Starting QMT...
./qt_install_cos8.sh: line 124: qmailctl: command not found
Starting clamd freshclam dovecot spamassassin httpd chronyd acpid atd
autofs smartd named, this may take a while...
Failed to enable unit: Unit file clamd@scan.service does not exist.
--2020-12-30 16:47:51--
https://raw.githubusercontent.com/qmtoaster/scripts/master/toaststat.cos8
Resolving raw.githubusercontent.com (raw.githubusercontent.com)...
151.101.0.133, 151.101.64.133, 151.101.128.133, ...
Connecting to raw.githubusercontent.com
(raw.githubusercontent.com)|151.101.0.133|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 1436 (1.4K) [text/plain]
Saving to: '/usr/bin/toaststat'
/usr/bin/toaststat 100%
Status of toaster services
cat: /etc/vsftpd/vsftpd.conf: No such file or directory
mariadb mariadb
systemd service: clamd@scan.service: [ FAILED ]
systemd service: clamav-freshclam: [ FAILED ]
systemd service: spamassassin: [ FAILED ]
systemd service: dovecot: [ FAILED ]
systemd service: mariadb: [ OK ]
systemd service:httpd: [ OK ]
systemd service: chronyd: [ OK ]
systemd service: sshd: [ OK ]
systemd service:crond: [ OK ]
systemd service: vsftpd: [ FAILED ]
systemd service:acpid: [ FAILED ]
systemd service: atd: [ OK ]
systemd service: autofs: [ FAILED ]
systemd service: smartd: [ OK ]
systemd service: irqbalance: [ OK ]
Not sure what went wrong and if I should start debugging or try to do
a fresh install?
Best,
Peter
-
To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
Re: [qmailtoaster] TLS v1.2 on Centos 6, Thunderbird 78
Hi, This problem is also present on older Dovecot on centos5 I still have installed: dovecot-2.0.17-2.qtp -> the older dovecot does not support the possibility to disable sslv3 Eric in your repo's cos5 downloads I saw a more recent dovecot that should support this: dovecot-2.2.7-0.qt.el5.i386.rpm I tried upgrading to it but encountered a dependency problem: # rpm -Uvh dovecot-2.2.7-0.qt.el5.i386.rpm warning: dovecot-2.2.7-0.qt.el5.i386.rpm: Header V3 DSA signature: NOKEY, key ID 1bde5fd0 error: Failed dependencies: libcourierauth.so.0 is needed by (installed) maildrop-toaster-2.0.3-1.3.8.i686 Tips for solving this dependency problem? If it is a lot of work then maybe its not worth the trouble as I should be upgrading to cos8 based install anyway... Best, Peter On Fri, Nov 13, 2020 at 6:50 PM Eric Broch wrote: > > And, > > QMT Dovecot RPMs > > ftp://ftp.qmailtoaster.org/pub/repo/qmt/CentOS/6/testing/x86_64/ > > > On 11/13/2020 9:29 AM, Eric Broch wrote: > > Janno, > > How to > > http://wiki.qmailtoaster.com/index.php/Replacing_Courier_IMAP_with_Dovecot_IMAP > > https://wiki.dovecot.org/Migration/Courier > > Eric > > On 11/13/2020 9:19 AM, Janno Sannik wrote: > > Hi, > > No. Just looked into it. Seems like depencency goes a little grazy if trying > to compile it on centos6. I should convert to new os & dovecot anyway. > Also it seems qmail itself (smtp) was not affected since thunderbird could > send out mail just fine. That would say that qmail itself is using openssl > latest tls as needed. I did not bother to recheck as it is working. > > I should probably dig into courier->dovecot howto that I saw floating aroud > here already instead. > I have made one conversion. I just made everyone with outlook to readd their > mailboxes and I would like to avoid that. > > Thanks for help. > > Janno > > On 13.11.2020 00:01, Eric Broch wrote: > > Have you looked at upgrading: > > http://www.courier-mta.org/imap/download.html > > http://www.courier-mta.org/FAQ.html#rpm > > > On 11/12/2020 12:45 PM, Janno Sannik wrote: > > The stackexchange was the first thing I tried, but it seemed just guesswork > going on in there. > And of course - it did not work. > > Couriertls manpage says that you can use only: > TLS_PROTOCOL=proto > > Set the protocol version. The possible versions are: SSL2, SSL3, TLS1. > > Source: http://manpages.org/couriertls > > The code reveals: > ctx=SSL_CTX_new(protocol && strcmp(protocol, "SSL2") == 0 > ? SSLv2_method(): > protocol && strcmp(protocol, "SSL3") == 0 ? SSLv23_method(): > TLSv1_method()); > > Which is what I saw - whatever garbage I put in the TLS_PROTOCOL variable - > it did not care and defaulted to tlsv1 > > So looking at the openssl man page: > https://www.openssl.org/docs/man1.0.2/man3/TLSv1_method.html > > Luckyly there were sslv2 and sslv3 so I did not need to know much about c > coding and could just directly make a replacement since they are also > absolute. > > diff -Nur courier-imap-4.1.2/tcpd/libcouriertls.c > courier-imap-4.1.2-new/tcpd/libcouriertls.c > --- courier-imap-4.1.2/tcpd/libcouriertls.c 2006-10-28 20:47:32.0 > +0300 > +++ courier-imap-4.1.2-new/tcpd/libcouriertls.c 2020-11-12 21:06:03.338688570 > +0200 > @@ -416,9 +416,9 @@ > memcpy(info_copy, info, sizeof(*info_copy)); > info_copy->isserver=isserver; > > - ctx=SSL_CTX_new(protocol && strcmp(protocol, "SSL2") == 0 > - ? SSLv2_method(): > - protocol && strcmp(protocol, "SSL3") == 0 ? SSLv23_method(): > + ctx=SSL_CTX_new(protocol && strcmp(protocol, "TLS1_1") == 0 > + ? TLSv1_1_method(): > + protocol && strcmp(protocol, "TLS1_2") == 0 ? > TLSv1_2_method(): > > > rpm was built --with cnt5064 (on centos6 system) > > And behold: > > openssl s_client -tls1_2 -connect mail.example.com:993 > > New, TLSv1.2, Cipher is AES256-GCM-SHA384 > Server public key is 2048 bit > Secure Renegotiation IS supported > Compression: NONE > Expansion: NONE > No ALPN negotiated > SSL-Session: > Protocol : TLSv1.2 > Cipher: AES256-GCM-SHA384 > Session-ID: > 175F44FDDE4230DBDD7200B5E276AB1D87206062931B05EAD68A3892DF3CDB68 > Session-ID-ctx: > Master-Key: > F9BDA2CCD78802E8FE2AFD7B440C5E3F5EE8AFD286ABF39F7BCB7796B55D89C5D043207BCB5E8F5C70D372EFAF30CC65 > PSK identity: None > PSK identity hint: None > SRP username: None > TLS session ticket lifetime hint: 7200 (seconds) > TLS session ticket: > > > I'm well aware that I'm fixin a dead horse, but just archiving it to myself > and anyone it might concern of :) > > > On 12.11.2020 20:17, Eric Broch wrote: > > Also > > qmail with updated ssl > > http://repo.whitehorsetc.com/6/development/x86_64/ > > On 11/12/2020 11:10 AM, Eric Broch wrote: > > This may he
[qmailtoaster] How to modify autorespond to not include reply in the vacation msgs?
I have autorespond-toaster-2.0.5-1.4.0 installed on my server. Is there a way to modify it server-wide so that it would not include the original email in the reply? I know it sets the .qmail file where a flag can be used to disable it, but how do I change the default behaviour to set that flag? Best, Peter - To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
Re: [qmailtoaster] Encryption problems with Apple devices
Thanks Miguel, Your suggestion is great when having self signed certificates. It turned out my situation was not because Apple devices were having problems with TLSv1 like I initially thought. A backup server had a technical failure and it had rebooted and then automatically started a backup version of the (virtual) mail server. So the "real" and "backup" server were both online having the same IP. This apparently caused some confusion with the clients :) Took one full day to figure this out white trying all kinds of myriad fixes. I take this as a sign to finally start the migration to newer OS on this server. Now I would need to decide if I should go with COS7 or COS8... Best, Peter On Mon, Aug 24, 2020 at 12:20 AM Miguel Angel Amable Ventura wrote: > > Hi Peter, > > You need to tell your users to delete the pop/imap account completely > (not editing it) and register again just from the very beginning and > they need to be connected to the wifi so the trust certificate shows the > "trust option" to check it (in details) and finish their register. That > can happen when you change the actual certificate or it has expired, I > use my self-signed-certificates and set the expiry time at 10 years > forward. When signing you need to use the option -extensions v3_ca as > follows: > > openssl req -x509 -nodes -days 4825 -newkey rsa:2048 -keyout server1.key > -out server1.crt -extensions v3_ca > cat server.crt server.key > servercert.pem > cp servercert.pem /var/qmail/control/servercert.pem > chmod 640 /var/qmail/control/servercert.pem > chown root.vchkpw /var/qmail/control/servercert.pem > openssl pkcs12 -export -out mail4.pfx -inkey server.key -in server.crt > > When you use that option (extensions) apple/microsoft products can give > you an option to trust your certificate. > > Greetings! > > > El 22/08/2020 a las 04:28 a. m., Peter Peltonen escribió: > > I have an old COS5 qmailtoaster > > > > Since yesterday Apple devices using its Mail program have been > > receiving messages about certificate being not valid. Its a wildcard > > certificate that is being used elsewhere as well so it should be valid > > (it has not been expired). > > > > All other devices / clients seem to work also. > > > > As COS5 openssl uses TLSv1 I started wondering if Apple has deprecated > > it from its Mail clients...? > > > > I do have this fix enabled: > > https://www.qmailtoaster.org/newopensslcnt50.html > > > > But I assume it does not affect Dovecot which is still using the old > > OpenSSL, right? > > > > So my only option really is to upgrade... Should have done it ages ago > > of course. Just wondering if some quick fix came to somebody's mind so > > I could buy some time to do the upgrade with a little more > > preparation? > > > > Best, > > Peter > > > > - > > To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com > > For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com > > > > - > To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com > For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com > - To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
[qmailtoaster] Encryption problems with Apple devices
I have an old COS5 qmailtoaster Since yesterday Apple devices using its Mail program have been receiving messages about certificate being not valid. Its a wildcard certificate that is being used elsewhere as well so it should be valid (it has not been expired). All other devices / clients seem to work also. As COS5 openssl uses TLSv1 I started wondering if Apple has deprecated it from its Mail clients...? I do have this fix enabled: https://www.qmailtoaster.org/newopensslcnt50.html But I assume it does not affect Dovecot which is still using the old OpenSSL, right? So my only option really is to upgrade... Should have done it ages ago of course. Just wondering if some quick fix came to somebody's mind so I could buy some time to do the upgrade with a little more preparation? Best, Peter - To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
Re: [qmailtoaster] Getting multiple copies of emails
In the past I remember this kind thing happening with the old Courier IMAP. Upgrading to Dovecot solved the issue. Buit you probably are running Dovecot already? Best, Peter On Thu, May 30, 2019 at 3:14 AM Jeff Koch wrote: > > > Hi List: > > All of a sudden this morning everyone using one of our QMT7 mailservers has > started getting 6,7,8 copies of each email. This is with IMAP accounts. It > seems as if the mailserver is not registering or marking the emails that they > have already been downloaded. I checked and we don't have multiple copies on > the mailserver itself - just on the email clients that connect to it. > > Any ideas ? Everything was working fine until this morning. > > Regards, Jeff - To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
Re: [qmailtoaster] [solved] ClamAv Soft Reject errors
Thanks Eric! I will test them (probably next week) and let you know how they behave. Best, Peter On Thu, Mar 28, 2019 at 6:15 PM Eric Broch wrote: > > List (CentOS 5 users), > > ClamAV w/pcre & zlib for x86/x86_64 is available in CentOS 5 'current' repo, > here. > > The most recent version of pcre and zlib were required for x86 (i386) > architecture. > > If the links don't work wait for mirrors to synchronize (rsync) or use > www.whitehorsetc.com instead of www.qmailtoaster.com > > Instructions here: https://www.qmailtoaster.org/newopensslclamavcnt50.html > > This tested fine for me, as always, user at your own risk. > > Eric > > On 3/25/2019 3:28 AM, Peter Peltonen wrote: > > Eric, > > is it possible for you to build these for COS5 32bit (i386) also? > > Best, > Peter > > On Mon, Mar 25, 2019 at 8:30 AM Eric Broch wrote: > > Here's the updated ClamAV with Curl Devel >= 8.32 rpm version > > http://www.qmailtoaster.com/newopensslclamavcnt50.html > > > Thanks for taking the lead on this Alexander > > > On 3/22/2019 4:33 AM, Aleksander Podsiadły wrote: > > W dniu czw, 21.03.2019 o godzinie 14∶06 -0600, użytkownik Eric Broch > napisał: > > Yup, you're right Aleksander. > > Now clamav works for me on my CentOS 5. :) > > 8<-- test > Received: by simscan 1.4.0 ppid: 15961, pid: 15964, t: 0.2610s > scanners: attach: 1.4.0 clamav: 0.100.0/m:58/d:25396 > 8<-- EOT test > > HOWTO: > > 1. Download https://ftp.pcre.org/pub/pcre/pcre-8.43.tar.gz > > 2. Compile pcre with different prefix: > mkdir /usr/local/PCRE > ./configure --enable-utf8 --enable-unicode-properties --prefix=/usr/local/PCRE > make > make install > > 3. Modify clamav-toaster.spec and build package. > %configure --with-pcre=/usr/local/PCRE > > 4. Install new clamav-toaster: > rpm -Fvh --nodeps clamav-toaster-0.100.0-1.0.17.x86_64.rpm > > Without > I modified rpmrelease too. > > -- > 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 > > - > To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com > For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com > > -- > 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] [solved] ClamAv Soft Reject errors
Eric, is it possible for you to build these for COS5 32bit (i386) also? Best, Peter On Mon, Mar 25, 2019 at 8:30 AM Eric Broch wrote: > > > Here's the updated ClamAV with Curl Devel >= 8.32 rpm version > > http://www.qmailtoaster.com/newopensslclamavcnt50.html > > > Thanks for taking the lead on this Alexander > > > On 3/22/2019 4:33 AM, Aleksander Podsiadły wrote: > > W dniu czw, 21.03.2019 o godzinie 14∶06 -0600, użytkownik Eric Broch > > napisał: > >> Yup, you're right Aleksander. > > Now clamav works for me on my CentOS 5. :) > > > > 8<-- test > > Received: by simscan 1.4.0 ppid: 15961, pid: 15964, t: 0.2610s > > scanners: attach: 1.4.0 clamav: 0.100.0/m:58/d:25396 > > 8<-- EOT test > > > > HOWTO: > > > > 1. Download https://ftp.pcre.org/pub/pcre/pcre-8.43.tar.gz > > > > 2. Compile pcre with different prefix: > > mkdir /usr/local/PCRE > > ./configure --enable-utf8 --enable-unicode-properties > > --prefix=/usr/local/PCRE > > make > > make install > > > > 3. Modify clamav-toaster.spec and build package. > > %configure --with-pcre=/usr/local/PCRE > > > > 4. Install new clamav-toaster: > > rpm -Fvh --nodeps clamav-toaster-0.100.0-1.0.17.x86_64.rpm > > > > Without > > I modified rpmrelease too. > > > -- > 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 > - To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
Re: [qmailtoaster] ClamAv Soft Reject errors
I got hit with this too... Would it be possible for you Eric to make i386 version available as well? And do I need to get newer pcre from somewhere? I have pcre-6.6-9.el5 installed... Best, Peter On Thu, Mar 21, 2019 at 9:53 PM Eric Broch wrote: > > Well, I could be wrong but while installing clamav-100.2 w/o pcre > support on CentOS 5 I got the pcre errors. When I installed the same > w/pcre support no errors downloading clamav database. It installed fine > on my CentOS 5 x86_64 test box. > > I'll make it available on the repo and get the x86 out shortly. > > On 3/21/2019 1:42 PM, Aleksander Podsiadły wrote: > > W dniu czw, 21.03.2019 o godzinie 12∶27 -0600, użytkownik Eric Broch > > napisał: > >> This is missing the PCRE lib, > > It's not missing, IMHO it's too old library (pcre-6.6-9.el5). > > Look at this discussion: > > https://lists.gt.net/clamav/users/69071 > > > > For me it is the first time when clamav daily.cvd stops qmailtoaster. > > I have to upgrade Centos but it's no so simple. When I buy new one > > server will be occasion. There is no possibility to stop production > > server for days or hours. > > > -- > 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 > - To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
Re: [qmailtoaster] TLS issue how to fix it
Replying to myself:yes at least for me everything worked ok after updating tlsserverciphers with command/usr/bin/openssl101e ciphers > tlsserverciphersCheers,Peter On Wed, Mar 6, 2019 at 3:58 PM Peter Peltonen wrote: > > Hi, > > After upgrading COS5 openssl I still encounter these errors: > > TLS connect failed: error:14077410:SSL > routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure; > connected to > > Am I missing something, should I update also tlsserverciphers after > the openssl upgrade? > > Best, > Peter > > On Tue, Dec 11, 2018 at 9:05 AM Tommi Järvilehto > wrote: > > > > I can confirm that this upgrade does work. > > On a 32bit COS5. Just needed to turn off domainkeys again. This upgrade > > turned it on and crashes. > > > > > > On 6.12.2018 17:11, Eric Broch wrote: > > > Upgrade: > > > > > > https://www.qmailtoaster.org/newopensslcnt50.html > > > > > > or > > > > > > Turn off: > > > > > > https://www.qmailtoaster.org/notls.html > > > > > > > > > On 12/5/2018 11:30 PM, Remo Mattei wrote: > > >> Just want to add the is an old CentOS 5 box. > > >> > > >> Remo > > >> > > >>> On Dec 5, 2018, at 22:24, Remo Mattei wrote: > > >>> > > >>> Any tips on the issue > > >>> > > >>> TLS_connect_failed:_connection_reset;_connected_to_195.200.170.100./ > > >>> > > >>> > > >>> Thanks > > >>> > > >>> - > > >>> To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com > > >>> For additional commands, e-mail: > > >>> qmailtoaster-list-h...@qmailtoaster.com > > >>> > > >> > > >> - > > >> To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com > > >> For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com > > >> > > > > -- > > Tommi Järvilehto > > DataVahti Oy > > 040 732 8032 > > > > > > - > > To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com > > For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com > > - To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
Re: [qmailtoaster] TLS issue how to fix it
Hi, After upgrading COS5 openssl I still encounter these errors: TLS connect failed: error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure; connected to Am I missing something, should I update also tlsserverciphers after the openssl upgrade? Best, Peter On Tue, Dec 11, 2018 at 9:05 AM Tommi Järvilehto wrote: > > I can confirm that this upgrade does work. > On a 32bit COS5. Just needed to turn off domainkeys again. This upgrade > turned it on and crashes. > > > On 6.12.2018 17:11, Eric Broch wrote: > > Upgrade: > > > > https://www.qmailtoaster.org/newopensslcnt50.html > > > > or > > > > Turn off: > > > > https://www.qmailtoaster.org/notls.html > > > > > > On 12/5/2018 11:30 PM, Remo Mattei wrote: > >> Just want to add the is an old CentOS 5 box. > >> > >> Remo > >> > >>> On Dec 5, 2018, at 22:24, Remo Mattei wrote: > >>> > >>> Any tips on the issue > >>> > >>> TLS_connect_failed:_connection_reset;_connected_to_195.200.170.100./ > >>> > >>> > >>> Thanks > >>> > >>> - > >>> To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com > >>> For additional commands, e-mail: > >>> qmailtoaster-list-h...@qmailtoaster.com > >>> > >> > >> - > >> To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com > >> For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com > >> > > -- > Tommi Järvilehto > DataVahti Oy > 040 732 8032 > > > - > To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com > For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com > - To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
[qmailtoaster] Re: messages forwarded by qmail not encrypted
Stupid me: I had two servers and the forwarding account I was testing against had TLS turned off for all outgoing SMTP... So everything working as expected! Sorry for the noise, Peter On Sun, Feb 24, 2019 at 11:38 PM Peter Peltonen wrote: > > Hi, > > I upgraded my TLS setup on my old toaster as instructed by Eric here: > https://www.qmailtoaster.org/newopensslcnt50.html > > Everything else fine except: > > 1) if I send a message to a gmail account directly, the message is encrypted > > 2) if I setup a forward to this gmail account in my toaster say > gmailtest@mytoasteraccount and send a message to to that forward > address, then gmail reports on this message that it was not encrypted > > Conclusion: my toaster forwards messages unencrypted > > Is there a way to turn on encryption for these forwards? > > Best, > Peter - To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
[qmailtoaster] messages forwarded by qmail not encrypted
Hi, I upgraded my TLS setup on my old toaster as instructed by Eric here: https://www.qmailtoaster.org/newopensslcnt50.html Everything else fine except: 1) if I send a message to a gmail account directly, the message is encrypted 2) if I setup a forward to this gmail account in my toaster say gmailtest@mytoasteraccount and send a message to to that forward address, then gmail reports on this message that it was not encrypted Conclusion: my toaster forwards messages unencrypted Is there a way to turn on encryption for these forwards? Best, Peter - To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
Re: [qmailtoaster] TLS issue how to fix it
Easiest for COS5 is to turn off TLS entirely for SMTP: 1. create dir /var/qmail/control/tlshosts 2. create file /var/qmail/control/tlshosts/exhaustivelist If someone knows if this can cause any incompatibilities between any receiving servers, please share your experiences? Best, Peter On Thu, Dec 6, 2018 at 5:11 PM Eric Broch wrote: > > Upgrade: > > https://www.qmailtoaster.org/newopensslcnt50.html > > or > > Turn off: > > https://www.qmailtoaster.org/notls.html > > > On 12/5/2018 11:30 PM, Remo Mattei wrote: > > Just want to add the is an old CentOS 5 box. > > > > Remo > > > >> On Dec 5, 2018, at 22:24, Remo Mattei wrote: > >> > >> Any tips on the issue > >> > >> TLS_connect_failed:_connection_reset;_connected_to_195.200.170.100./ > >> > >> > >> Thanks > >> > >> - > >> To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com > >> For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com > >> > > > > - > > To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com > > For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com > > > -- > 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 > - To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
Re: [qmailtoaster] Slightly Off-Topic: CentOS 7 MariaDB Packages
Hi, what client are you referring to? The only client I am aware of is the CLI mysql command /usr/bin/mysql and that is included in the mariadb package: # rpm -qf /usr/bin/mysql mariadb-5.5.60-1.el7_5.x86_64 Best, Peter On Tue, Nov 13, 2018 at 5:13 AM Roxanne Sandesara wrote: > > I have a QMT box running on CentOS 7. The mariadb packages installed are > upgrades of those that are part of the core CentOS 7 repositories. As such, > currently I have installed: > > mariadb-server-5.5.60-1.el7_5.x86_64 > mariadb-devel-5.5.60-1.el7_5.x86_64 > mariadb-5.5.60-1.el7_5.x86_64 > mariadb-libs-5.5.60-1.el7_5.x86_64 > > I now have another thing I’m trying to get working on the server. It requires > the -client package. However, I cannot find that package in any of the CentOS > 7 repositories. The only place I can find it is in the MariaDB repositories … > which then attempt to install Galera clustering, which I absolutely do not > want. (They also fail in the upgrade attempt, but that’s beside the point.) > > I have noticed that the MariaDB repository packages are camel-cased names > (MariaDB-client rather than mariadb-client). I have tried Google without any > success so far. Does anyone know where I can get either src.rpm or .rpm for > these versions of mariadb-client, mariadb-common, mariadb-shared ? > > > - > To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com > For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com > - To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
Re: [qmailtoaster] bayes setup
Very generic question about teaching spamassassin: If one runs sa-learn against a maildir folder for learning more spam, should that folder: a) contain messages that spamassasin has failed to classify spam or b) contain messages that spamassasin has failed to classify spam AND messages that spamassasin has succeeded in classifying as spam and if the answer is b) does then I suppose it does not matter that the subjects of the messages contain the *** SPAM *** prefix? Same thing goes for ham: should I teach sa against ham classified wrongly as spam only or include correctly identified ham as well? Peter On Thu, Oct 4, 2018 at 3:14 PM Eric Broch wrote: > > Sorry below show be > > # chown vchkpw:vpopmail /etc/spamassassin/.spamassassin > > > On 10/4/2018 6:13 AM, Eric Broch wrote: > > # chown vchkpw:vpopmail drwxr-xr-x2 vpopmail vchkpw 20480 Oct 4 > > 05:57 .spamassassin > > -- > 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 > - To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
Re: [qmailtoaster] rainloop
Great to see that Eric has found Rainloop as well :) One thing I didn't manage to get working was reCAPTCHA witht he pluging provided Have you tried that / succeeded in the installation? Even I have the plugin active I do not see anything related to it in the index.php source code... Best, Peter On Sat, Sep 22, 2018 at 2:31 AM Eric Broch wrote: > > https://www.qmailtoaster.org/rainloop.html > > -- > 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 > - To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
Re: [qmailtoaster] Rainloop removed squirrelmail
Hi, I've been now playing with Rainloop for a few days and really like it. It is simple to setup, it is fast and responsive and it has support for accounts on different IMAP servers. The only thing lacking is the documentation: it would be great to createa a plugin for setting vacation message / password against our toaster, but with the current documentation it might be a too big task... On Tue, Aug 21, 2018 at 6:13 AM Remo Mattei wrote: > > Hello guys, I installed rainloop and removed squirrelmail looks nice, = > fast, supports lots of options. > > Remo >
Re: [qmailtoaster] Requested DIGEST-MD5 scheme, but we have only SHA1
Thanks Andy: I've also found it a bit confusing with different client settings. To the original problem: I removed now DIGEST-MD5 from my auth mechanisms, restarted and all seems fine. Thanks Eric! Best, Peter On Tue, Aug 14, 2018 at 7:42 PM, Andrew Swartz wrote: > My understanding is that RFC compliance is highly variable in email > client-server relationships. This is because servers tend to have > preexisting relationships with clients such that servers can dictate > configurations. Therefore RFC compliance isn't important for > interoperability. > > Using STARTTLS over port 143 is perfectly secure if it is "required." > > The pertinent RFC's is 2595 (June 1999), which I just reviewed. It > specifies (and favors) STARTTLS on port 143 and frowns upon the dedication > of port 993 for TLS. The exact wording is: '*Separate ports imply a model > of either "secure" or "not secure."*' It is interesting that that > concept was frowned upon back then because it has definitely become favored > today. Being in a nebulous/unknown security state leads to false > assumptions which lead to security failure. > > So per the RFC, I stand corrected: port 143 is the designated STARTTLS > port. That makes logical since because the initial handshakes of TLS and > STARTTLS are incompatible, whereas plain-text and STARTTLS both start out > the same. However, going as far back as using Eudora in the late 90's, > I've seen massive variability in IMAP/POP configurations. When the server > gets to dictate configuration to the client in advance, anything goes. > > For example, here is Thunderbird's port 993 options: > > > > > Note that STARTTLS is an option on 993 (along with "none") and that there > is no setting for "required" versus "optional". I've been using > Thunderbird for about 10 years, and I'm pretty sure that prior versions had > a setting for "required" or "optional" for STARTTLS. Eudora definitely had > it. There is a reasonable chance that the Thunderbird developers removed > the setting and that it silently uses "required". But if so, the end > result is an ambiguous security setting from the perspective of > admins/users. That is currently unacceptable. The IMAP/POP server might > be configured for required STARTTLS, but how would the user know that? > Transparency = good, ambiguity = bad. > > > That being said, here is Thunderbird's setting for submission on port 465: > > > > Clearly "None" and "STARTTLS" are not supposed to be supported on port > 465. I imagine they include those options because enough server admins > want them. Again, the clients simply do as their server admins dictate. > > Good question because it prompted me to review the RFC's. > > The password encryption schemes (like digest-md5) are a concept which > predates authentication over an encrypted channel. The problem with > digest-md5 is that the md5 hash is considered broken and completely > insecure for such purposes. The new mantra is to be explicitly secure or > insecure; therefore use of weak security to achieve a nebulous security > situation is slowly becoming outlawed. Here is the wikipedia article about > digest-md5: https://en.wikipedia.org/wiki/Digest_access_authentication > > If you can guarantee an encrypted session (which is always the case with > TLS), then just use PLAIN auth and ignore the password encryption schemes > all together. The advantage of this is that PLAIN will never require > reconfiguration because it has become "broken". > > Again, I hope with is helpful (and accurate). > > -Andy > > > > > > > > > > > On 8/14/2018 1:10 AM, Peter Peltonen wrote: > > Thanks Andy. Just to be sure on this: I had the impression that > STARTTLS could be used also with port 143? At least > readinghttps://wiki.dovecot.org/SSL indicates so: > > "Clients using STARTTLS work by connecting to the regular unencrypted > port and immediately issue a STARTTLS command, after which the session > is encrypted." > > So it shouldn't matter if I use 143 or 993 as a port? > > My users should all use TLS (configured to their clients). I'm still > wondering about the DIGEST-MD5: what is that auth mechanism for and > why did my toaster conf use it? Anything bad that can happen by > removing it? And what is the difference between PLAIN and LOGIN auth > mechanisms? Are there client configs For Outlook / Thunderbird / Apple > Mail that could be broken by this? > > Best, > Peter > > > > On Tue, Aug 14, 2018 at 11:25 AM, Andrew Swartz >
Re: [qmailtoaster] Requested DIGEST-MD5 scheme, but we have only SHA1
Thanks Andy. Just to be sure on this: I had the impression that STARTTLS could be used also with port 143? At least reading https://wiki.dovecot.org/SSL indicates so: "Clients using STARTTLS work by connecting to the regular unencrypted port and immediately issue a STARTTLS command, after which the session is encrypted." So it shouldn't matter if I use 143 or 993 as a port? My users should all use TLS (configured to their clients). I'm still wondering about the DIGEST-MD5: what is that auth mechanism for and why did my toaster conf use it? Anything bad that can happen by removing it? And what is the difference between PLAIN and LOGIN auth mechanisms? Are there client configs For Outlook / Thunderbird / Apple Mail that could be broken by this? Best, Peter On Tue, Aug 14, 2018 at 11:25 AM, Andrew Swartz wrote: > Peter, > > If you are using ports 110/143, which are clear-text, then you should > switch to 993/995 (if possible, of course). > > Ports 993/995 are never intentionally clear-text; they are either TLS or > STARTTLS. Many servers/clients can be configured for either, but they > cannot be configured for both because the initial protocol sequences are > incompatible. > > If 993/995 are configured for TLS, you can use PLAIN auth method and not > give it another thought. > > But if configured for STARTTLS, it must be set to "require" STARTTLS > rather than just "if available". If you can "require" STARTTLS, then > PLAIN auth is secure because the login cannot not be sent unencrpyted. > > But if the connection is configured as "STARTTLS if available", then > failure to initiate the STARTTLS will result in continuing with a clear > text session. In this scenario, a PLAIN auth would be very dangerous. > > Hope this helps. > > -Andy > > > On 8/13/2018 11:43 PM, Peter Peltonen wrote: >> Thanks for the suggestions! >> >> So if I have only plain and login auth mechanisms enabled, what does >> that mean in practice security wise? >> >> Any ideas why the error is happening sometimes but not always and why >> aut_cache settings would fix the problem? Is it related to caching >> credentials for different devices / clients for same account? >> >> Best, >> Peter >> >> On Tue, Aug 14, 2018 at 5:52 AM, Eric Broch wrote: >>> I'd remove DIGEST-MD5 from 'auth_mechanisms'. >>> >>> >>> >>> On 8/13/2018 3:01 PM, Peter Peltonen wrote: >>>> >>>> I have a user with Outlook 2016 having this error appearing in the >>>> Dovecot logs and not being able to login when it occurs >>>> >>>> The strange thing is that if I restart dovecot then the Outlook can >>>> login and no error: >>>> >>>> method=DIGEST-MD5, rip=xxx, lip=yyy, mpid=23280, TLS >>>> >>>> What I have for auth mechanisms in toaster.conf is: >>>> >>>> auth_mechanisms = plain login digest-md5 >>>> >>>> I thought it was a dovecot cache issue and I changed >>>> >>>>cache_key=%u >>>> >>>> to >>>> >>>>cache_key=%u%r >>>> >>>> but the problem reappeared after a week. >>>> >>>> This is an old QMT installation on COS5. >>>> >>>> Best, >>>> Peter >>>> >>>> - >>>> To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com >>>> For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com >>>> >>> >>> -- >>> 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 >>> >> >> - >> To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com >> For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com >> >> > > -- > Andrew W. Swartz, MD > Departments of Emergency Medicine, Family Medicine, and Surgery > Yukon-Kuskokwim Delta Regional Hospital > Bethel, Alaska > - To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
Re: [qmailtoaster] Requested DIGEST-MD5 scheme, but we have only SHA1
Thanks for the suggestions! So if I have only plain and login auth mechanisms enabled, what does that mean in practice security wise? Any ideas why the error is happening sometimes but not always and why aut_cache settings would fix the problem? Is it related to caching credentials for different devices / clients for same account? Best, Peter On Tue, Aug 14, 2018 at 5:52 AM, Eric Broch wrote: > I'd remove DIGEST-MD5 from 'auth_mechanisms'. > > > > On 8/13/2018 3:01 PM, Peter Peltonen wrote: >> >> I have a user with Outlook 2016 having this error appearing in the >> Dovecot logs and not being able to login when it occurs >> >> The strange thing is that if I restart dovecot then the Outlook can >> login and no error: >> >> method=DIGEST-MD5, rip=xxx, lip=yyy, mpid=23280, TLS >> >> What I have for auth mechanisms in toaster.conf is: >> >> auth_mechanisms = plain login digest-md5 >> >> I thought it was a dovecot cache issue and I changed >> >>cache_key=%u >> >> to >> >>cache_key=%u%r >> >> but the problem reappeared after a week. >> >> This is an old QMT installation on COS5. >> >> Best, >> Peter >> >> - >> To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com >> For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com >> > > -- > 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 > - To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
[qmailtoaster] Requested DIGEST-MD5 scheme, but we have only SHA1
I have a user with Outlook 2016 having this error appearing in the Dovecot logs and not being able to login when it occurs The strange thing is that if I restart dovecot then the Outlook can login and no error: method=DIGEST-MD5, rip=xxx, lip=yyy, mpid=23280, TLS What I have for auth mechanisms in toaster.conf is: auth_mechanisms = plain login digest-md5 I thought it was a dovecot cache issue and I changed cache_key=%u to cache_key=%u%r but the problem reappeared after a week. This is an old QMT installation on COS5. Best, Peter - To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
[qmailtoaster] problem with DMARC and forwarded messages
Has anyone encountered the following problem before: msg from us...@non-qmail-host-with-dmarc-in-use.com is sent to us...@qmailtoaster-domain.com and then this message is forwarded from the toaster to us...@gmail.com so userA is using DMARC for his domain when forwarding the message my toaster gets a response from Gmail that DMARC verification failed for non-qmail-host-with-dmarc-in-use.com but if the msg is sent directly from us...@non-qmail-host-with-dmarc-in-use.com to us...@gmail.com it gets through ok. so the problam is in the middle with the toaster the error msg from Gmail being: : User and password not set, continuing without authentication. serveri-ip-here failed after I sent the message. Remote host said: 550-5.7.1 Unauthenticated email from non-qmail-host-with-dmarc-in-use.com is not accepted due to 550-5.7.1 domain's DMARC policy. Please contact the administrator of 550-5.7.1 non-qmail-host-with-dmarc-in-use.com domain if this was a legitimate mail. Please visit 550-5.7.1 https://support.google.com/mail/answer/2451690 to learn about the 550 5.7.1 DMARC initiative. o22-v6si2332322lji.148 - gsmtp ? Best, Peter - To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
Re: [qmailtoaster] Asking the password frequently
Not sure if this relates to any of your problems: I had a few days ago problem with a Outlook 2016 stopping receiving email suddenly. I chased this down to Outlook claming the server did not support the correct authentication method, which was strange as nothing had changed on the server side for a while. The same user's iPhone with the same username/password was working at the same time correctly. What I think it was Dovecot caching credentials somehow wrong: differet caching for iPhone and Outlook causing the problem. I solved it by changing cache_key=%u entries to cache_key=%u%r in /etc/dovecot/toaster.conf so Outlook connecting from different IP got cached differently than the iPhone. Don't know what will happen when they appear in the same WLAN though... Why did this not happen before, I don't know, perhaps Outlook has been updated and uses now some other auth by default than before? Not sure if this relates to your problem at all, as I am running pretty old Dovecot... Best, Peter On Mon, Aug 6, 2018 at 9:19 AM, ChandranManikandan wrote: > Hi Eric, > > Yes, we are using Ubuntu latest 64 bit version, > We tried to configure the imap email and we got the attached message and > couldn't configure it. > > Any one face the same issue. > > Please help me to resolve the issue. > > As well the same issue on Outlook 2016 unable to receive emails. > > Everything work well before but latest version having the issue. > Is it need to install any certificate on our server. > > Am using COS 6 32 bit , Qmailtoaster. > > > > On Mon, Aug 6, 2018 at 1:22 PM, ChandranManikandan > wrote: >> >> Hi Eric, >> >> Yes, we are using Ubuntu latest 64 bit version, >> We tried to configure the imap email and we got the attached message and >> couldn't configure it. >> >> Any one face the same issue. >> >> Please help me to resolve the issue. >> >> As well the same issue on Outlook 2016 unable to receive emails. >> >> Everything work well before but latest version having the issue. >> Is it need to install any certificate on our server. >> >> Am using COS 6 32 bit , Qmailtoaster. >> >> >> >> On Mon, Aug 6, 2018 at 5:59 AM, Eric Broch >> wrote: >>> >>> >>> Just an FYI. >>> If your client is using Ubuntu 18.04 there is an issue with the network >>> stopping on the local pc. >>> To test get your client to use the GUI network manager and disconnect >>> wait >>> a few seconds then reconnect. >>> We are chasing a similar issue now for a client. >>> To see if this is the issue either try pinging out of the network or >>> loading a web page. >>> >>> best wishes >>> Tony White >>> >>> On 03/08/18 01:16, Eric Broch wrote: >>> >>> Can you check if the password for the account is saved in Thunderbird on >>> the Ubuntu desktop? >>> >>> In Thunderbird go to Tools->Options->Security->Saved Passwords >>> >>> >>> On 8/2/2018 4:52 AM, ChandranManikandan wrote: >>> >>> Hi Friends, >>> >>> One of our user getting disconnected frequently from thunderbird (Asking >>> passwords) and webmail also not opening. >>> >>> After restart the dovecot service it will working again. >>> But the password is asking frequently. >>> I have restarted the dovecot service frequently. >>> >>> This problem for only one user rest of other users not an issue. >>> >>> I couldn't trace the logs in /var/log/maillog and /var/log/dovecot.log >>> >>> Anyone face the same issue . >>> >>> Could anyone help me to resolve this issue. >>> >>> Note: User is using Ubuntu Desktop with Thunderbird. >>> >>> -- >>> Thanks & Best Regards, >>> Manikandan.C >>> >>> >>> -- >>> Eric Broch >>> White Horse Technical Consulting (WHTC) >>> >>> >> >> >> >> -- >> Thanks & Best Regards, >> Manikandan.C > > > > > -- > Thanks & Best Regards, > Manikandan.C > > - > To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com > For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com - To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
Re: [qmailtoaster] Clamav service stopped
Stumbled on this on the CentOS mailing list: it seems 32bit CentOS6 has a zlib that doesn't play along with the new clamav: https://bugzilla.redhat.com/show_bug.cgi?id=1600458 I am wondering if this is an issue with qmailtoaster's clamav as well? Peter On Thu, Jul 12, 2018 at 9:40 AM, ChandranManikandan wrote: > Hi Eric, > > Thanks for your support. > The clamd service started successfully > But freshclam shown the below error. > > ClamAV update process started at Thu Jul 12 14:37:30 2018 > WARNING: Your ClamAV installation is OUTDATED! > WARNING: Local version: 0.100.0 Recommended version: 0.100.1 > DON'T PANIC! Read https://www.clamav.net/documents/upgrading-clamav > Downloading main.cvd [100%] > WARNING: [LibClamAV] cli_cvdload: Corrupted CVD header > ERROR: Verification: Malformed database > Giving up on database.clamav.net... > Update failed. Your network may be down or none of the mirrors listed in > /etc/freshclam.conf > > File /var/log/clamav/freshclam.log not changed so no update needed > > > On Thu, Jul 12, 2018 at 1:11 PM, Eric Broch wrote: >> >> you could download the databases manually here: >> >> https://www.clamav.net/downloads >> >> and put them in the folder /var/lib/clamav >> >> >> On 7/11/2018 10:47 PM, ChandranManikandan wrote: >> >> Hi Friends, >> >> I have updated latest simscan and clamav on my COS6 32 bit. >> >> My clamav service stopped and unable to start again. the below message >> come. >> Could anyone help me. >> >> # service clamd restart >> Stopping Clam AntiVirus Daemon:[FAILED] >> Starting Clam AntiVirus Daemon: LibClamAV Error: cli_loaddbdir(): No >> supported d >> atabase files found in /var/lib/clamav >> ERROR: Can't open file or directory >> Closing the main socket. >>[FAILED] >> freshclam command come below message. >> >> >> freshclam >> ClamAV update process started at Thu Jul 12 12:46:31 2018 >> WARNING: Your ClamAV installation is OUTDATED! >> WARNING: Local version: 0.100.0 Recommended version: 0.100.1 >> DON'T PANIC! Read https://www.clamav.net/documents/upgrading-clamav >> WARNING: Can't download main.cvd from db.sg.clamav.net >> Trying again in 5 secs... >> ClamAV update process started at Thu Jul 12 12:46:36 2018 >> WARNING: Your ClamAV installation is OUTDATED! >> WARNING: Local version: 0.100.0 Recommended version: 0.100.1 >> DON'T PANIC! Read https://www.clamav.net/documents/upgrading-clamav >> WARNING: Can't download main.cvd from db.sg.clamav.net >> Trying again in 5 secs... >> ClamAV update process started at Thu Jul 12 12:46:41 2018 >> WARNING: Your ClamAV installation is OUTDATED! >> WARNING: Local version: 0.100.0 Recommended version: 0.100.1 >> DON'T PANIC! Read https://www.clamav.net/documents/upgrading-clamav >> ERROR: Can't download main.cvd from db.sg.clamav.net >> Giving up on db.sg.clamav.net... >> ClamAV update process started at Thu Jul 12 12:46:41 2018 >> WARNING: Your ClamAV installation is OUTDATED! >> WARNING: Local version: 0.100.0 Recommended version: 0.100.1 >> DON'T PANIC! Read https://www.clamav.net/documents/upgrading-clamav >> Downloading main.cvd [100%] >> WARNING: [LibClamAV] cli_cvdload: Corrupted CVD header >> ERROR: Verification: Malformed database >> Giving up on database.clamav.net... >> Update failed. Your network may be down or none of the mirrors listed in >> /etc/freshclam.conf is working. Check >> https://www.clamav.net/documents/official-mirror-faq for possible reasons. >> >> >> -- >> Thanks & Best Regards, >> Manikandan.C >> >> >> -- >> Eric Broch >> White Horse Technical Consulting (WHTC) > > > > > -- > Thanks & Best Regards, > Manikandan.C - To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
Re: [qmailtoaster] Upgrading openssl in an old Qmailtoaster install
Thanks Eric, does this rpm have also the cname lookup remove patch? Best, Peter On Sat, Jun 30, 2018 at 9:06 PM, Eric Broch wrote: > Instructions for setting up greater than openssl-0.9.8 CentOS 5, minimal > testing done. This is done with openssl-1.01e > > https://www.qmailtoaster.org/newopensslcnt50.html > > Eric > > > > On 6/29/2018 4:51 AM, Peter Peltonen wrote: >> >> Great, thanks for sharing! >> >> One question: >> >> Eric had produced an RPM for qmail 1.03-1.3.23.i386 with the CNAME >> lookups removed. >> >> Yours is 1.03-1.3.22 and with CNAME lookups enabled I assume. >> >> How would one migrate the changes you did to Eric's version, as I >> would like to have both: newer TLS support + CNAME lookups removed? >> >> Best, >> Peter >> >> On Fri, Jun 29, 2018 at 10:34 AM, Eric Broch >> wrote: >>> >>> Thanks, Brian!!! >>> >>> >>> On 6/29/2018 1:32 AM, Brian Ghidinelli wrote: >>> >>> Good news - I seemed to have solved this. It's a combo of these old notes >>> from 2011 and an upgraded openssl: >>> >>> http://www.ghidinelli.com/2011/10/20/october-qmail-follow-up >>> >>> I'm attaching my modified qmail-toaster.spec from 1.3.21. I installed >>> openssl-1.0.2o from source on CentOS 5 and linked: >>> >>> /usr/include/openssl -> /usr/local/ssl/include/openssl/ >>> >>> Then I rebuilt the RPM: >>> >>> rpmbuild -bb --target i686 --with cnt50 >>> /usr/src/redhat/SPECS/qmail-toaster.spec >>> >>> This generated the RPM. I extracted the files: >>> >>> rpm2cpio qmail-toaster-1.03-1.3.22.i686.rpm | cpio -idmv >>> >>> I backed up my existing qmail-smtpd and qmail-remote.orig, and copied >>> the new binaries over (from /usr/src/redhat/RPMS/i686/var/qmail/bin >>> where cpio extracted them to) >>> >>> And then tested with checktls.com and everything shows TLS 1.2 now. >>> *whew* >>> >>> This buys us a little time to complete a migration. Hope this helps >>> someone >>> else! >>> >>> >>> Brian >>> >>> >>> On 6/27/18 09:09, Eric Broch wrote: >>> >>> Have a look at this thread: >>> >>> >>> https://www.mail-archive.com/qmailtoaster-list@qmailtoaster.com/msg41029.html >>> >>> IMHO, there were to many packages that were dependent on openssl-9.8 on >>> the >>> CentOS 5 box to make this practical. >>> >>> >>> >>> >>> - >>> To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com >>> For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com >>> >>> >>> -- >>> 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 >> > > -- > 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 > - To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
Re: [qmailtoaster] Upgrading openssl in an old Qmailtoaster install
Great, thanks for sharing! One question: Eric had produced an RPM for qmail 1.03-1.3.23.i386 with the CNAME lookups removed. Yours is 1.03-1.3.22 and with CNAME lookups enabled I assume. How would one migrate the changes you did to Eric's version, as I would like to have both: newer TLS support + CNAME lookups removed? Best, Peter On Fri, Jun 29, 2018 at 10:34 AM, Eric Broch wrote: > Thanks, Brian!!! > > > On 6/29/2018 1:32 AM, Brian Ghidinelli wrote: > > Good news - I seemed to have solved this. It's a combo of these old notes > from 2011 and an upgraded openssl: > > http://www.ghidinelli.com/2011/10/20/october-qmail-follow-up > > I'm attaching my modified qmail-toaster.spec from 1.3.21. I installed > openssl-1.0.2o from source on CentOS 5 and linked: > > /usr/include/openssl -> /usr/local/ssl/include/openssl/ > > Then I rebuilt the RPM: > > rpmbuild -bb --target i686 --with cnt50 > /usr/src/redhat/SPECS/qmail-toaster.spec > > This generated the RPM. I extracted the files: > > rpm2cpio qmail-toaster-1.03-1.3.22.i686.rpm | cpio -idmv > > I backed up my existing qmail-smtpd and qmail-remote.orig, and copied > the new binaries over (from /usr/src/redhat/RPMS/i686/var/qmail/bin > where cpio extracted them to) > > And then tested with checktls.com and everything shows TLS 1.2 now. *whew* > > This buys us a little time to complete a migration. Hope this helps someone > else! > > > Brian > > > On 6/27/18 09:09, Eric Broch wrote: > > Have a look at this thread: > > https://www.mail-archive.com/qmailtoaster-list@qmailtoaster.com/msg41029.html > > IMHO, there were to many packages that were dependent on openssl-9.8 on the > CentOS 5 box to make this practical. > > > > > - > To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com > For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com > > > -- > 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] Upgrading openssl in an old Qmailtoaster install
I would be interested in this solution as well. How did you upgrade openssl? Did you follow this tutorial https://miteshshah.github.io/linux/centos/how-to-enable-openssl-1-0-2-a-tlsv1-1-and-tlsv1-2-on-centos-5-and-rhel5/ or something else? Best, Peter On Wed, Jun 27, 2018 at 8:44 AM, Brian Ghidinelli wrote: > > I'm running into the same SMTP TLS connection errors as reported by Sean > Murphy in this email here: > > https://www.mail-archive.com/qmailtoaster-list@qmailtoaster.com/msg41115.html > > Same scenario: old, reliable CentOS 5 box. We need a few more months to > transition off this box and we're getting an increasing number of TLS > failures that are hard to fix with notls FQDNs. > > I have upgraded our openssl so I'm wondering if it's possible, using the > source rpm for my very old install, to recompile and provide a new SSL > library path? > > I am not very experienced with rpmbuild and have toyed with the > qmail-toaster.spec file but I believe I ran into a problem that openssl > 1.0.2l does not pass the checks for openssl >= 0.9.8. Any suggestions for a > short term fix? > > I believe I would need to recompile and then replace just qmail-smtpd and > qmail-remote, yes? > > > Brian > > - > To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com > For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com > - To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
Re: [qmailtoaster] SOLVED - Re: [qmailtoaster] QMT - Problem with MessageID on Vacation Message Responses
Eric - any plans to create an rpm for the new autorespond 2.06 version?
I've also opened a new issue with it at GitHub: messages containing
scandinavian letters are quoted wrong in the replies generated by the
autoresponder.
Best,
Peter
On Thu, Jan 18, 2018 at 6:14 AM, Jeff Koch wrote:
> There is a new version of autorespond on GITHUB - version 2.06 - patched
> April 2016 that fixes the MessageID.
>
> The original code in existence since 2001 creates the MessageID as follows:
>
> fprintf(fdm,"Date: %u %s %u %02u:%02u:%02u -\nMessage-ID:
> <%lu.%u.blah>\n"
> ,dt->tm_mday,montab[dt->tm_mon],dt->tm_year+1900,dt->tm_hour,dt->tm_min,dt->tm_sec,msgwhen,getpid()
> );
>
> with the word 'blah'.
>
> The correction is:
>
>
> fprintf(fdm,"Date: %u %s %u %02u:%02u:%02u -\nMessage-ID:
> <%lu.%u.autorespond@%s>\n
> ,dt->tm_mday,montab[dt->tm_mon],dt->tm_year+1900,dt->tm_hour,dt->tm_min,dt->tm_sec,msgwhen,getpid(),getenv("LOCAL")
>
> using LOCAL which is the domain name followed by the user name.
>
> You can just download the code, unzip it, run 'make' followed by 'make
> install' and your autoresponder is fixed.
>
> Jeff
>
>
> On 1/17/2018 2:41 PM, Jeff Koch wrote:
>
>
> I have been testing the vacation message function on the moduser page in
> qmailadmin. The autoresponses generated by the vacation message option end
> up in my spam folders because the Message ID generated by the autoresponder
> do not include a domain name and, as a result, violate RFC 2822.
>
> These two issues give the message 4.3 points for spamassassin and the
> message ends up as junk.
>
> Here's the MessageID generated by the vacation responder:
>
> Message-ID: <1516217515.27282.blah>
>
> I don't have a clue where 'blah' comes from. All we need is a domain name to
> put in there - doesn't even need to be valid.
>
> Does anyone know how to change 'blah' to something else?
>
> Regards, Jeff
>
>
-
To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
Re: [qmailtoaster] Re: CNAME_lookup_failed_temporarily._(#4.4.3)/
Thank you Eric,
installing this version seems to fix the problem I have been having.
Sorry for not reporting earlier: Gmail decided to put this email
thread to my spam folder and I did not notice your replies until I
started wondering if I am on the list anymore :(
Only issue I have noticed with the upgrade was that my qmail-queue
symlink was pointing to qmail-dk and not to qmail-queue.orig like
before the upgrade.
Best,
Peter
On Thu, Apr 26, 2018 at 5:53 PM, Eric Broch wrote:
> Hi Peter,
>
> This is not a Big DNS failure. It's a problem with CNAME lookup, and
> qmailtoaster is patched with the Big DNS patch.
>
> Dan Bernstein recommended the removal of the CNAME lookup portion of the
> code (patch below), which I did, a function in dns object module which is
> called by qmail-remote. There are new binaries with this patch at the
> following locations for respective CentOS version:
>
> CentOS 7:
> ftp://ftp.qmailtoaster.org/pub/repo/qmt/CentOS/7/development/x86_64/qmail-1.03-2.2.qt.el7.x86_64.rpm
>
> CentOS 6:
> ftp://ftp.qmailtoaster.org/pub/repo/qmt/CentOS/6/development/x86_64/qmail-1.03-1.1.qt.el6.x86_64.rpm
>
> CentOS 5:
> ftp://ftp.qmailtoaster.org/pub/repo/qmt/CentOS/5/development/i386/qmail-toaster-1.03-1.3.23.i386.rpm
>
> ftp://ftp.qmailtoaster.org/pub/repo/qmt/CentOS/5/development/x86_64/qmail-toaster-1.03-1.3.23.x86_64.rpm
>
> Eric
>
> CNAME lookup remove patch:
>
>
>
> --- qmailqmt/dns.c 2018-01-21 09:03:56.201694493 -0700
> +++ qmailqmt-new/dns.c 2018-01-21 09:06:40.696619489 -0700
> @@ -249,32 +249,7 @@
> int dns_cname(sa)
> stralloc *sa;
> {
> - int r;
> - int loop;
> - for (loop = 0;loop < 10;++loop)
> - {
> - if (!sa->len) return loop;
> - if (sa->s[sa->len - 1] == ']') return loop;
> - if (sa->s[sa->len - 1] == '.') { --sa->len; continue; }
> - switch(resolve(sa,T_CNAME))
> -{
> - case DNS_MEM: return DNS_MEM;
> - case DNS_SOFT: return DNS_SOFT;
> - case DNS_HARD: return loop;
> - default:
> - while ((r = findname(T_CNAME)) != 2)
> - {
> -if (r == DNS_SOFT) return DNS_SOFT;
> -if (r == 1)
> - {
> - if (!stralloc_copys(sa,name)) return DNS_MEM;
> - break;
> - }
> - }
> - if (r == 2) return loop;
> -}
> - }
> - return DNS_HARD; /* alias loop */
> + return 0;
> }
>
> #define FMT_IAA 40
>
>
>
>
>
> On 4/24/2018 12:48 AM, Peter Peltonen wrote:
>
> No ideas? From the archives I can see others have been struggling with
> the same issue...
>
> Peter
>
> On Wed, Apr 18, 2018 at 6:52 PM, Peter Peltonen
> wrote:
>
> I am getting this error when sending to the tyks.fi domain:
>
> 2018-04-18 18:15:18.787618500 starting delivery 32313: msg 2232943 to
> remote ***@tyks.fi
> 2018-04-18 18:16:01.777845500 delivery 32313: deferral:
> CNAME_lookup_failed_temporarily._(#4.4.3)/
>
> I've been searching for this error and found the following:
>
> 1) known error for qmail + bind combination
> 2) fix is to either patch with qmailtoaster-big-dns.patch or use other
> recursor than bind
>
> Before I can proceed with 2) I have some questions though:
>
> * Why is the patch not installed by default in the toaster? I can see
> Shubert had it:
>
> https://github.com/QMailToaster/qmail/blob/master/qmailtoaster-big-dns.patch
>
> * As I understood it, the problem is a response too big that BIND
> cannot handle. I am a bit confused here, as the tyks.fi lookup does
> not return a big response and it does not have any CNAME records in
> it. Could this error be caused by something else?
>
> * If I would to change resolveer and not to patch, can I both run a
> BIND server and have a different resolver at the same time on the same
> server?
>
> Best,
> Peter
>
> -
> To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
> For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
>
>
> --
> 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] Re: CNAME_lookup_failed_temporarily._(#4.4.3)/
No ideas? From the archives I can see others have been struggling with the same issue... Peter On Wed, Apr 18, 2018 at 6:52 PM, Peter Peltonen wrote: > I am getting this error when sending to the tyks.fi domain: > > 2018-04-18 18:15:18.787618500 starting delivery 32313: msg 2232943 to > remote ***@tyks.fi > 2018-04-18 18:16:01.777845500 delivery 32313: deferral: > CNAME_lookup_failed_temporarily._(#4.4.3)/ > > I've been searching for this error and found the following: > > 1) known error for qmail + bind combination > 2) fix is to either patch with qmailtoaster-big-dns.patch or use other > recursor than bind > > Before I can proceed with 2) I have some questions though: > > * Why is the patch not installed by default in the toaster? I can see > Shubert had it: > > https://github.com/QMailToaster/qmail/blob/master/qmailtoaster-big-dns.patch > > * As I understood it, the problem is a response too big that BIND > cannot handle. I am a bit confused here, as the tyks.fi lookup does > not return a big response and it does not have any CNAME records in > it. Could this error be caused by something else? > > * If I would to change resolveer and not to patch, can I both run a > BIND server and have a different resolver at the same time on the same > server? > > Best, > Peter - To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
[qmailtoaster] CNAME_lookup_failed_temporarily._(#4.4.3)/
I am getting this error when sending to the tyks.fi domain: 2018-04-18 18:15:18.787618500 starting delivery 32313: msg 2232943 to remote ***@tyks.fi 2018-04-18 18:16:01.777845500 delivery 32313: deferral: CNAME_lookup_failed_temporarily._(#4.4.3)/ I've been searching for this error and found the following: 1) known error for qmail + bind combination 2) fix is to either patch with qmailtoaster-big-dns.patch or use other recursor than bind Before I can proceed with 2) I have some questions though: * Why is the patch not installed by default in the toaster? I can see Shubert had it: https://github.com/QMailToaster/qmail/blob/master/qmailtoaster-big-dns.patch * As I understood it, the problem is a response too big that BIND cannot handle. I am a bit confused here, as the tyks.fi lookup does not return a big response and it does not have any CNAME records in it. Could this error be caused by something else? * If I would to change resolveer and not to patch, can I both run a BIND server and have a different resolver at the same time on the same server? Best, Peter - To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
Re: [qmailtoaster] CNAME lookup failed temporarily -- workarounds?
Hi, I was hit by this error on a server running qmail-toaster-1.03-1.3.22 This patch is not included by default in the toaster qmail package? Strange thing is that the error came from a host that has proper MX records (MX pointing to a A record, not CNAME), so I am wondering what exactly is triggering this error...? Regards, Peter On Mon, Feb 19, 2018 at 9:06 PM, Angus McIntyre wrote: > Eric, very many thanks for this. > > I've done the upgrade using the RPMs that you provided and, touch wood, > everything seems to be going smoothly. > > The only problem that I encountered (so far) was with authenticating on > submission. This turned out to be a softlimit issue: softlimit had reverted > to its original, lower value in a couple of the supervise scripts, and this > was stopping a shared library loading. Once I put the softlimit back to what > it should be, everything returned to normal. > > Once again, many thanks for your help with this, and with qmailtoaster in > general. > > Angus > > > > > Eric Broch wrote: >> >> Angus, >> >> qmail-toaster ( and pop3d) x86_64 RPMS (CNAME lookup removed) in this >> folder: >> ftp://ftp.qmailtoaster.org/pub/repo/qmt/CentOS/5/development/x86_64/ >> >> >> On 2/15/2018 7:16 AM, Angus McIntyre wrote: >>> >>> I'm running a fairly ancient qmail (netqmail-1.0.5, according to the >>> manual) on CentOS 5, and I'm starting to get bitten with increasing >>> frequency by the 'CNAME lookup failed temporarily' bug. >>> >>> I urgently need to build a new host with an up-to-date OS and the >>> latest version of qmail and move everything over, but I don't have the >>> time to do that right now. I'm very hesitant to screw with this >>> particular configuration (which is a mess) in case I bring everything >>> crashing down around my ears. >>> >>> So the question is, is there any easy (temporary) fix for this issue? >>> >>> Thanks, >>> >>> Angus >>> >>> - >>> To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com >>> For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com >>> >> > > - > To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com > For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com > - To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
[qmailtoaster] where are forwards created in qmailadmin stored?
Hi, Aliases are stored in MySQL and can be managed with the valias command from cmd line. But what about forwards created for an existing account via qmailadmin? I thought that would create a .qmail file but just tested it and I found I was wrong. So where is the forward data stored? What I am after is creating a script that would show both valiases and forwards for an email address. It's annoying that I need to check the forwards using qmailadmin... Best, Peter - To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
Re: [qmailtoaster] ERROR: accept() failed
First thing that comes to my mind is to check qmail directory ownerships and permissions? On Fri, Jan 26, 2018 at 12:24 PM, Michele Federici wrote: > Hi, > > I have a qmail server that today returns in the smtp log "mail server > temporarily rejected message (# 4.3.0)". > > Everything works fine until the start of these errors on simscan > > Fri Jan 26 10:00:52 2018 -> > /var/qmail/simscan/1516957251.438820.10197/doc05577520180126111044.pdf: OK > Fri Jan 26 10:01:16 2018 -> > /var/qmail/simscan/1516957274.430368.10271/msg.1516957274.430368.10271: OK > Fri Jan 26 10:01:16 2018 -> > /var/qmail/simscan/1516957274.430368.10271/addr.1516957274.430368.10271: OK > Fri Jan 26 10:01:16 2018 -> > /var/qmail/simscan/1516957274.430368.10271/textfile0: OK > Fri Jan 26 10:01:16 2018 -> > /var/qmail/simscan/1516957274.430368.10271/textfile1: OK > Fri Jan 26 10:01:16 2018 -> > /var/qmail/simscan/1516957274.430368.10271/textfile2: OK > Fri Jan 26 10:01:20 2018 -> > /var/qmail/simscan/1516957279.523709.10292/addr.1516957279.523709.10292: OK > Fri Jan 26 10:01:20 2018 -> > /var/qmail/simscan/1516957279.523709.10292/textfile2: OK > Fri Jan 26 10:01:20 2018 -> > /var/qmail/simscan/1516957279.523709.10292/textfile3: Can't open file or > directory ERROR > Fri Jan 26 10:01:20 2018 -> > /var/qmail/simscan/1516957279.523709.10292/image001.png: OK > Fri Jan 26 10:01:20 2018 -> > /var/qmail/simscan/1516957279.523709.10292/doc05577520180126111044.pdf: OK > Fri Jan 26 10:01:23 2018 -> > /var/qmail/simscan/1516957282.930250.10316/msg.1516957282.930250.10316: > Can't open file or directory ERROR > Fri Jan 26 10:01:23 2018 -> > /var/qmail/simscan/1516957282.930250.10316/addr.1516957282.930250.10316: > Can't create new file ERROR > Fri Jan 26 10:01:23 2018 -> > /var/qmail/simscan/1516957282.930250.10316/textfile0: Can't open file or > directory ERROR > [..] > Fri Jan 26 10:09:15 2018 -> ERROR: accept() failed: > Fri Jan 26 10:09:15 2018 -> ERROR: accept() failed: > Fri Jan 26 10:09:15 2018 -> ERROR: accept() failed: > Fri Jan 26 10:09:15 2018 -> ERROR: accept() failed: > Fri Jan 26 10:09:15 2018 -> ERROR: accept() failed: > Fri Jan 26 10:09:15 2018 -> ERROR: accept() failed: > Fri Jan 26 10:09:15 2018 -> ERROR: accept() failed: > > So I restart > > # systemctl restart clamav-daemon.service > # systemctl restart clamav-daemon.socket > > and then everything works fine until simscan restarts to return "Unable to > open file or directory ERROR" > > I'm running qmailtoaster on Centos 7 with ClamAV 0.99.2. > > Any suggestions? > > -- > Michele Federici > > > - > To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com > For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com > - To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
Re: [qmailtoaster] connection issues again.
Never worked with fail2ban before. Care to share your config for qmailtoaster? On Fri, Dec 29, 2017 at 8:56 PM, Eric Broch wrote: > Hi Tony, > > I see this more than I'd like. Sometimes I hear my server cranking away > and upon investigation one day (tail -f /var/log/qmail/smtp/current) > found connects and immediate disconnects being perpetrated from the same > IP address scrolling across the terminal for as long as I cared to > watch, 45 minutes or so, and then continued to hear my server cranking > away until I left the room. I've tried banning them in my external > firewall but I think the better approach is to use either IP tables or > fail2ban DOS. I don't want to wait for authentication (the stock > fail2ban setup for qmailtoaster) before dropping the IP but want anyone > who connects even without trying to authenticate to be banned after so > many attempts within a certain time frame. Fail2ban and IP Tables have > these options. > > Eric > > > > On 12/29/2017 6:40 AM, Tony White wrote: >> >> Hi folks, >> Is anyone else seeing a single ip connecting hundreds even thousands >> of times but never sending any mail? I end up blocking these using >> iptables >> but I do not understand why it is happening. >> >> TIA >> >> Example >> 2017-12-30 00:31:31.653614500 tcpserver: status: 2/100 >> 2017-12-30 00:31:31.653753500 tcpserver: pid 31242 from 114.229.162.93 >> 2017-12-30 00:31:31.653820500 tcpserver: ok 31242 >> indialau.bigpuddle.net:192.168.1.138:25 :114.229.162.93::62277 >> 2017-12-30 00:31:32.581728500 tcpserver: end 31242 status 0 >> 2017-12-30 00:31:32.581729500 tcpserver: status: 1/100 >> 2017-12-30 00:31:32.872455500 tcpserver: status: 2/100 >> 2017-12-30 00:31:32.872564500 tcpserver: pid 31246 from 114.229.162.93 >> 2017-12-30 00:31:32.872611500 tcpserver: ok 31246 >> indialau.bigpuddle.net:192.168.1.138:25 :114.229.162.93::62369 >> 2017-12-30 00:31:33.862860500 tcpserver: end 31246 status 0 >> 2017-12-30 00:31:33.862861500 tcpserver: status: 1/100 >> 2017-12-30 00:31:34.375021500 tcpserver: status: 2/100 >> 2017-12-30 00:31:34.375022500 tcpserver: pid 31248 from 114.229.162.93 >> 2017-12-30 00:31:34.375056500 tcpserver: ok 31248 >> indialau.bigpuddle.net:192.168.1.138:25 :114.229.162.93::62461 >> 2017-12-30 00:31:35.326643500 tcpserver: end 31248 status 0 >> 2017-12-30 00:31:35.326645500 tcpserver: status: 1/100 >> 2017-12-30 00:31:35.717309500 tcpserver: status: 2/100 >> 2017-12-30 00:31:35.717443500 tcpserver: pid 31252 from 114.229.162.93 >> 2017-12-30 00:31:35.717508500 tcpserver: ok 31252 >> indialau.bigpuddle.net:192.168.1.138:25 :114.229.162.93::62563 >> 2017-12-30 00:31:36.657366500 tcpserver: end 31252 status 0 >> 2017-12-30 00:31:36.657368500 tcpserver: status: 1/100 >> 2017-12-30 00:31:37.007733500 tcpserver: status: 2/100 >> 2017-12-30 00:31:37.007904500 tcpserver: pid 31254 from 114.229.162.93 >> 2017-12-30 00:31:37.007983500 tcpserver: ok 31254 >> indialau.bigpuddle.net:192.168.1.138:25 :114.229.162.93::62637 >> 2017-12-30 00:31:37.914884500 tcpserver: end 31254 status 0 >> 2017-12-30 00:31:37.914885500 tcpserver: status: 1/100 >> 2017-12-30 00:31:38.215151500 tcpserver: status: 2/100 >> 2017-12-30 00:31:38.215252500 tcpserver: pid 31259 from 114.229.162.93 >> 2017-12-30 00:31:38.215296500 tcpserver: ok 31259 >> indialau.bigpuddle.net:192.168.1.138:25 :114.229.162.93::62738 >> 2017-12-30 00:31:39.110484500 tcpserver: end 31259 status 0 >> 2017-12-30 00:31:39.110485500 tcpserver: status: 1/100 >> 2017-12-30 00:31:39.433288500 tcpserver: status: 2/100 >> 2017-12-30 00:31:39.433302500 tcpserver: pid 31261 from 114.229.162.93 >> 2017-12-30 00:31:39.433357500 tcpserver: ok 31261 >> indialau.bigpuddle.net:192.168.1.138:25 :114.229.162.93::62831 >> 2017-12-30 00:31:40.316270500 tcpserver: end 31261 status 0 >> 2017-12-30 00:31:40.316271500 tcpserver: status: 1/100 >> 2017-12-30 00:31:40.615598500 tcpserver: status: 2/100 >> 2017-12-30 00:31:40.615698500 tcpserver: pid 31271 from 114.229.162.93 >> 2017-12-30 00:31:40.615766500 tcpserver: ok 31271 >> indialau.bigpuddle.net:192.168.1.138:25 :114.229.162.93::62924 >> 2017-12-30 00:31:41.496972500 tcpserver: end 31271 status 0 >> 2017-12-30 00:31:41.496973500 tcpserver: status: 1/100 >> 2017-12-30 00:31:41.873223500 tcpserver: status: 2/100 >> 2017-12-30 00:31:41.873326500 tcpserver: pid 31273 from 114.229.162.93 >> 2017-12-30 00:31:41.873371500 tcpserver: ok 31273 >> indialau.bigpuddle.net:192.168.1.138:25 :114.229.162.93::63007 >> 2017-12-30 00:31:42.828193500 tcpserver: end 31273 status 0 >> 2017-12-30 00:31:42.828194500 tcpserver: status: 1/100 >> 2017-12-30 00:31:43.135644500 tcpserver: status: 2/100 >> 2017-12-30 00:31:43.135749500 tcpserver: pid 31277 from 114.229.162.93 >> 2017-12-30 00:31:43.135794500 tcpserver: ok 31277 >> indialau.bigpuddle.net:192.168.1.138:25 :114.229.162.93::63093 >> 2017-12-30 00:31:44.067442500 tcpserver: end 31277 status 0 >> 2017-12-30 00:31:44.067443500 tcpserver: status: 1/100 >> 2017-12-30 00:31:44.3
Re: [qmailtoaster] logging subjects of sent / received email
Two more questions: 1) is the toaster compiled with QUEUE_EXTRA set? 2) Regarding Remo's comment: can the .qmail files still be used with the stock toaster? On Tue, Nov 14, 2017 at 4:35 AM, Remo Mattei wrote: > I use the files since I have issues with vpopaliases!!! > > Just my 2 cents > > On 11/13/17 6:33 PM, Eric Broch wrote: >> Hi Peter, >> >> The way that vpopmail is compiled the alias stuff is in the maria/mysql >> db, but I THINK you can put the same entries that go into the alias >> files into one of the fields of the mysql/maria vpopmail alias db. >> >> Eric >> >> >> On 11/13/2017 6:08 AM, Peter Peltonen wrote: >>> Hi, >>> >>> I would need to gather a log of dates and subjects of sent + reiceived >>> emails for one domain. >>> >>> Can that be done with our toaster? >>> >>> Googling I found this advice for stock Qmail: >>> >>> " >>> Just rebuild qmail with QUEUE_EXTRA set[1], install DJB's >>> mess822 package[2], and put the following line in ~alias/.qmail-log: >>> >>> |/usr/local/bin/822field subject || echo "no subject" >>> >>> >>> Footnotes: >>> [1] http://lifewithqmail.org/lwq.html#queue_extra >>> >>> [2] http://lifewithqmail.org/lwq.html#mess822 >>> " >>> >>> I am unsure if this relates to our version of Qmail? >>> >>> Best, >>> Peter >>> >>> - >>> To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com >>> For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com >>> >> > > > - > To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com > For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com > - To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
[qmailtoaster] logging subjects of sent / received email
Hi, I would need to gather a log of dates and subjects of sent + reiceived emails for one domain. Can that be done with our toaster? Googling I found this advice for stock Qmail: " Just rebuild qmail with QUEUE_EXTRA set[1], install DJB's mess822 package[2], and put the following line in ~alias/.qmail-log: |/usr/local/bin/822field subject || echo "no subject" Footnotes: [1] http://lifewithqmail.org/lwq.html#queue_extra [2] http://lifewithqmail.org/lwq.html#mess822 " I am unsure if this relates to our version of Qmail? Best, Peter - To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
Re: [qmailtoaster] {Disarmed} Re: [qmailtoaster] I am seeing this in my send..
I tried z-push on CentOS6. My toaster was running CentOS5 on another server. But that was long ago, so I was wondering how it behaves nowadays. I was actually using it with SOGo to sync calendar events as well, don't remember if it was email or calendar related. On Wed, Jul 19, 2017 at 10:34 PM, Remo Mattei wrote: > Centos 7 > > TY > > On Jul 19, 2017, at 12:25 PM, Eric Broch wrote: > > Hi Peter, > > What OS were you using? > > > On 7/19/2017 12:49 PM, Peter Peltonen wrote: > > How are you finding z-push resource wise? > > When I tried it couple of years ago I found it eating memory like a > monster... > > Regards, > Peter > > On Wed, Jul 19, 2017 at 9:05 PM, Eric Broch > wrote: > > Z-push: > > http://www.qmailtoaster.org/msas.html > > > On 7/19/2017 11:53 AM, Remo Mattei wrote: > > I have sieve working and moves msg .. roundcube has the great plugin which > creates the rules for your in a human way.. > > I will have to write up what I have done so we can post it. > > Remo > > PS. Did anyone implement z-push and what’s the setting going to be in the > iPhone to get mail? Just wonder. > > TY > > On Jul 19, 2017, at 10:04 AM, Eric Broch wrote: > > For sending messages this is fine. > > What about your original questions about Sieve, is that working? > > > On 7/19/2017 10:51 AM, Remo Mattei wrote: > > Hello all > > I see this in my send message any suggestions on where to look for? > > User_and_password_not_set,_continuing_without_authentication./ virgilio.it>_212.48.24.40_accepted_message./Remote_host_said:_250_ > Xrtddxo6Gl3EvXrtedKDg4_mail_accepted_for_delivery/ > > User_and_password_not_set,_continuing_without_authentication./ virgilio.it>_212.48.24.40_accepted_message./Remote_host_said:_250_ > Xrtddxo6Gl3EvXrtedKDg4_mail_accepted_for_delivery/ > > User_and_password_not_set,_continuing_without_authentication./ virgilio.it>_212.48.24.40_accepted_message./Remote_host_said:_250_ > Xrtddxo6Gl3EvXrtedKDg4_mail_accepted_for_delivery/ > > User_and_password_not_set,_continuing_without_authentication./ virgilio.it>_212.48.24.40_accepted_message./Remote_host_said:_250_ > Xrtddxo6Gl3EvXrtedKDg4_mail_accepted_for_delivery/ > > success: > User_and_password_not_set,_continuing_without_authentication./ virgilio.it>_212.48.24.40_accepted_message./Remote_host_said:_250_ > Xrtddxo6Gl3EvXrtedKDg4_mail_accepted_for_delivery/ > success: > User_and_password_not_set,_continuing_without_authentication./ virgilio.it>_212.48.24.40_accepted_message./Remote_host_said:_250_ > Xrtddxo6Gl3EvXrtedKDg4_mail_accepted_for_delivery/ > > 3: success: > User_and_password_not_set,_continuing_without_authentication./ virgilio.it>_212.48.24.40_accepted_message./Remote_host_said:_250_ > Xrtddxo6Gl3EvXrtedKDg4_mail_accepted_for_delivery/ > @4000596f89a105d5cc1c status: local 0/10 remote 0/60 > > @4000596f899f08ab7d74 status: local 0/10 remote 1/60 > @4000596f89a105d5c064 delivery 3: success: > User_and_password_not_set,_continuing_without_authentication./ virgilio.it>_212.48.24.40_accepted_message./Remote_host_said:_250_ > Xrtddxo6Gl3EvXrtedKDg4_mail_accepted_for_delivery/ > @4000596f89a105d5cc1c status: local 0/10 remote 0/60 > @4000596f89a105d5d004 end msg 10356912 > > @4000596f899f08ab7d74 status: local 0/10 remote 1/60 > @4000596f89a105d5c064 delivery 3: success: > User_and_password_not_set,_continuing_without_authentication./ >_212.48.24.40_accepted_message./Remote_host_said:_250_ > Xrtddxo6Gl3EvXrtedKDg4_mail_accepted_for_delivery/ > @4000596f89a105d5cc1c status: local 0/10 remote 0/60 > @4000596f89a105d5d004 end msg 10356912 > > > -- > Eric Broch > White Horse Technical Consulting (WHTC) > > > > -- > 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 > > > > -- > 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 > > > > [image: Web Bug from > https://master.mailbutler.io/tracking/FE31CA65-7973-4213-B0D5-389D766CC2DF] >
Re: Re: [qmailtoaster] I am seeing this in my send..
How are you finding z-push resource wise? When I tried it couple of years ago I found it eating memory like a monster... Regards, Peter On Wed, Jul 19, 2017 at 9:05 PM, Eric Broch wrote: > Z-push: > > http://www.qmailtoaster.org/msas.html > > > On 7/19/2017 11:53 AM, Remo Mattei wrote: > > I have sieve working and moves msg .. roundcube has the great plugin which > creates the rules for your in a human way.. > > I will have to write up what I have done so we can post it. > > Remo > > PS. Did anyone implement z-push and what’s the setting going to be in the > iPhone to get mail? Just wonder. > > TY > > On Jul 19, 2017, at 10:04 AM, Eric Broch wrote: > > For sending messages this is fine. > > What about your original questions about Sieve, is that working? > > > On 7/19/2017 10:51 AM, Remo Mattei wrote: > > Hello all > > I see this in my send message any suggestions on where to look for? > > User_and_password_not_set,_continuing_without_authentication./_212.48.24.40_accepted_message./Remote_host_said:_250_Xrtddxo6Gl3EvXrtedKDg4_mail_accepted_for_delivery/ > > User_and_password_not_set,_continuing_without_authentication./_212.48.24.40_accepted_message./Remote_host_said:_250_Xrtddxo6Gl3EvXrtedKDg4_mail_accepted_for_delivery/ > > User_and_password_not_set,_continuing_without_authentication./_212.48.24.40_accepted_message./Remote_host_said:_250_Xrtddxo6Gl3EvXrtedKDg4_mail_accepted_for_delivery/ > > User_and_password_not_set,_continuing_without_authentication./_212.48.24.40_accepted_message./Remote_host_said:_250_Xrtddxo6Gl3EvXrtedKDg4_mail_accepted_for_delivery/ > > success: > User_and_password_not_set,_continuing_without_authentication./_212.48.24.40_accepted_message./Remote_host_said:_250_Xrtddxo6Gl3EvXrtedKDg4_mail_accepted_for_delivery/ > success: > User_and_password_not_set,_continuing_without_authentication./_212.48.24.40_accepted_message./Remote_host_said:_250_Xrtddxo6Gl3EvXrtedKDg4_mail_accepted_for_delivery/ > > 3: success: > User_and_password_not_set,_continuing_without_authentication./_212.48.24.40_accepted_message./Remote_host_said:_250_Xrtddxo6Gl3EvXrtedKDg4_mail_accepted_for_delivery/ > @4000596f89a105d5cc1c status: local 0/10 remote 0/60 > > @4000596f899f08ab7d74 status: local 0/10 remote 1/60 > @4000596f89a105d5c064 delivery 3: success: > User_and_password_not_set,_continuing_without_authentication./_212.48.24.40_accepted_message./Remote_host_said:_250_Xrtddxo6Gl3EvXrtedKDg4_mail_accepted_for_delivery/ > @4000596f89a105d5cc1c status: local 0/10 remote 0/60 > @4000596f89a105d5d004 end msg 10356912 > > @4000596f899f08ab7d74 status: local 0/10 remote 1/60 > @4000596f89a105d5c064 delivery 3: success: > User_and_password_not_set,_continuing_without_authentication./_212.48.24.40_accepted_message./Remote_host_said:_250_Xrtddxo6Gl3EvXrtedKDg4_mail_accepted_for_delivery/ > @4000596f89a105d5cc1c status: local 0/10 remote 0/60 > @4000596f89a105d5d004 end msg 10356912 > > > -- > Eric Broch > White Horse Technical Consulting (WHTC) > > > > -- > 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] setting account forward from command line
Thanks Eric, this was just what I needed! Best, Peter On Thu, May 18, 2017 at 7:45 PM, Eric Broch wrote: > This is basically what the forwards option does in qmailadmin (below), > create a .qmail file. > > This could easily be scripted. If you already have a .qmail file in place > (as I do) this will overwrite it. > > # echo "&u...@destination.com" > > /home/vpopmail/domains/origin.com/user/.qmail > # chmod 0600 /home/vpopmail/domains/origin.com/user/.qmail > # chown vpopmail:vchkpw /home/vpopmail/domains/origin.com/user/.qmail > > > > On 5/18/2017 10:10 AM, Peter Peltonen wrote: >> >> A common task I encounter when managing toaster accounts is setting up >> / modifying or removing forwards for existing email accounts. >> >> Can this be done from command line? I find it very cumbersome to have >> to do it via qmailadmin. >> >> And I mean here real email accounts with inboxes, not aliases that I >> can manage with valias. >> >> Regards, >> Peter >> >> - >> To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com >> For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com >> > > -- > 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 > - To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
[qmailtoaster] setting account forward from command line
A common task I encounter when managing toaster accounts is setting up / modifying or removing forwards for existing email accounts. Can this be done from command line? I find it very cumbersome to have to do it via qmailadmin. And I mean here real email accounts with inboxes, not aliases that I can manage with valias. Regards, Peter - To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
Re: [qmailtoaster] QMT Instructions (bare bones)
Thats a good starting point, thanks! Best, Peter On Mon, Dec 14, 2015 at 8:20 PM, Eric wrote: > https://www.whitehorsetc.com/files/qmail/qmail.php > > The CentOS 5 link resolves to > http://wiki.qmailtoaster.com/index.php/Configuration. I don't think anyone > is creating CentOS 5 QMT hosts anymore so this goes to the configuration > page. > The CentOS 6 link resolves to > https://github.com/QMailToaster/qmailtoaster-util > The CentOS 7 link resolves to an installation and update README > ftp://ftp.whitehorsetc.com/pub/repo/qmt/CentOS/7/current/x86_64/1.qmail-centos7-install.README > > If anyone wants to submit any documentation let me know. > > Eric > > > - > To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com > For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com > - To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
Re: [qmailtoaster] QMT -- state of the union?
Hi, At least I do not have access, how about Dan? If no easy access to the Wiki is found, then a page on your site would be great. We can then sync the info rom there to the official site / wiki / whatever if / when Shubes gets back. It would be really handy if the latest info could be found from one place and one would not need to search the archives. Best, Peter On Sat, Dec 12, 2015 at 5:09 PM, Eric wrote: > That's a great idea. Does anyone have access to the wiki? If not I could > create a page on my site. > > > On 12/12/2015 6:13 AM, Peter Peltonen wrote: >> >> Hi, >> >> Thanks for Eric for all his work. >> >> How about a temporary website that puts all these bits of information >> together? >> >> Best, >> Peter >> >> On Sat, Dec 12, 2015 at 12:58 AM, Angus McIntyre wrote: >>> >>> Thank you, Eric. >>> >>> Ansible is pretty nice: >>> >>> http://www.ansible.com/get-started >>> >>> Seems to be a good balance between simplicity and power. >>> >>> I will probably end up using it to manage my QMT host(s) if I can, so I >>> may >>> document my experience here in due course. >>> >>> Angus >>> >>> >>> On Dec 11, 2015, at 10:55 AM, Eric wrote: >>> >>> Hi Angus, >>> >>> I've never tried Ansible, I'll have a look at it. >>> >>> CentOS 6 is still installed via Github. Look through the list and you can >>> find the procedure to install it. >>> >>> For CentOS 6 updates use the WHTC repo: # rpm -Uvh >>> >>> ftp://ftp.whitehorsetc.com/pub/repo/qmt/CentOS/6/current/noarch/whtc-qmt-1-1.qt.el6.noarch.rpm >>> >>> As for CentOS 7 there are two methods: >>> >>> >>> 1) Install CentOS 7 minimal install (I install both options under >>> minimal install. One is development tools and I can't remember the >>> other). >>> 2) curl >>> ftp://ftp.whitehorsetc.com/pub/qmail/CentOS7/qmt/scripts/qt_prep.sh >>>> >>>> qt_prep.sh >>> >>> 3) sh qt_prep.sh (Automatic reboot) >>> 4) sh qt_install.sh >>> >>> >>> Or >>> >>> >>> 1) Install CentOS 7 minimal install (I install both options under >>> minimal install. One is development tools and I can't remember the >>> other). >>> 2) curl >>> ftp://ftp.whitehorsetc.com/pub/qmail/CentOS7/qmt/scripts/qt_prep.sh >>>> >>>> qt_prep.sh >>> >>> 3) sh qt_prep.sh (Automatic reboot) >>> 4) curl >>> >>> ftp://ftp.whitehorsetc.com/pub/qmail/CentOS7/qmt/scripts/qt_grp_install.sh >>>> >>>> qt_grp_install.sh >>> >>> 5) sh qt_grp_install.sh >>> >>> >>> Eric Shubert is still the lead for QMT. I will continue to do packaging >>> in >>> his absence. Eventually, I'd like to move all the work that I've done to >>> GitHub. There are many people using and updating CentOS 7 and have been >>> since near the beginning of this year with success. I'd say that its >>> stable. >>> >>> EricB >>> >>> On 12/11/2015 8:15 AM, Angus McIntyre wrote: >>> >>> I’ve been running a QMT server on a CentOS 5 VPS for a while, and I’m now >>> looking to migrate it to a newer host. >>> >>> What’s the currently-preferred platform? CentOS 6, or CentOS 7? Are there >>> any other special requirements? >>> >>> Also, I know that in the absence of Eric Shubart, Eric Broch has been >>> doing >>> all the heavy lifting and maintaining the RPMs. Is there a document >>> anywhere >>> that describes the current step-by-step installation procedure using the >>> RPMs on whitehorsetc.com? Is it essentially unchanged from before, or are >>> there new things we need to know? >>> >>> Final question: has anyone tried using Ansible to manage a QMT install? >>> I’ve >>> just started to play around with Ansible, and it seems like a well >>> thought-out tool, so I’m wondering how easy it would be to use to >>> automate >>> the process of getting QMT up and running. >>> >>> Thanks, >>> >>> Angus >>> >>> >>> >>> >> - >> To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com >> For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com >> > > > - > To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com > For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com > - To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
Re: [qmailtoaster] QMT -- state of the union?
Hi, Thanks for Eric for all his work. How about a temporary website that puts all these bits of information together? Best, Peter On Sat, Dec 12, 2015 at 12:58 AM, Angus McIntyre wrote: > Thank you, Eric. > > Ansible is pretty nice: > > http://www.ansible.com/get-started > > Seems to be a good balance between simplicity and power. > > I will probably end up using it to manage my QMT host(s) if I can, so I may > document my experience here in due course. > > Angus > > > On Dec 11, 2015, at 10:55 AM, Eric wrote: > > Hi Angus, > > I've never tried Ansible, I'll have a look at it. > > CentOS 6 is still installed via Github. Look through the list and you can > find the procedure to install it. > > For CentOS 6 updates use the WHTC repo: # rpm -Uvh > ftp://ftp.whitehorsetc.com/pub/repo/qmt/CentOS/6/current/noarch/whtc-qmt-1-1.qt.el6.noarch.rpm > > As for CentOS 7 there are two methods: > > > 1) Install CentOS 7 minimal install (I install both options under > minimal install. One is development tools and I can't remember the other). > 2) curl ftp://ftp.whitehorsetc.com/pub/qmail/CentOS7/qmt/scripts/qt_prep.sh >>qt_prep.sh > 3) sh qt_prep.sh (Automatic reboot) > 4) sh qt_install.sh > > > Or > > > 1) Install CentOS 7 minimal install (I install both options under > minimal install. One is development tools and I can't remember the other). > 2) curl ftp://ftp.whitehorsetc.com/pub/qmail/CentOS7/qmt/scripts/qt_prep.sh >>qt_prep.sh > 3) sh qt_prep.sh (Automatic reboot) > 4) curl > ftp://ftp.whitehorsetc.com/pub/qmail/CentOS7/qmt/scripts/qt_grp_install.sh >>qt_grp_install.sh > 5) sh qt_grp_install.sh > > > Eric Shubert is still the lead for QMT. I will continue to do packaging in > his absence. Eventually, I'd like to move all the work that I've done to > GitHub. There are many people using and updating CentOS 7 and have been > since near the beginning of this year with success. I'd say that its stable. > > EricB > > On 12/11/2015 8:15 AM, Angus McIntyre wrote: > > I’ve been running a QMT server on a CentOS 5 VPS for a while, and I’m now > looking to migrate it to a newer host. > > What’s the currently-preferred platform? CentOS 6, or CentOS 7? Are there > any other special requirements? > > Also, I know that in the absence of Eric Shubart, Eric Broch has been doing > all the heavy lifting and maintaining the RPMs. Is there a document anywhere > that describes the current step-by-step installation procedure using the > RPMs on whitehorsetc.com? Is it essentially unchanged from before, or are > there new things we need to know? > > Final question: has anyone tried using Ansible to manage a QMT install? I’ve > just started to play around with Ansible, and it seems like a well > thought-out tool, so I’m wondering how easy it would be to use to automate > the process of getting QMT up and running. > > Thanks, > > Angus > > > > - To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
Re: [qmailtoaster] Integrated perdition pop3/imap4 proxy
Hi, On Tue, Jan 20, 2015 at 5:09 PM, Nikolay Mitev wrote: > Integrated perdition pop3/imap4 proxy and all received emails started to > duplicate ... Don't know about proxies, but message duplication has been caused by courier-imap, which can be fixed by switching to dovecot instead (search the archives, look at the wiki). Regards, Peter - To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
Re: [qmailtoaster] Concerns for Updates, Viability, Future of Qmailtoaster
Hi, My 2 cents on this below: On Fri, Jan 16, 2015 at 5:54 AM, Edwin C wrote: >>> How about you guys start charging for an annual fee or something? >>> >>> Just to assure that qmailtoaster gets updated all the time: dovecot, >>> spamassassin, clamav... the rest of the stuff. >>> >>> Then you should have flawless installs on CentOS 6 and CentOs 7. > The driving force of the project has been Eric S. Without him we wouldn't have the toaster we have now... Lately he has been less active with this project, and that starts to show... If you are reading this Eric, it would be nice to hear your opinion, would you have more time for the project if some compensation for your work could be arranged? Best, Peter - To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
Re: [qmailtoaster] Forcing authentication (submission) for all users
HI, On Thu, Dec 18, 2014 at 4:55 PM, Dan McAllister wrote: > If I had my druthers, a stock QMT would come with SpamDyke pre-installed... > not so much so that I could block a great deal of SPAM, but because the > SpamDyke control of the qmail-smtp is so easy. Thanks for your input Dan, that sounds like a good way to setup sending messages. You don't have any idea about the two other issues I asked about, blacklisting local domains and local mail delivery (see my msg below)? Best, Peter > > > > On 12/15/2014 3:33 PM, Peter Peltonen wrote: > > Hi, > > I would like to force all users using my toaster to send mail to > authenticate. I've now managed to get Squirrelmail and Horde do that. > But I would like to know how to do this also with other (web)servers > that use the toaster as a smarthost? The other servers are running > Postfix. > > Another thing I remember that has been discussed in this list, but > what I couldn't find by searching the archives, was that if all users > authenticate, then one could blacklist all local domains in Spamdyke? > Is that advice still valid (and why should one do it, I'm curious)? > > Another thing I'm thinking is about local user accounts on the toaster > server. How are those handled if localhost is not allowed to relay > mail? Do they inject the mail to qmail directly without using smtp? > > Regards, > Peter > > - > To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com > For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com > > > > -- > IT4SOHO, LLC > 33 - 4th Street N, Suite 211 > St. Petersburg, FL 33701-3806 > > CALL TOLL FREE: > 877-IT4SOHO > > 877-484-7646 Phone > 727-647-7646 Local > 727-490-4394 Fax > > We have support plans for QMail! > - To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
[qmailtoaster] Forcing authentication (submission) for all users
Hi, I would like to force all users using my toaster to send mail to authenticate. I've now managed to get Squirrelmail and Horde do that. But I would like to know how to do this also with other (web)servers that use the toaster as a smarthost? The other servers are running Postfix. Another thing I remember that has been discussed in this list, but what I couldn't find by searching the archives, was that if all users authenticate, then one could blacklist all local domains in Spamdyke? Is that advice still valid (and why should one do it, I'm curious)? Another thing I'm thinking is about local user accounts on the toaster server. How are those handled if localhost is not allowed to relay mail? Do they inject the mail to qmail directly without using smtp? Regards, Peter - To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
Re: [qmailtoaster] how to block connections
Hi, On Mon, Dec 15, 2014 at 5:08 AM, Eric Broch wrote: > I think it's a connect and disconnect. I get them a lot. I'm not sure > what they are. If I telnet to my own server on port 25 from a remote > location and quit the telnet connection on port 25 right away it has the > same affect as you've posted in your email. Thanks for the info. The netblock is in India and I see more harm in them cluttering my smtp log than allowing traffick from them, so I added this rule to my /etc/sysconfig/iptables : -A RH-Firewall-1-INPUT -s 103.225.0.0/16 -j DROP before the ACCEPT rules for that chain and now the attempts have stopped. Regards, Peter - To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
[qmailtoaster] how to block connections
Hi, In my smtp log I see lots of this kind of connection entries: @4000548e1bdf373b6974 tcpserver: pid 20363 from 103.225.128.9 @4000548e1bdf373b6d5c tcpserver: ok 20363 myserver:myip :103.225.128.9::57521 These are coming from different IPs from 103.225.128.0/255.255.255.0 network I blacklisted those in Spamdyke's blacklist_ip and I am not seeing anything in my send log, so does that mean that those connections are not delivering any messages or should I debug this further somehow? Is iptables the only option to block those connections so they wouldn't even cause a log entry? Regards, Peter - To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
Re: [qmailtoaster] Re: Need help: How to setup qmailtoaster
Hi Jim, On Fri, Nov 7, 2014 at 10:04 PM, Jim Shupert wrote: > > Friends, > I realize that it is suggested to install cent os with a minimal install > > but is it OK to install as 'standard desktop' ;; with the selfish reason > to have available the stuff the standard desktop gives you > or should one really - most definitely-! > > do a minimal install with generic video drivers > > also i intend to do centos 6.6 64 bit I'm sure standard desktop will run as fine as minimal. If you you need more than 4GB memory then you need 64bit install, which is fine also. Regards, Peter - To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
Re: [qmailtoaster] Re: dovecot upgrade
Hi, On Sat, Oct 18, 2014 at 3:03 AM, Eric Shubert wrote: > > If you don't use the spambox option or otherwise use maildrop, you might be > able to simply remove maildrop-toaster. There might be some dependency with > qmail-admin though, I'm not sure. I do use maildrop, so removing it is not an option... What is the reason for dovecot to remove libcourierauth as the earlier version does not require that? Can I edit the spec file and remove that requirement? Regards, Peter - To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
[qmailtoaster] dovecot upgrade
As one needs at least dovecot version 2.1 to be able to disable SSLv3, I would need to upgrade my old dovecot-2.0.17-2.qtp packages to newer ones. I thought I just grab the packages from the latest bunch of .qt pacakges, but upgrading to those didn't work out: # rpm -Fvh dovecot-2.2.7-0.qt.el5.i386.rpm warning: dovecot-2.2.7-0.qt.el5.i386.rpm: Header V3 DSA signature: NOKEY, key ID 1bde5fd0 error: Failed dependencies: libcourierauth.so.0 is needed by (installed) maildrop-toaster-2.0.3-1.3.8.i686 I do not quite get what libcourierauth has to do with dovecot and why do I get this error? # rpm -qf /usr/lib/courier-authlib/libcourierauth.so.0 courier-authlib-toaster-0.59.2-1.3.10 Any advice how I should proceed in getting a newer version of dovecot installed? Peter - To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
Re: [qmailtoaster] Re: Disable SSLv3, POODLE: SSLv3 vulnerability
Hi, On Thu, Oct 16, 2014 at 1:51 AM, Eric Shubert wrote: > In order to disable SSLv3, you need to change your cyphers list in > /etc/dovecot/toaster.conf file for dovecot, and > /var/qmail/control/tlsserverciphers for qmail-smtpd. > > If you turn off SSLv3, that includes TLS, so you'd better turn off plain and > login authentication methods as well. Looks like digest-md5 or cram-md5 > would be the only non-plain-text authentication methods available. I imagine > Dan's loving that. ;) Regarding this StackExchange information: http://security.stackexchange.com/questions/70832/why-doesnt-the-tls-protocol-work-without-the-sslv3-ciphersuites there is no need to disable ciphers, but only SSL v3 protocol (POODLE is a protocol, not cipher, problem)? Here you can find software specific instructions for disabling SSL v3, including Dovecot: https://linode.com/docs/security/security-patches/disabling-sslv3-for-poodle I haven't tried these yet as it seems I need to upgrade my Dovecot installations first to be able to disable sslv3... Best, Peter - To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
[qmailtoaster] Character encoding issue with Squirrelmail + HTML messages
When a user receives an HTML multipart message (for example from outlook.com), I have noticed the following: * the non-HTML version of the message is displayed by default in Squirrelmail, and in this version umlauts are displayed incorrectly (as question marks) * if one opens the HTML attachment version of the message in Squirrelmail, the umlauts are displayed correctly * If one replies to the message, the quoted part is from the non-HTML message and therefore contains question marks instead of umlauts * If I view this message in Thunderbird instead, the HTML version is shown as default and when replying to the message umlauts show ok, but when I view the non-HTML version of the message also TB shows the characters as question marks Is anyone else experiencing these issues and do you have any suggestions how to fix at least the encoding issue when replying to a multipart message in Squirrelmail? Here is what the message source looks like in TB: " Content-Type: multipart/alternative; boundary="_000_900f17668f4c4cbe93698f67c9e17a5bDB3PR05MB380eurprd05pro_" MIME-Version: 1.0 --_000_900f17668f4c4cbe93698f67c9e17a5bDB3PR05MB380eurprd05pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable koitin laittaa uudistin-meilin nyt k??ntym??n my?s siulle. Ilmoitteletko, t= oimiiko k??nt? =3D tuliko t?m? siulle perille. " Regards, Peter - To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
Re: [qmailtoaster] Security - TLS/SSL ciphers
Hi, On Tue, Mar 25, 2014 at 2:27 AM, Eric Shubert wrote: > It came to my attention recently that the ciphers used by the stock QMT > aren't as secure as they might be. In fact, QMT was simply using all > available ciphers in no particular priority. > > The general intention of QMT is to be as secure as reasonably possible in > the stock configuration, and if security is too tight for someone, then can > deliberately relax the security configuration. > > With this in mind, I've modified the soon-to-be-offically-released qmail > for COS6 to include the following cipher string: > MEDIUM:HIGH:!SSLv2:!MD5:!RC4:!3DES > If anyone needs something more lenient, they can adjust their > tlsserverciphers file accordingly. > > For those of you on COS5 (or present COS6 hosts) who want to beef up their > TLS/SSL security, the following command will do it: > # openssl ciphers 'MEDIUM:HIGH:!SSLv2:!MD5:!RC4:!3DES' \ >>/var/qmail/control/tlsserverciphers > Thanks Eric, much appreciated! One question: does qmail need to be restarted after issuing the openssl command? Regards, Peter
Re: [qmailtoaster] Re: Virtualizing a QMT server!
Hi, On Sun, Mar 2, 2014 at 3:50 AM, Tony White wrote: > Hi Eric, > Thanks for the pointers but it still does not answer my > question? > > "Has anyone converted a running server to a VM?". > I've done this with my servers, converting to Xen VMs was not that hard and you can find plenty of tutorials online with a little googling. I am sure the situation is same with KVM. Best, Peter
Re: [qmailtoaster] Virtualizing a QMT server!
Hi, On Sat, Mar 1, 2014 at 7:07 PM, Unai Rodriguez wrote: > > > On Saturday, 01 March, 2014 09:49 PM, Tony White wrote: > >> Hi folks, >> Has anyone tried to virtualize a QMT server yet? >> Has it worked? If so can you tell me how you did it >> so I can do it for my server please? >> > I've been running three servers unders COS5 and Xen. The thing I would pay attention to is disk I/O. As there is continuous reading/writing happening in the Toaster VM, this might affect or be affected by other virtual machines accessing the same physical disk(s). Best, Peter
Re: [qmailtoaster] Any writeups out there on blocking email based on pattern matching?
Hi, On Mon, Nov 18, 2013 at 12:08 AM, Kelly Cobean wrote: > So I'm wondering if anyone knows of any good writeups or tutorials on > how to do pattern based mail dropping or other suggestions on how to cut > down on the garbage. I don't want SA to drop the messages because every > now and again it'll flag a legit message. > The most common suggestion on the list is to use Spamdyke. Have you tried it? It blocks email from misconfigured servers which are usually computers hijacked by spambots. Take a look at: http://wiki.qmailtoaster.com/index.php/Spamdyke Regards, Peter
Re: [qmailtoaster] IMAP Connection Limit
Hi Dan, On Wed, Nov 13, 2013 at 7:43 PM, Dan McAllister wrote: > Greeting Family/Team: > > Question from a client that I haven't been able to answer: > - Is there a limit to the number of simultaneous IMAP connections on a > QMT solution? > - If so, where is it controlled? > I think it is at least dependent on MAXCONNIP and MAXCONNC value: http://wiki.qmailtoaster.com/index.php/TCP_Server_limits_configuration I do not know about Dovecot specific limitations, there might be those as well? Regards, Peter
Re: [qmailtoaster] dropping Maildrop?
Hi, On Tue, Nov 12, 2013 at 4:13 AM, Eric Shubert wrote: > Is anyone really using maildrop filters? It seems to me that some time ago > there were a couple people who were. > I am! They are very useful as one can integrate easily bash scripts to them. > I know the 'spambox' feature uses maildrop, so if you rely on this > feature, let us know about it! > I am using the spambox feature as well. > maildrop will eventually be replaced by sieve, in conjunction with > dovecot's LDA. This will give us web-controlled server-side filtering, per > user. I'm a little leery of throwing dovecot's LDA and sieve into the mix > for the upcoming release though. > The current maildrop script uses a few programs that are in the courier > package, so in order to keep maildrop in the upcoming release, I'll need to > pull those programs out of courier and put them somewhere (probably in the > maildrop package). I'm not looking forward to that. I'd rather simply drop > the maildrop package. > > Anyone have thoughts on this? > > This really starts to sound like that many major components of the toaster will be replaced by new ones. I would compare it to RedHat replacing Xen virtualization (in CentOS 5) with KVM (In CentOS 6). If you want to move to COS6 it will require quite a lot of work if you are running many Xen VMs. Fortunately COS5 is supported for many years still and you have time to prepare for this change. This is actually what would be ideal with toaster as well: 1) To have a stable branch with existing components for COS5 that will receive security updates only and will not break any existing functionality and that will be supported for as long as possible 2) To have a new "bleeding edge" branch with new components for COS6 that can break existing functionality The only drawback here is of course the amount of work required. But I think the package that mostly keeps receiving updates is just ClamAV? This kind of solution would be optimal for me, how about others and how do you Eric feel about keeping two branches, would it mean too much work for you? Best regards, Peter > -- > -Eric 'shubes' > > > - > To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com > For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com > >
Re: [qmailtoaster] Re: how to disable local delivery for one virtual domain
Hi, Thanks for your clarification Dan. One question: On Wed, Nov 6, 2013 at 6:29 PM, Dan McAllister wrote: > I'm johnny-come-lately on this, and Peter nearly nailed it: > > 1) If you remove DOMAIN-X.com from *rcpthosts*, you no longer accept mail > for it at all -- so it probably needs to remain there (or in > *morercpthosts*) > I do not want to accept mail for this domain. I only want users to be able to access the old mailboxes via IMAP until their contract runs out. The issue I washaving is that the same server acts as the web server for that domain and mail was being relayed from their contact forms etc to the old inboxes and not to the new inboxes at Office365. > 2) You should remove the domain from *virtualdomains* > 3) If present, you must also remove the domain from *locals* > (All files located in */var/qmail/control*) > > Having done the above, the QMT knows to accept mail for DOMAIN-X.com, but > not where to deliver it (you took that out!)... so now you go into > smtproutes and tell it where to forward the mail... > That domain is still in smptroutes and mail seems to be relaying to Office365 ok. So should I keep the domain in rcpthosts or not, will it do me some harm that it is not there? I am not actually using SPF. When setting up my mail servers it seemed to cause more troubles than it was worth. Perhaps this has changed and it would be a good idea nowadays? Thanks for your help, Peter
Re: [qmailtoaster] Re: how to disable local delivery for one virtual domain
Hi, On Wed, Nov 6, 2013 at 1:14 AM, Eric Shubert wrote: > On 11/05/2013 01:48 PM, Peter Peltonen wrote: > >> Hi, >> >> I have a virtual domain on a toaster which mails go nowadays to >> Office365 (-> MX is pointint there). >> >> I would still need to offer IMAP service for this domain, but if an >> email is sent through this toaster to that virtual domain, it should not >> be delivered locally to the toaster inbox, but it should sent to >> Office365 (= treated as a message that should be sent to the default >> smtp smarthost defined in smtproutes). >> >> How can I achieve this, do I just remove the domain from rcpthosts? >> >> Regards, >> Peter >> > > Wouldn't you simply add a line in smtproutes for that domain to be sent to > the Office365 server? This did not work. What I tried in smtproutes: myvirtualdomain.dom:office365.smtp.server.dom :mydefaultsmtp.dom I think the toaster does local delivery before checking the contents of smtproutes... Removing the domain from rcpthosts and virtualdomains file solved the situation: I still can login with webmail to the old account and sending messages using the toaster as the smtp server delivers to office365 and not to the toaster. Regards, Peter > > -- > -Eric 'shubes' > > > - > To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com > For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com > >
