Mailing List Archive: qmail-remote crashed.

qmail-remote crashed.

Feb 18, 2019, 7:30 AM

Post #1 of 14 (4275 views)

Hi all

I made this weekend the migration of my qmail to a virtual machine
with opensuse 42.2 leap, (4vcpu and 4G RAM and a faster internet link,
better than the previous server).

everything is working fine and several emails are already being sent
and received.

however I am having many segfault problems with qmail-remote.

the qmail settings as well as the defined limits are identical to the
previous server.

kernel 4.4.62-18.6-default 64 bits
qmail-smtpd-softlimit = 66000000

it *seems* that errors occur when qmail tries to deliver mail to
*.mail.protection.outlook.com domains (at least it seems) , but I can
access the mta's on port 25 using telnet.

here is a part of strace for qmail-rspawn

select(84, [.0 3 5 7 9 11 13 15 17 19 21 25 27 29 31 33 35 37 39 41 43
45 47 49 51 53 55 57 59 61 63 65 67 69 71 75 77 79 81 83], NULL, NULL,
NULL) = 1 (in [0])
rt_sigprocmask(SIG_BLOCK, [CHLD], NULL, 8) = 0
read(0, "\n\00017/1048242\0naoresponda@bhz.jam"..., 1024) = 65
open("17/1048242", O_RDONLY|O_NONBLOCK) = 2
fstat(2, {st_mode=S_IFREG|0644, st_size=11841, ...}) = 0
pipe([23, 24]) = 0
fcntl(23, F_SETFD, FD_CLOEXEC) = 0
vfork() = 21071
close(2) = 0
fcntl(24, F_SETFD, FD_CLOEXEC) = 0
rt_sigprocmask(SIG_UNBLOCK, [CHLD], NULL, 8) = 0
select(84, [.0 3 5 7 9 11 13 15 17 19 21 23 25 27 29 31 33 35 37 39 41
43 45 47 49 51 53 55 57 59 61 63 65 67 69 71 75 77 79 81 83], NULL,
NULL, NULL) = ? ERESTARTNOHAND (To be
restarted if no handler)
--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_KILLED, si_pid=20994,
si_uid=361, si_status=SIGSEGV, si_utime=7, si_stime=0} ---
wait4(-1, [{WIFSIGNALED(s) && WTERMSIG(s) == SIGSEGV}], WNOHANG, NULL) = 20994
close(32) = 0
wait4(-1, 0x7ffd77421f1c, WNOHANG, NULL) = 0
rt_sigreturn({mask=[]}) = -1 EINTR (Interrupted system call)
rt_sigprocmask(SIG_BLOCK, [CHLD], NULL, 8) = 0
rt_sigprocmask(SIG_UNBLOCK, [CHLD], NULL, 8) = 0
select(84, [.0 3 5 7 9 11 13 15 17 19 21 23 25 27 29 31 33 35 37 39 41
43 45 47 49 51 53 55 57 59 61 63 65 67 69 71 75 77 79 81 83], NULL,
NULL, NULL) = 1 (in [31])
rt_sigprocmask(SIG_BLOCK, [CHLD], NULL, 8) = 0
read(31, "", 128) = 0
write(1, "\16\0Zqmail-remote crashed.\n\0", 26) = 26
close(31) = 0
rt_sigprocmask(SIG_UNBLOCK, [CHLD], NULL, 8) = 0

any ideas?

--
*Esta mensagem pode conter informações confidenciais ou privilegiadas,
sendo seu sigilo protegido por lei. Se você não for o destinatário ou a
pessoa autorizada a receber esta mensagem, não pode usar, copiar ou
divulgar as informações nela contidas ou tomar qualquer ação baseada nessas
informações. Se você recebeu esta mensagem por engano, por favor avise
imediatamente ao remetente, respondendo o e-mail e em seguida apague-o.
Agradecemos sua cooperação.*

Re: qmail-remote crashed. [ In reply to ]

feh at fehcom

Feb 18, 2019, 8:35 AM

Post #2 of 14 (4275 views)

Permalink

Hi,

> Am 18.02.2019 um 16:30 schrieb Rejaine Silveira Monteiro <rejaine@bhz.jamef.com.br>:
>
> Hi all
>
> I made this weekend the migration of my qmail to a virtual machine
> with opensuse 42.2 leap, (4vcpu and 4G RAM and a faster internet link,
> better than the previous server).
>
> everything is working fine and several emails are already being sent
> and received.
>
> however I am having many segfault problems with qmail-remote.
>
> the qmail settings as well as the defined limits are identical to the
> previous server.
>
> kernel 4.4.62-18.6-default 64 bits
> qmail-smtpd-softlimit = 66000000

Remember: Softlimit only is in place for qmail-smtpd (receiving emails); not sending emails.

