These have been working for me for several days now. Not sure if something changed or not, but thought I'd mention it. These are the actual headers (with some stuff modified, and a couple initial lines removed), to give folks some idea of what the mail flow is like:
Code: Select all
From email@example.com Tue Feb 26 18:10:01 2019
Received: from qproxy4-pub.mail.unifiedlayer.com (qproxy4-pub.mail.unifiedlayer.com [22.214.171.124])
by mambo.koitsu.org (Postfix) with ESMTP id 30E8B4E7F0
for <XXX>; Tue, 26 Feb 2019 18:05:40 -0800 (PST)
Received: from cmgw11.unifiedlayer.com (unknown [10.9.0.11])
by qproxy4.mail.unifiedlayer.com (Postfix) with ESMTP id C2638A034F
for <XXX>; Tue, 26 Feb 2019 19:05:38 -0700 (MST)
Received: from box609.bluehost.com ([126.96.36.199])
by cmsmtp with ESMTP
id yobKgpppND8RpyobKgDPU1; Tue, 26 Feb 2019 19:05:38 -0700
Received: from [188.8.131.52] (port=35686 helo=gen.8bitalley.com)
by box609.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256)
for XXX; Tue, 26 Feb 2019 19:05:38 -0700
Date: Tue, 26 Feb 2019 19:04:02 -0700
Content-Type: text/plain; charset=UTF-8
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - box609.bluehost.com
X-AntiAbuse: Original Domain - koitsu.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - nesdev.com
X-Source-Sender: (gen.8bitalley.com) [184.108.40.206]:35686
Running full headers through a tool like this
sheds some light on the topology and possible causes. The topology currently is this:
1. gen.8bitalley.com (nesdev box) --> bluehost.com (who is a general web/hosting provider); could be a service/company/thing running on BlueHost
2. bluehost.com --> something I can't exactly figure out, maybe local mail parsing of some kind, or some TCP/SSL tunnel, I don't know.
3. Somehow at this point the mail makes it to unifiedlayer.com
4. unifiedlayer sends the mail along to another mail server they themselves run
5. That server then sends it out onto the Internet (in this case, my own server that I use to manage my own Email)
I have no idea what the relationship is between all these things, but no wonder there are problems. Things could go missing, flagged, whatever -- and nobody has any insights into why because there appear to be 2 "intermediate" parties/providers involved (BlueHost and UnifiedLayer). That said, using said tool, we find something interesting:
During step #5, the tool reports "Blacklisted". I was like, "what? Surely not my box". Nope, not mine, but rather UnitedLayer!
https://mxtoolbox.com/SuperTool.aspx?ac ... ailheaders
They seem to be on several major/key DNSBL lists, which means they have a history of sending out spam. It doesn't mean nesdev is sending out spam -- they aren't -- it means that one of those intermediary servers does. Anyone running a mail server on the Internet that does DNSBL lookups and sees the IP of UnitedLayer mail servers (220.127.116.11 in this particular case, but I imagine they have tons) could have their email flat out rejected (i.e. you never get a copy), or possibly accepted but scored as spam (i.e. the mail arrives but in your spam folder).
This is from a SORBS DNSBL lookup:
This is really not good, guys.
Finally: nesdev.com -- the sending domain -- has no SPF (TXT) records of what SMTP servers are authoritative for sending mail out on its behalf. This isn't the reason for the above, I assure you, but it is certainly complicating matters too. In fact, maybe it lacks SPF/TXT records *because* of this whole BlueHost->UL thing, I don't know.
Code: Select all
$ dig txt nesdev.com.
; <<>> DiG 9.12.3-P4 <<>> txt nesdev.com.
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31516
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: d8b654e3b3aafbb92633df695c7608e5370799386a39067d (good)
;; QUESTION SECTION:
;nesdev.com. IN TXT
;; AUTHORITY SECTION:
nesdev.com. 10735 IN SOA ns1.dreamhost.com. hostmaster.dreamhost.com. 2018091600 17404 1800 1814400 14400
;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Tue Feb 26 19:49:57 PST 2019
;; MSG SIZE rcvd: 131
Not bragging or egoing, I assure you, but Parodius did not work this way. When nesdev was hosted with me, the mail went directly from our box out onto the Internet. I ran a tight ship and did not use intermediary mail providers -- because all it takes is one customer
sending spam via such a place and suddenly that mail provider is blacklisted. There's a lot of good reasons I did everything directly.
I kinda wonder if the community would actually prefer to have the nesdev sites hosted back on something that isn't set up this way, i.e. done the "old way" (without ads too) and with reliable Email and so on. I could probably do that in a matter of days, though more likely weeks given my full-time job and so on. I just have a feeling WhoaMan is full-time swamped with his job, runs this as a hobby that "mostly works", but when it breaks/misbehaves/issues like this happen, it's hard to get them fixed (given the model/topology).