Pedro, I will gladly and gratefully yield the speaking podium to you on that one.  I know I used xev back in the 1990s, but cannot remember offhand its uses and advantages.  (I recall that it is a general tool for sending X events to a window, to see what then ensues.)

Well, I hope one of the really knowledgeable desktop-computing people on this forum will help.  Yr. humble servant is basically a system administrator who has rather little to do with the X Windows System in any form, most days.

I do have a MacBook Air running Debian 9 'Stretch' in a virtual machine.  In that environment, right-Command-key clicking emulates right-click, which is a darned good thing because right-clicking is essential for the Window Maker environment.  You might be amused that I gravitate toward Window Maker because, in bygone days, I was a huge fan of NeXT, Inc.'s NeXTStep, a proprietary BSD Unix whose current offspring is Mac OSX.  Window Maker is an X11 window manager/desktop that's deliberately in the style of NeXTStep.

The Debian installation does NOT have an /etc/X11/Xorg.conf file, and instead relies (I guess) on Xorg hardware autoprobing and defaults.  I've not looked more deeply because it Just Works[tm], so I haven't poked around much.

Give that a try, anyway.  'Hope it helps.

Godt nyttår!

Feliz Año Nuevo!

!שנה אזרחית טובה

Bonne Annee!

(Forsinket nyttårshilsen fra California, hvor noen snakker norsk.  Vel, noen lærer norsk.)

snorkack (Fred), now that I've slept on this, and also having seen your explanation that what we're seeing is ISP follies from a firm paid to host your domain's e-mail and DNS, I think I can help more.

On reflection, point #4 I added as afterthought yesterday is the immediate reason for the 45x tempfails.

450 4.7.25 Client host rejected: cannot find your hostname, [65.49.128.26]

As I mentioned, '450' is a classic tempfail, i.e., delivery is being refused at the moment, but not definitively and the mail may be accepted later upon redelivery attempt.  These three-digit SMTP error codes were found (if I recall correctly) by the Internet Engineering Task Force to need further elaboration, so the N.NN.NN status codes like 4.7.25 were added.  4.7.25 is part of the "4.X.X " group of Persistent Transient Failure SMTP error status codes, but we don't even need to look up what it means because the full explanation is right next to that:  "cannot find your hostname, [65.49.128.26]"

Yesterday, I was slow to make the connection, but it's very literally saying your mail is being tempfailed because mail.dyne.org has the (reasonable) expectation that your hostname's DNS name (blakemfg.com) would resolve, but it doesn't.  65.49.128.26 is the IP address of the ISP host handling your mail.  There is a regular 'A'-type DNS record for mail.blakemfg.com, but not one for blakemfg.com itself.  This is a very peculiar but damaging administrative error on your ISP's part.  Let me explain why:

We're several decades into a war between spammers and sysadmins.  One big weapon we sysadmins have is enforcement of DNS and SMTP technical standards.  Spam characteristically ignores a bunch of those standards and just spews out poorly-compliant bitstreams to see who'll accept them.  Rejecting standards-ignoring mail is thus a highly effective antispam heuristic.  So, increasingly, mail-sending domains must be competently administered or they'll get doors slammed in their faces.  In this case, you got a gently closed door with a nice note saying 'Hey, you're welcome to try again but need to fix this problem.'  And what to fix was right there.

That leaves you with a potentially serious problem, because, frankly, all the DNS misconfigurations I mentioned[1] are things I'd fire (well, put on probation) a junior sysadmin for at any place that does e-mail and DNS for, y'know, a freakin' living.  You can certainly ask the ISP to fix those issues, but expecting them to suddenly find their mislaid competence just because you pointed out some abject failures at doing your DNS seems... optimistic.  Sure, try that if you wish, but then check that they fixed all the problems, and have a Plan B in case they keep screwing up because they just aren't good at the job.  Personally, I'd be treating them a bit like a sandwich shop that served me a meatball sandwich with a layer of dirt in it.

So, I'd be looking in the Yellow Pages under "ISPs that are not named Internet Operating Services of Arizona LLC". 

Also, as a Linux user generally and as domain owner, you may find getting to be really good at use of /usr/bin/dig and studying DNS administration really useful in keeping hosting companies honest and understanding what's going on.  There's a nice (and free-as-in-gratis) online book:  http://www.zytrax.com/books/dns/  (For one thing, consider:  Fluency with 'dig' will let you check up on your provider and make sure the current sorts of woes don't recur.)