>
> it *seems* that errors occur when qmail tries to deliver mail to
> *.mail.protection.outlook.com domains (at least it seems) , but I can
> access the mta's on port 25 using telnet.
>
> here is a part of strace for qmail-rspawn
>
> select(84, [.0 3 5 7 9 11 13 15 17 19 21 25 27 29 31 33 35 37 39 41 43
> 45 47 49 51 53 55 57 59 61 63 65 67 69 71 75 77 79 81 83], NULL, NULL,
> NULL) = 1 (in [0])
> rt_sigprocmask(SIG_BLOCK, [CHLD], NULL, 8) = 0
> read(0, "\n\00017/1048242\0naoresponda@bhz.jam"..., 1024) = 65
> open("17/1048242", O_RDONLY|O_NONBLOCK) = 2
> fstat(2, {st_mode=S_IFREG|0644, st_size=11841, ...}) = 0
> pipe([23, 24]) = 0
> fcntl(23, F_SETFD, FD_CLOEXEC) = 0
> vfork() = 21071
> close(2) = 0
> fcntl(24, F_SETFD, FD_CLOEXEC) = 0
> rt_sigprocmask(SIG_UNBLOCK, [CHLD], NULL, 8) = 0
> select(84, [.0 3 5 7 9 11 13 15 17 19 21 23 25 27 29 31 33 35 37 39 41
> 43 45 47 49 51 53 55 57 59 61 63 65 67 69 71 75 77 79 81 83], NULL,
> NULL, NULL) = ? ERESTARTNOHAND (To be
> restarted if no handler)
> --- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_KILLED, si_pid=20994,
> si_uid=361, si_status=SIGSEGV, si_utime=7, si_stime=0} ---
> wait4(-1, [{WIFSIGNALED(s) && WTERMSIG(s) == SIGSEGV}], WNOHANG, NULL) = 20994
> close(32) = 0
> wait4(-1, 0x7ffd77421f1c, WNOHANG, NULL) = 0
> rt_sigreturn({mask=[]}) = -1 EINTR (Interrupted system call)
> rt_sigprocmask(SIG_BLOCK, [CHLD], NULL, 8) = 0
> rt_sigprocmask(SIG_UNBLOCK, [CHLD], NULL, 8) = 0
> select(84, [.0 3 5 7 9 11 13 15 17 19 21 23 25 27 29 31 33 35 37 39 41
> 43 45 47 49 51 53 55 57 59 61 63 65 67 69 71 75 77 79 81 83], NULL,
> NULL, NULL) = 1 (in [31])
> rt_sigprocmask(SIG_BLOCK, [CHLD], NULL, 8) = 0
> read(31, "", 128) = 0
> write(1, "\16\0Zqmail-remote crashed.\n\0", 26) = 26
> close(31) = 0
> rt_sigprocmask(SIG_UNBLOCK, [CHLD], NULL, 8) = 0
>
> any ideas?

Not currently. But you can give me some more informations:

a) What is the version of ucspi-ssl you have used (check the symlinked ucspi.h).
b) What is the OpenSSL/LibreSSL Version you are using?

In oder to diagnose TSL problems, disable TLS delivery to that address:

tlsdestinations:
!.outlook.com:

and see, what is happening.

Use

mconnect 104.47.9.33

to check the settings after responding with 'ehlo you'.

Best regards.
--eh.

>
> --
> *Esta mensagem pode conter informações confidenciais ou privilegiadas,
> sendo seu sigilo protegido por lei. Se você não for o destinatário ou a
> pessoa autorizada a receber esta mensagem, não pode usar, copiar ou
> divulgar as informações nela contidas ou tomar qualquer ação baseada nessas
> informações. Se você recebeu esta mensagem por engano, por favor avise
> imediatamente ao remetente, respondendo o e-mail e em seguida apague-o.
> Agradecemos sua cooperação.*
>

Dr. Erwin Hoffmann | FEHCom | http://www.fehcom.de | PGP Key-Id 7E4034BE

Re: qmail-remote crashed. [ In reply to ]

rejaine at bhz

Feb 18, 2019, 9:26 AM

Post #3 of 14 (4275 views)

Permalink

Helo Erwin

I'm not using TLS and using qmail-1.03-jms1-7.10.patch (FORCE_TLS=0
and DENY_TLS=1)
anyway, I created the tlsdestinations file as you indicated, but it
did not work.

the only problem is with clients using mail.protection.outlook.com

in the link below you can read that there may be problems with new
ips, due to some "policy reputation" stuff (our mta ip was changed
last nigth) and maybe that is why we can not send it there ..

https://docs.microsoft.com/pt-br/office365/securitycompliance/removing-a-user-domain-or-ip-address-from-a-block-list-after-sending-spam-email

I publish SPF, but not DMARC or DKIM ... so I guess I'll have to wait
a little longer ..

