[sf-lug] Mail problems (or Firefox, or systemd,...)

[Rick Moen]

Quoting Ken Shaffer (kenshaffer80 at gmail.com):

> The big orange banner in evolution saying "Cannot resolve mail.comcast.net"
> nslookup saying (with both the explicit or default 127.0.0.53 nameserver)
> ** server can't find muil.comcast.net: NXDOMAIN
> (Now nslookup is working making me doubt my memory but
> ping still fails with:
> $ ping mail.comcast.net
> ping: mail.comcast.net: Name or service not known
> 
> Substitute pop3.mail.comcast and you get the same errors.

{applause}

See, _that_ is raw diagnostic data.  Let's imagine that your initial
post(s) had included that datum.  I'd have said:

   Huh!  How about if you do 'dig mail.comcast.net @8.8.8.8 +short'?
   If you don't have /usr/bin/dig around and don't care to install
   it, how about 'nslookup mail.comcast.net 8.8.8.8'?

I'll bet that you'd have said those correctly resolved the name.
(One reason why accurate notes are important:  I'm betting that 
you're very slightly misremembering what you saw at the time in 
your nslookup output.)

The point may be obvious, but ping is not a tool for checking DNS
functionality.  If DNS resolution is failing, then _obviously_ ping by
hostname is going to also fail, so that result tells you nothing.

I'm also going to stop here and praise the GNOME developers for adding
that orange diagnostic banner to Evolution.  It's rare that I get a
chance to say something nice about them, so it feels good.

(Michael prefers 'delv' the new and shiny over dig or nslookup.)

> Odd indeed. See launchpad bug 1804487.  

https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1804487

> Looks like a combination of an NXDOMAIN error resulting in a reduced
> function set UDP trigger, and mail.comcast.net 's big (greater than
> 512 bytes) causing a problem. (It's time dependent too, with the UDP
> fallback getting reset after a grace period.)

systemd-resolved implementation fault, as I said.

It's _way_ common in badly written DNS-handling software to fail to
correctly handle DNS data spread across more than one packet (thus over
512 bytes, requiring TCP transport rather than DNS's default UDP
transport).  systemd-resolved is badly written DNS-handling software.
Quod erat demonstrandum.

You're messing around with kludges recommended on ubuntuforums.org
(judging by recent posts) while, I gather, waiting for the 'bugfix' 
update.  OK, good luck on the bugfix treadmill.  Personally, when I find
out that a piece of software is fundamentally bad, I do my best to get
rid of it.


> Well, yeah , I am a home user, so my linksys router is my gateway
> 192.168.1.1,
> and my default network setup simply sets my nameserver to 192.168.1.1.
> For a real yuck, look at the output of systemd-resolve --status
> That the nameserver systemd-resolvd is using too!

As I said upthread, systemd-resolved, for all of its absurd
overcomplication and tentacles into everything, isn't even a real
nameserver daemon.  In that functionality area, all it does is cache,
ergo it outsources all queries to one or more real nameserver it
discovers or has in its internal list.  It picked up 192.168.1.1 from
your network environment (probably from information provided with the
DHCP lease), so it used that.


> Right, web based mail.  After my evolution mail failed, I checked
> it, and got the most unhelpful, "That didn't work, try again"
> Instead of something like "We need you to allow us to run scripts on your
> machine for this function."

See, if you had mentioned in your initial problem description that
_first_ you got the extremely helpful Evolution diagnostic you
mentioned, then cross-checked the same service (Comcast 'Xfinity' ISP
services) via Firefox to the webmail interface and got substantively the
same error, then your aspiring helpers would have seen right away that
it's 99.999% likely the cause is neiter Evolution nor your Web browser,
because the same bug popping up independently in both would be
astronically unlikely.  This would have pointed suspicion at system
software, which would have lead to systemd-resolved in very short order.

> Bit by the Poission distribution. Two random errors at once, confusing me a
> bit.

Au contraire, Monsieur Poisson.  That was your big clue that the fault
lay in _neither_ of those pieces of software, but rather at the system
(lower) level of network functionality.

(You say the 'Google problem' resolved to something mishandled by NoScript. 
Not sure how that relates to Comcast Xfinity mail stuff.)


> Chrome browser, not Chromium.

If you want a nice _open source_ browser, add Chromium to your
collection.  Google Chrome is proprietary software.  (I imagine
Netflix likes it for its DRM handcuffing of your esteemed self.)