On Wed, Nov 23, 2016 at 09:55:33PM +1100, Sam Vaughan wrote: > > On 23 Nov. 2016, at 9:08 pm, Gilles Chehade <[email protected]> wrote: > > > > On Wed, Nov 23, 2016 at 01:53:22PM +1100, Sam Vaughan wrote: > >> Hi [email protected], > >> > > > > Hi, > > > > > >> I???ve been a very happy user of OpenSMTPD for some time now, but I > >> encountered a DNS issue today which seems to have caused mail to be lost. > >> > >> For some reason, the primary DNS server in the data centre I'm using > >> started replying to lookups with REFUSED last night. As a result, smtpd > >> couldn't resolve destination MX addresses and emails stopped getting > >> delivered. Many /var/log/maillog entries started appearing along the > >> lines of: > >> > >> smtp-out: routing: Failed to resolve MX for [blah]: Invalid domain name > >> smtp-out: session 0000000000000000: evpid=blah, status=PermFail, > >> from=<>, to=<[email protected]>, rcpt=<->, source=-, relay=bar.com, delay=0s, > >> stat=Invalid domain name > >> warn: queue: no return path! > >> > >> What surprised me about this situation was that smtpd seems to think it > >> successfully delivered all those messages. `smtpctl show queue` is empty > >> and there are no files sitting in /var/spool/smtpd, so as far as I can > >> tell the messages are gone. I was expecting to find them tucked away in a > >> directory somewhere waiting for something to be done about them. Is this > >> expected behaviour? > >> > > > > The "Invalid domain name" error will only happen when the MTA layer gets > > a DNS_EINVAL error which is considered unrecoverable in the sense that a > > similar query will result in a similar error. > > > > The question is, are there cases where error is considered unrecoverable > > when it really isn't the case ? > > > > I see two cases in the code where I'm unsure it's not getting this wrong > > so I'll check with eric@ what he thinks. > > > > > >> The other surprising thing to me was that the system's DNS lookups weren't > >> clever enough to ignore the server that was returning REFUSED and fall > >> back to the second DNS server listed in /etc/resolv.conf, which was still > >> working just fine. That's a question for a different list though. > >> > > > > That would be a side effect of a bug above. > > That's interesting. So it's the application's job to walk the list of DNS > servers and query them one by one? That would explain why nslookup on > OpenBSD and "drill??? on FreeBSD have different behaviour. nslookup stops > when the first server says REFUSED and returns the error. drill continues on > to another server and gets a valid response. > > >> OS and software versions: > >> > >> FreeBSD 10.3 > >> opensmtpd-5.7.3_2,1 > >> libasr-1.0.2 > >> libevent2-2.0.22_1 > >> > > > > Thanks for the report, we'll get back to you shortly. > > Could you please open a ticket on our tracker with a copy of this mail ? > > Thanks Gilles, posted just now: > https://github.com/OpenSMTPD/OpenSMTPD/issues/742 >
Thanks, we're discussing the proper fix, we don't know yet if this needs a fix in libasr or in opensmtpd -- Gilles Chehade https://www.poolp.org @poolpOrg -- You received this mail because you are subscribed to [email protected] To unsubscribe, send a mail to: [email protected]