Em seg, 18 de fev de 2019 às 13:35, Erwin Hoffmann <feh@fehcom.de> escreveu:
>
> Hi,
>
>
> > Am 18.02.2019 um 16:30 schrieb Rejaine Silveira Monteiro <rejaine@bhz.jamef.com.br>:
> >
> > Hi all
> >
> > I made this weekend the migration of my qmail to a virtual machine
> > with opensuse 42.2 leap, (4vcpu and 4G RAM and a faster internet link,
> > better than the previous server).
> >
> > everything is working fine and several emails are already being sent
> > and received.
> >
> > however I am having many segfault problems with qmail-remote.
> >
> > the qmail settings as well as the defined limits are identical to the
> > previous server.
> >
> > kernel 4.4.62-18.6-default 64 bits
> > qmail-smtpd-softlimit = 66000000
>
> Remember: Softlimit only is in place for qmail-smtpd (receiving emails); not sending emails.
>
>
> >
> > it *seems* that errors occur when qmail tries to deliver mail to
> > *.mail.protection.outlook.com domains (at least it seems) , but I can
> > access the mta's on port 25 using telnet.
> >
> > here is a part of strace for qmail-rspawn
> >
> > select(84, [.0 3 5 7 9 11 13 15 17 19 21 25 27 29 31 33 35 37 39 41 43
> > 45 47 49 51 53 55 57 59 61 63 65 67 69 71 75 77 79 81 83], NULL, NULL,
> > NULL) = 1 (in [0])
> > rt_sigprocmask(SIG_BLOCK, [CHLD], NULL, 8) = 0
> > read(0, "\n\00017/1048242\0naoresponda@bhz.jam"..., 1024) = 65
> > open("17/1048242", O_RDONLY|O_NONBLOCK) = 2
> > fstat(2, {st_mode=S_IFREG|0644, st_size=11841, ...}) = 0
> > pipe([23, 24]) = 0
> > fcntl(23, F_SETFD, FD_CLOEXEC) = 0
> > vfork() = 21071
> > close(2) = 0
> > fcntl(24, F_SETFD, FD_CLOEXEC) = 0
> > rt_sigprocmask(SIG_UNBLOCK, [CHLD], NULL, 8) = 0
> > select(84, [.0 3 5 7 9 11 13 15 17 19 21 23 25 27 29 31 33 35 37 39 41
> > 43 45 47 49 51 53 55 57 59 61 63 65 67 69 71 75 77 79 81 83], NULL,
> > NULL, NULL) = ? ERESTARTNOHAND (To be
> > restarted if no handler)
> > --- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_KILLED, si_pid=20994,
> > si_uid=361, si_status=SIGSEGV, si_utime=7, si_stime=0} ---
> > wait4(-1, [{WIFSIGNALED(s) && WTERMSIG(s) == SIGSEGV}], WNOHANG, NULL) = 20994
> > close(32) = 0
> > wait4(-1, 0x7ffd77421f1c, WNOHANG, NULL) = 0
> > rt_sigreturn({mask=[]}) = -1 EINTR (Interrupted system call)
> > rt_sigprocmask(SIG_BLOCK, [CHLD], NULL, 8) = 0
> > rt_sigprocmask(SIG_UNBLOCK, [CHLD], NULL, 8) = 0
> > select(84, [.0 3 5 7 9 11 13 15 17 19 21 23 25 27 29 31 33 35 37 39 41
> > 43 45 47 49 51 53 55 57 59 61 63 65 67 69 71 75 77 79 81 83], NULL,
> > NULL, NULL) = 1 (in [31])
> > rt_sigprocmask(SIG_BLOCK, [CHLD], NULL, 8) = 0
> > read(31, "", 128) = 0
> > write(1, "\16\0Zqmail-remote crashed.\n\0", 26) = 26
> > close(31) = 0
> > rt_sigprocmask(SIG_UNBLOCK, [CHLD], NULL, 8) = 0
> >
> > any ideas?
>
> Not currently. But you can give me some more informations:
>
> a) What is the version of ucspi-ssl you have used (check the symlinked ucspi.h).
> b) What is the OpenSSL/LibreSSL Version you are using?
>
> In oder to diagnose TSL problems, disable TLS delivery to that address:
>
> tlsdestinations:
> !.outlook.com:
>
> and see, what is happening.
>
> Use
>
> mconnect 104.47.9.33
>
> to check the settings after responding with 'ehlo you'.
>
> Best regards.
> --eh.
>
>
> >
> > --
> > *Esta mensagem pode conter informações confidenciais ou privilegiadas,
> > sendo seu sigilo protegido por lei. Se você não for o destinatário ou a
> > pessoa autorizada a receber esta mensagem, não pode usar, copiar ou
> > divulgar as informações nela contidas ou tomar qualquer ação baseada nessas
> > informações. Se você recebeu esta mensagem por engano, por favor avise
> > imediatamente ao remetente, respondendo o e-mail e em seguida apague-o.
> > Agradecemos sua cooperação.*
> >
>
> Dr. Erwin Hoffmann | FEHCom | http://www.fehcom.de | PGP Key-Id 7E4034BE
>
>
>
>
>
>
>

--
*Esta mensagem pode conter informações confidenciais ou privilegiadas,
sendo seu sigilo protegido por lei. Se você não for o destinatário ou a
pessoa autorizada a receber esta mensagem, não pode usar, copiar ou
divulgar as informações nela contidas ou tomar qualquer ação baseada nessas
informações. Se você recebeu esta mensagem por engano, por favor avise
imediatamente ao remetente, respondendo o e-mail e em seguida apague-o.
Agradecemos sua cooperação.*

Re: qmail-remote crashed. [ In reply to ]

jjohnstone at tridentusa

Feb 18, 2019, 10:33 AM

Post #4 of 14 (4275 views)

Permalink

On 2/18/19 12:26 PM, Rejaine Silveira Monteiro wrote:
> Helo Erwin
>
> I'm not using TLS and using qmail-1.03-jms1-7.10.patch (FORCE_TLS=0
> and DENY_TLS=1)

I can't offer much help with specific ideas for a solution but I can
offer some advice about where not to look.

In John Simpson's patch FORCE_TLS and DENY_TLS are only used by
qmail-smtpd. They are not used elsewhere.