[1] Except for the one where your mail server's forward resolution name (mail.blakemfg.com) doesn't match the reverse-DNS resolution of associated IP address 65.49.128.26.  (As mentioned, as a separate problem, they did omit a forward resolution DNS record for blakemfg.com.)  Your explanation makes clear that IP address 65.49.128.26 is a machine used for shared hosting.  The ISP probably virtual-hosts hundreds of customer domains from that IP.  Each customer domain forward-lookups to IP 65.49.128.26:  In DNS, you can have an arbitrarily large number of forward-lookup "A" records all pointing to the same IP -- but the IP can reverse-resolve to only a single fully qualified domain name (FQDN).  In this case, they've understandably chosen to have it resolve to the ISP's own FQDN,
mail.iosaz.net. 

Fortunately, to my knowledge, even the most militantly antispam SMTP servers don't require forward/reverse exact match, albeit many insist that the delivering IP reverse-resolve to something, or else will refuse mail from that IP.  (And your IP does reverse-resolve to something.)

Fred, as a disclaimer, I'm unfortunately not a lists.dyne.org admin, and in particular have no access to its SMTP logs, which would be handy in this case.  So, I don't speak for administration, and have no insight into host configuration.  However, I'm a sysadmin (and DNS admin) elsewhere, so may be able to help.

I infer that lists.dyne.org (IP 195.169.149.119) was, as of the time of that delivery attempt, tempfailing your delivery attempt (thus the 450 SMTP error code -- 45x being temporary failures and 55x being permanent) because your sending domain's DNS is dysfunctional.  Observe:

$ dig -t ns blakemfg.com
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 29626
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0

;; ANSWER SECTION:
blakemfg.com.           3600    IN      NS      ns2.iosaz.net.
blakemfg.com.           3600    IN      NS      ns1.iosaz.net.
$

See the "AUTHORITY: 0"?  That's because ns2.iosaz.net and ns1.iosaz.net are not declared authoritative in your registrar records (which results in them being listed as NS records for your blakemfg.com domain in the parent .com zone).  Instead, the parent zone lists your authoritative nameservers as ns1.aspect1.net and ns2.aspect1.net.  Rule of thumb:  Always change in unison the in-zone NS lines and the parent-zone NS lines.  They must always match.

While I'm at it, a couple of other comments:

1.  The EXPIRE value in your SOA record is out of spec (too low).  You have 604800 seconds.   RFC1912 suggests a value between 1209600 and 2419200.

2.  It's contrary to your interests (helps probing your software) to allow your nameservers to give accurate answers to the CHAOS class bind.version query.

$ dig -c CHAOS -t txt version.bind @ns1.iosaz.net +short
"9.8.2rc1-RedHat-9.8.2-0.23.rc1.el6_5.1"
$

 
Since you're running BIND9 ;-> , I can suggest a conf file snippet to make it give your preferred answer queries for the version.bind synthetic hostname (using my own linuxmafia.com server as an example).  My own preferred answer is to use the Leslie Nielsen joke from 'Airplane!':

options {
        directory "/var/cache/bind";
        version     "Shirley, you're joking";
        hostname    "ns1.linuxmafia.com";
        //server-id is essentially redundant to hostname, default is none
        //server-id  none;
       // [omit other lines from this section]
};

3.  It is slightly problematic that your mail server's forward resolution name (mail.blakemfg.com) doesn't match the reverse-DNS resolution of the resulting IP address (65.49.128.26):

$ dig -t mx blakemfg.com +short
10 mail.blakemfg.com.
$ dig -t a mail.blakemfg.com +short
65.49.128.26
$ dig -x 65.49.128.26 +short
mail.iosaz.net.
$ 

To my knowledge, no RFC requirement so far requires a forward/reverse match (called 'forward-confirmed reverse DNS'), but in these days of twitchy spam-rejecting heuristics, it's in your interest to follow best practices or domains may treat your mail suspiciously or reject it.

Edited to add:

4.  Is there a particular reason why there is no 'A' record at all for FQDN 'blakemfg.com'?  That's a little wacky, and some accepting SMTP systems may choke on that, too.