> anyway, I created the tlsdestinations file as you indicated, but it
> did not work.
>
> the only problem is with clients using mail.protection.outlook.com
>
> in the link below you can read that there may be problems with new
> ips, due to some "policy reputation" stuff (our mta ip was changed
> last nigth) and maybe that is why we can not send it there ..
>
> https://docs.microsoft.com/pt-br/office365/securitycompliance/removing-a-user-domain-or-ip-address-from-a-block-list-after-sending-spam-email

If there is a problem with your IP addresses or domain names being
acceptable to Microsoft you will be seeing 4yz or 5yz SMTP reply errors
returned by them to you. Those errors will be in your qmail-send log
files. Those problems wouldn't cause qmail-remote to crash.

> I publish SPF, but not DMARC or DKIM ... so I guess I'll have to wait
> a little longer ..

Any changes with SPF, DKIM, etc will not make a difference with
qmail-remote crashing.

If you have /var/qmail/control/clientcert.pem you can rename that file
out of the way so that qmail-remote won't use it. It will effectively
disable TLS for qmail-remote. Just be aware that without TLS you may
have delivery problems with certain destinations since some will only
accept mail transferred with TLS.

-
John J.

Re: qmail-remote crashed. [ In reply to ]

amb-sendok-1553107684.fahkijinkakjkpmnffpa at bradfo

Feb 18, 2019, 10:48 AM

Post #5 of 14 (4275 views)

Permalink

Thus said John Johnstone on Mon, 18 Feb 2019 13:33:10 -0500:

> If you have /var/qmail/control/clientcert.pem you can rename that file
> out of the way so that qmail-remote won't use it. It will effectively
> disable TLS for qmail-remote. Just be aware that without TLS you may
> have delivery problems with certain destinations since some will only
> accept mail transferred with TLS.

I'm curious to know which MTAs out there on the public internet will
refuse to accept email from MTAs not using TLS.

Andy
--
TAI64 timestamp: 400000005c6afe08

Re: qmail-remote crashed. [ In reply to ]

rejaine at bhz

Feb 18, 2019, 11:03 AM

Post #6 of 14 (4275 views)

Permalink

this particular server is only a relay * (an antispam gateway) .. is
not used to authenticate user accounts. only sends emails and receives
to redirect to other internal servers.

Em seg, 18 de fev de 2019 às 15:50, Andy Bradford
<amb-sendok-1553107684.fahkijinkakjkpmnffpa@bradfords.org> escreveu:
>
> Thus said John Johnstone on Mon, 18 Feb 2019 13:33:10 -0500:
>
> > If you have /var/qmail/control/clientcert.pem you can rename that file
> > out of the way so that qmail-remote won't use it. It will effectively
> > disable TLS for qmail-remote. Just be aware that without TLS you may
> > have delivery problems with certain destinations since some will only
> > accept mail transferred with TLS.
>
> I'm curious to know which MTAs out there on the public internet will
> refuse to accept email from MTAs not using TLS.
>
> Andy
> --
> TAI64 timestamp: 400000005c6afe08
>
>

--
*Esta mensagem pode conter informações confidenciais ou privilegiadas,
sendo seu sigilo protegido por lei. Se você não for o destinatário ou a
pessoa autorizada a receber esta mensagem, não pode usar, copiar ou
divulgar as informações nela contidas ou tomar qualquer ação baseada nessas
informações. Se você recebeu esta mensagem por engano, por favor avise
imediatamente ao remetente, respondendo o e-mail e em seguida apague-o.
Agradecemos sua cooperação.*

Re: qmail-remote crashed. [ In reply to ]

rejaine at bhz

Feb 18, 2019, 11:12 AM

Post #7 of 14 (4275 views)

Permalink

Hi , John J.

I renamed all files * .pem, restart qmail, and all pending emails for
outlook.com were delivered. I'm still trying to understand what
happened ... I'll going to do a test generating the keys again (I
believe that the ones that were in use were only copied from the
previous server and not generated again)

thanks!

Em seg, 18 de fev de 2019 às 15:33, John Johnstone
<jjohnstone@tridentusa.com> escreveu:
>
> On 2/18/19 12:26 PM, Rejaine Silveira Monteiro wrote:
> > Helo Erwin
> >
> > I'm not using TLS and using qmail-1.03-jms1-7.10.patch (FORCE_TLS=0
> > and DENY_TLS=1)
>
> I can't offer much help with specific ideas for a solution but I can
> offer some advice about where not to look.
>
> In John Simpson's patch FORCE_TLS and DENY_TLS are only used by
> qmail-smtpd. They are not used elsewhere.
>
> > anyway, I created the tlsdestinations file as you indicated, but it
> > did not work.
> >
> > the only problem is with clients using mail.protection.outlook.com
> >
> > in the link below you can read that there may be problems with new
> > ips, due to some "policy reputation" stuff (our mta ip was changed
> > last nigth) and maybe that is why we can not send it there ..
> >
> > https://docs.microsoft.com/pt-br/office365/securitycompliance/removing-a-user-domain-or-ip-address-from-a-block-list-after-sending-spam-email
>
> If there is a problem with your IP addresses or domain names being
> acceptable to Microsoft you will be seeing 4yz or 5yz SMTP reply errors
> returned by them to you. Those errors will be in your qmail-send log
> files. Those problems wouldn't cause qmail-remote to crash.
>
> > I publish SPF, but not DMARC or DKIM ... so I guess I'll have to wait
> > a little longer ..
>
> Any changes with SPF, DKIM, etc will not make a difference with
> qmail-remote crashing.
>
> If you have /var/qmail/control/clientcert.pem you can rename that file
> out of the way so that qmail-remote won't use it. It will effectively
> disable TLS for qmail-remote. Just be aware that without TLS you may
> have delivery problems with certain destinations since some will only
> accept mail transferred with TLS.
>
> -
> John J.

--
*Esta mensagem pode conter informações confidenciais ou privilegiadas,
sendo seu sigilo protegido por lei. Se você não for o destinatário ou a
pessoa autorizada a receber esta mensagem, não pode usar, copiar ou
divulgar as informações nela contidas ou tomar qualquer ação baseada nessas
informações. Se você recebeu esta mensagem por engano, por favor avise
imediatamente ao remetente, respondendo o e-mail e em seguida apague-o.
Agradecemos sua cooperação.*

Re: qmail-remote crashed. [ In reply to ]

feh at fehcom

Feb 18, 2019, 11:19 AM

Post #8 of 14 (4275 views)

Permalink

Hi,

> Am 18.02.2019 um 18:26 schrieb Rejaine Silveira Monteiro <rejaine@bhz.jamef.com.br>:
>
> Helo Erwin
>
> I'm not using TLS and using qmail-1.03-jms1-7.10.patch (FORCE_TLS=0
> and DENY_TLS=1)
> anyway, I created the tlsdestinations file as you indicated, but it
> did not work.

Sorry, caught the mail on the wrong mailing list ... I though you are referring to my s/qmail.

>
> the only problem is with clients using mail.protection.outlook.com
>
> in the link below you can read that there may be problems with new
> ips, due to some "policy reputation" stuff (our mta ip was changed
> last nigth) and maybe that is why we can not send it there ..
>
> https://docs.microsoft.com/pt-br/office365/securitycompliance/removing-a-user-domain-or-ip-address-from-a-block-list-after-sending-spam-email
>
> I publish SPF, but not DMARC or DKIM ... so I guess I'll have to wait
> a little longer ..

There is however little, I can do in this case.

Sorry.

Regards.
--eh.

>
> Em seg, 18 de fev de 2019 às 13:35, Erwin Hoffmann <feh@fehcom.de> escreveu:
>>
>> Hi,
>>
>>
>>> Am 18.02.2019 um 16:30 schrieb Rejaine Silveira Monteiro <rejaine@bhz.jamef.com.br>:
>>>
>>> Hi all
>>>
>>> I made this weekend the migration of my qmail to a virtual machine
>>> with opensuse 42.2 leap, (4vcpu and 4G RAM and a faster internet link,
>>> better than the previous server).
>>>
>>> everything is working fine and several emails are already being sent
>>> and received.
>>>
>>> however I am having many segfault problems with qmail-remote.
>>>
>>> the qmail settings as well as the defined limits are identical to the
>>> previous server.
>>>
>>> kernel 4.4.62-18.6-default 64 bits
>>> qmail-smtpd-softlimit = 66000000
>>
>> Remember: Softlimit only is in place for qmail-smtpd (receiving emails); not sending emails.
>>
>>
>>>
>>> it *seems* that errors occur when qmail tries to deliver mail to
>>> *.mail.protection.outlook.com domains (at least it seems) , but I can
>>> access the mta's on port 25 using telnet.
>>>
>>> here is a part of strace for qmail-rspawn
>>>
>>> select(84, [.0 3 5 7 9 11 13 15 17 19 21 25 27 29 31 33 35 37 39 41 43
>>> 45 47 49 51 53 55 57 59 61 63 65 67 69 71 75 77 79 81 83], NULL, NULL,
>>> NULL) = 1 (in [0])
>>> rt_sigprocmask(SIG_BLOCK, [CHLD], NULL, 8) = 0
>>> read(0, "\n\00017/1048242\0naoresponda@bhz.jam"..., 1024) = 65
>>> open("17/1048242", O_RDONLY|O_NONBLOCK) = 2
>>> fstat(2, {st_mode=S_IFREG|0644, st_size=11841, ...}) = 0
>>> pipe([23, 24]) = 0
>>> fcntl(23, F_SETFD, FD_CLOEXEC) = 0
>>> vfork() = 21071
>>> close(2) = 0
>>> fcntl(24, F_SETFD, FD_CLOEXEC) = 0
>>> rt_sigprocmask(SIG_UNBLOCK, [CHLD], NULL, 8) = 0
>>> select(84, [.0 3 5 7 9 11 13 15 17 19 21 23 25 27 29 31 33 35 37 39 41
>>> 43 45 47 49 51 53 55 57 59 61 63 65 67 69 71 75 77 79 81 83], NULL,
>>> NULL, NULL) = ? ERESTARTNOHAND (To be
>>> restarted if no handler)
>>> --- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_KILLED, si_pid=20994,
>>> si_uid=361, si_status=SIGSEGV, si_utime=7, si_stime=0} ---
>>> wait4(-1, [{WIFSIGNALED(s) && WTERMSIG(s) == SIGSEGV}], WNOHANG, NULL) = 20994
>>> close(32) = 0
>>> wait4(-1, 0x7ffd77421f1c, WNOHANG, NULL) = 0
>>> rt_sigreturn({mask=[]}) = -1 EINTR (Interrupted system call)
>>> rt_sigprocmask(SIG_BLOCK, [CHLD], NULL, 8) = 0
>>> rt_sigprocmask(SIG_UNBLOCK, [CHLD], NULL, 8) = 0
>>> select(84, [.0 3 5 7 9 11 13 15 17 19 21 23 25 27 29 31 33 35 37 39 41
>>> 43 45 47 49 51 53 55 57 59 61 63 65 67 69 71 75 77 79 81 83], NULL,
>>> NULL, NULL) = 1 (in [31])
>>> rt_sigprocmask(SIG_BLOCK, [CHLD], NULL, 8) = 0
>>> read(31, "", 128) = 0
>>> write(1, "\16\0Zqmail-remote crashed.\n\0", 26) = 26
>>> close(31) = 0
>>> rt_sigprocmask(SIG_UNBLOCK, [CHLD], NULL, 8) = 0
>>>
>>> any ideas?
>>
>> Not currently. But you can give me some more informations:
>>
>> a) What is the version of ucspi-ssl you have used (check the symlinked ucspi.h).
>> b) What is the OpenSSL/LibreSSL Version you are using?
>>
>> In oder to diagnose TSL problems, disable TLS delivery to that address:
>>
>> tlsdestinations:
>> !.outlook.com:
>>
>> and see, what is happening.
>>
>> Use
>>
>> mconnect 104.47.9.33
>>
>> to check the settings after responding with 'ehlo you'.
>>
>> Best regards.
>> --eh.
>>
>>
>>>
>>> --
>>> *Esta mensagem pode conter informações confidenciais ou privilegiadas,
>>> sendo seu sigilo protegido por lei. Se você não for o destinatário ou a
>>> pessoa autorizada a receber esta mensagem, não pode usar, copiar ou
>>> divulgar as informações nela contidas ou tomar qualquer ação baseada nessas
>>> informações. Se você recebeu esta mensagem por engano, por favor avise
>>> imediatamente ao remetente, respondendo o e-mail e em seguida apague-o.
>>> Agradecemos sua cooperação.*
>>>
>>
>> Dr. Erwin Hoffmann | FEHCom | http://www.fehcom.de | PGP Key-Id 7E4034BE
>>
>>
>>
>>
>>
>>
>>
>
> --
> *Esta mensagem pode conter informações confidenciais ou privilegiadas,
> sendo seu sigilo protegido por lei. Se você não for o destinatário ou a
> pessoa autorizada a receber esta mensagem, não pode usar, copiar ou
> divulgar as informações nela contidas ou tomar qualquer ação baseada nessas
> informações. Se você recebeu esta mensagem por engano, por favor avise
> imediatamente ao remetente, respondendo o e-mail e em seguida apague-o.
> Agradecemos sua cooperação.*
>

Dr. Erwin Hoffmann | FEHCom | http://www.fehcom.de | PGP Key-Id 7E4034BE

Re: qmail-remote crashed. [ In reply to ]

jjohnstone at tridentusa

Feb 18, 2019, 11:25 AM

Post #9 of 14 (4275 views)

Permalink

On 2/18/19 1:48 PM, Andy Bradford wrote:
> Thus said John Johnstone on Mon, 18 Feb 2019 13:33:10 -0500:
>
>> If you have /var/qmail/control/clientcert.pem you can rename that file
>> out of the way so that qmail-remote won't use it. It will effectively
>> disable TLS for qmail-remote. Just be aware that without TLS you may
>> have delivery problems with certain destinations since some will only
>> accept mail transferred with TLS.
>
> I'm curious to know which MTAs out there on the public internet will
> refuse to accept email from MTAs not using TLS.

Not many I would guess. A few months ago I was having a delivery
problem and disabled TLS for qmail-remote. Later on while it was
disabled there was one domain that wouldn't accept mail without TLS.
Surprised me when I saw it. I didn't make a note of the domain. I just
took a brief look in the logs to see if I could find it but the details
are dim now and I'm not finding it.

-
John J.

Re: qmail-remote crashed. [ In reply to ]

jjohnstone at tridentusa

Feb 18, 2019, 12:05 PM

Post #10 of 14 (4275 views)

Permalink

On 2/18/19 2:12 PM, Rejaine Silveira Monteiro wrote:
> Hi , John J.
>
> I renamed all files * .pem, restart qmail, and all pending emails for
> outlook.com were delivered. I'm still trying to understand what
> happened ... I'll going to do a test generating the keys again (I
> believe that the ones that were in use were only copied from the
> previous server and not generated again)
>
> thanks!

As many have often pointed out as well as John Simpson himself, having a
publicly facing mail server is a significant effort. At the time John's
patch was maintained that was true and it's even more so today. Unless
you are investing quite a bit of time with it, you'll be likely to have
delivery problems at some point. As Erwin's suggestions may have given
the hint to you, TLS today is a moving target for creating
interoperability problems.

clientcert.pem is for qmail-remote. servercert.pem is for qmail-smtpd
so if that has also been renamed you have disabled TLS for qmail-smtpd also.

-
John J.

> Em seg, 18 de fev de 2019 às 15:33, John Johnstone
> <jjohnstone@tridentusa.com> escreveu:
>>
>> On 2/18/19 12:26 PM, Rejaine Silveira Monteiro wrote:
>>> Helo Erwin
>>>
>>> I'm not using TLS and using qmail-1.03-jms1-7.10.patch (FORCE_TLS=0
>>> and DENY_TLS=1)
>>
>> I can't offer much help with specific ideas for a solution but I can
>> offer some advice about where not to look.
>>
>> In John Simpson's patch FORCE_TLS and DENY_TLS are only used by
>> qmail-smtpd. They are not used elsewhere.
>>
>>> anyway, I created the tlsdestinations file as you indicated, but it
>>> did not work.
>>>
>>> the only problem is with clients using mail.protection.outlook.com
>>>
>>> in the link below you can read that there may be problems with new
>>> ips, due to some "policy reputation" stuff (our mta ip was changed
>>> last nigth) and maybe that is why we can not send it there ..
>>>
>>> https://docs.microsoft.com/pt-br/office365/securitycompliance/removing-a-user-domain-or-ip-address-from-a-block-list-after-sending-spam-email
>>
>> If there is a problem with your IP addresses or domain names being
>> acceptable to Microsoft you will be seeing 4yz or 5yz SMTP reply errors
>> returned by them to you. Those errors will be in your qmail-send log
>> files. Those problems wouldn't cause qmail-remote to crash.
>>
>>> I publish SPF, but not DMARC or DKIM ... so I guess I'll have to wait
>>> a little longer ..
>>
>> Any changes with SPF, DKIM, etc will not make a difference with
>> qmail-remote crashing.
>>
>> If you have /var/qmail/control/clientcert.pem you can rename that file
>> out of the way so that qmail-remote won't use it. It will effectively
>> disable TLS for qmail-remote. Just be aware that without TLS you may
>> have delivery problems with certain destinations since some will only
>> accept mail transferred with TLS.
>>
>> -
>> John J.
>

Re: qmail-remote crashed. [ In reply to ]

rejaine at bhz

Feb 19, 2019, 4:48 AM

Post #11 of 14 (4274 views)

Permalink

well, after the certificates again, qmail stopped crashing ..

however outlook.com now started to refuse messages with the error below:

104.47.2.36_failed_after_I_sent_the_message./Remote_host_said:_451_4.7.500_Server_busy._Please_try_again_later_from_[a.b.c.d]._(AS77712315)_[DB5EUR01FT062.eop-EUR01.prod.protection.outlook.com]/

at the moment I have more than 2 thousand messages in the queue giving
this error ... I believe they are blocking the new IP address ... :(

Em seg, 18 de fev de 2019 às 17:18, Rejaine Silveira Monteiro
<rejaine@bhz.jamef.com.br> escreveu:
>
> I just renamed *.pem only to take a test.
> I created both certificates again and it's working fine now (the cert
> files had been copied from an older server and with an older version
> of OS and openssl)
>
> Em seg, 18 de fev de 2019 às 17:08, John Johnstone
> <jjohnstone@tridentusa.com> escreveu:
> >
> > On 2/18/19 2:12 PM, Rejaine Silveira Monteiro wrote:
> > > Hi , John J.
> > >
> > > I renamed all files * .pem, restart qmail, and all pending emails for
> > > outlook.com were delivered. I'm still trying to understand what
> > > happened ... I'll going to do a test generating the keys again (I
> > > believe that the ones that were in use were only copied from the
> > > previous server and not generated again)
> > >
> > > thanks!
> >
> > As many have often pointed out as well as John Simpson himself, having a
> > publicly facing mail server is a significant effort. At the time John's
> > patch was maintained that was true and it's even more so today. Unless
> > you are investing quite a bit of time with it, you'll be likely to have
> > delivery problems at some point. As Erwin's suggestions may have given
> > the hint to you, TLS today is a moving target for creating
> > interoperability problems.
> >
> > clientcert.pem is for qmail-remote. servercert.pem is for qmail-smtpd
> > so if that has also been renamed you have disabled TLS for qmail-smtpd also.
> >
> > -
> > John J.
> >
> >
> > > Em seg, 18 de fev de 2019 às 15:33, John Johnstone
> > > <jjohnstone@tridentusa.com> escreveu:
> > >>
> > >> On 2/18/19 12:26 PM, Rejaine Silveira Monteiro wrote:
> > >>> Helo Erwin
> > >>>
> > >>> I'm not using TLS and using qmail-1.03-jms1-7.10.patch (FORCE_TLS=0
> > >>> and DENY_TLS=1)
> > >>
> > >> I can't offer much help with specific ideas for a solution but I can
> > >> offer some advice about where not to look.
> > >>
> > >> In John Simpson's patch FORCE_TLS and DENY_TLS are only used by
> > >> qmail-smtpd. They are not used elsewhere.
> > >>
> > >>> anyway, I created the tlsdestinations file as you indicated, but it
> > >>> did not work.
> > >>>
> > >>> the only problem is with clients using mail.protection.outlook.com
> > >>>
> > >>> in the link below you can read that there may be problems with new
> > >>> ips, due to some "policy reputation" stuff (our mta ip was changed
> > >>> last nigth) and maybe that is why we can not send it there ..
> > >>>
> > >>> https://docs.microsoft.com/pt-br/office365/securitycompliance/removing-a-user-domain-or-ip-address-from-a-block-list-after-sending-spam-email
> > >>
> > >> If there is a problem with your IP addresses or domain names being
> > >> acceptable to Microsoft you will be seeing 4yz or 5yz SMTP reply errors
> > >> returned by them to you. Those errors will be in your qmail-send log
> > >> files. Those problems wouldn't cause qmail-remote to crash.
> > >>
> > >>> I publish SPF, but not DMARC or DKIM ... so I guess I'll have to wait
> > >>> a little longer ..
> > >>
> > >> Any changes with SPF, DKIM, etc will not make a difference with
> > >> qmail-remote crashing.
> > >>
> > >> If you have /var/qmail/control/clientcert.pem you can rename that file
> > >> out of the way so that qmail-remote won't use it. It will effectively
> > >> disable TLS for qmail-remote. Just be aware that without TLS you may
> > >> have delivery problems with certain destinations since some will only
> > >> accept mail transferred with TLS.
> > >>
> > >> -
> > >> John J.
> > >
> >

--
*Esta mensagem pode conter informações confidenciais ou privilegiadas,
sendo seu sigilo protegido por lei. Se você não for o destinatário ou a
pessoa autorizada a receber esta mensagem, não pode usar, copiar ou
divulgar as informações nela contidas ou tomar qualquer ação baseada nessas
informações. Se você recebeu esta mensagem por engano, por favor avise
imediatamente ao remetente, respondendo o e-mail e em seguida apague-o.
Agradecemos sua cooperação.*

Re: qmail-remote crashed. [ In reply to ]

amb-sendok-1553176689.kkadaiekigenoikdnkod at bradfo

Feb 19, 2019, 5:58 AM

Post #12 of 14 (4274 views)

Permalink

Thus said John Johnstone on Mon, 18 Feb 2019 15:05:52 -0500:

> As many have often pointed out as well as John Simpson himself, having
> a publicly facing mail server is a significant effort. At the time
> John's patch was maintained that was true and it's even more so today.
> Unless you are investing quite a bit of time with it, you'll be likely
> to have delivery problems at some point.

But we're not talking about delivery problems, we're talking about a
crashing qmail-remote---this should never happen. That fact that it
happens represents a bug that needs to be investigated and fixed. I know
the OP is likely just trying to get deliveries working again, but he
also needs to spend some time figuring out why qmail-remote is crashing
because this is a bug.

Andy
--
TAI64 timestamp: 400000005c6c0b95

Re: qmail-remote crashed. [ In reply to ]

amb-sendok-1553176851.cfonlggfilajgcoceffl at bradfo

Feb 19, 2019, 6:00 AM

Post #13 of 14 (4274 views)

Permalink

Thus said Rejaine Silveira Monteiro on Tue, 19 Feb 2019 09:48:38 -0300:

> 104.47.2.36_failed_after_I_sent_the_message./Remote_host_said:_451_4.7.500_Server_busy._Please_try_again_later_from_[a.b.c.d]._(AS77712315)_[DB5EUR01FT062.eop-EUR01.prod.protection.outlook.com]/
>
> at the moment I have more than 2 thousand messages in the queue giving
> this error ... I believe they are blocking the new IP address ... :(

It's a temporary rejection---it should clear up assuming it just
represents a throttling mechanism on their part. It does say that the
server is busy.

Andy
--
TAI64 timestamp: 400000005c6c0c38

Re: qmail-remote crashed. [ In reply to ]

rejaine at bhz

Feb 19, 2019, 6:32 AM

Post #14 of 14 (4274 views)

Permalink

hi

the * .pem files I was using had been copied from the previous server
(and was generated with the old openssl version)
when i created cert files again directly on new server, the crash
problem was solved. ;)

Em ter, 19 de fev de 2019 às 11:05, Andy Bradford
<amb-sendok-1553176689.kkadaiekigenoikdnkod@bradfords.org> escreveu:
>
> Thus said John Johnstone on Mon, 18 Feb 2019 15:05:52 -0500:
>
> > As many have often pointed out as well as John Simpson himself, having
> > a publicly facing mail server is a significant effort. At the time
> > John's patch was maintained that was true and it's even more so today.
> > Unless you are investing quite a bit of time with it, you'll be likely
> > to have delivery problems at some point.
>
> But we're not talking about delivery problems, we're talking about a
> crashing qmail-remote---this should never happen. That fact that it
> happens represents a bug that needs to be investigated and fixed. I know
> the OP is likely just trying to get deliveries working again, but he
> also needs to spend some time figuring out why qmail-remote is crashing
> because this is a bug.
>
> Andy
> --
> TAI64 timestamp: 400000005c6c0b95
>
>

--
*Esta mensagem pode conter informações confidenciais ou privilegiadas,
sendo seu sigilo protegido por lei. Se você não for o destinatário ou a
pessoa autorizada a receber esta mensagem, não pode usar, copiar ou
divulgar as informações nela contidas ou tomar qualquer ação baseada nessas
informações. Se você recebeu esta mensagem por engano, por favor avise
imediatamente ao remetente, respondendo o e-mail e em seguida apague-o.
Agradecemos sua cooperação.*