I have noticed that incoming Passbolt forum digests are getting hung up on my server. I can’t quite nail it down, but this morning it’s a case of the hostname having no A records.
Last week it was coming through as .cloud and .org. Most of the time I was able to resolve the hostname manually and the issue was the message didn’t include the hostname. I am pretty sure this is coming from Passbolt.
I figured I would pass it on in case no one else had.
I can provide these at the moment…logs from my server. The domain in the message must be .org as it’s getting flagged.
I do recall last week that either domain (.org or .cloud) seemed to be resolving to the address when I checked manually from ultratools online. However, my server (which uses cloudflare) was not able to resolve the .org version. I ultimately concluded that the handshake was not include the hostname, as discourse was sending both version on and off over a day’s period. I considered whitelisting the ip address but decided against it.
Based on this, as I don’t know who the heck this is. The address is a residence:
Jun 10 10:22:49 mx postfix/postscreen[3729]: PASS OLD [72.52.80.54]:40265
Jun 10 10:22:57 mx postfix/smtpd[3730]: warning: hostname mx-out-01a.sjc3.discourse.org does not resolve to address 72.52.80.54: Temporary failure in name resolution
Jun 10 10:22:57 mx postfix/smtpd[3730]: connect from unknown[72.52.80.54]
Jun 10 10:22:58 mx postfix/smtpd[3730]: Anonymous TLS connection established from unknown[72.52.80.54]: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
Jun 10 10:22:58 mx postfix/smtpd[3730]: NOQUEUE: reject: RCPT from unknown[72.52.80.54]: 450 4.7.25 Client host rejected: cannot find your hostname, [72.52.80.54]; from=passbolt+verp-e781c285d74642f33a9498585cbd77e1@discoursemail.com to= proto=ESMTP helo=<mx-out-01a.sjc3.discourse.cloud>
Jun 10 10:22:58 mx postfix/smtpd[3730]: disconnect from unknown[72.52.80.54] ehlo=2 starttls=1 mail=1 rcpt=0/1 data=0/1 rset=1 quit=1 commands=6/8
These error logs began when I stopped receiving digests.
If I can assist further, please let me know. I am hesitant to let the message through.
@garrett@schleifer is asking: Do you have any more information for that? Maybe a timestamp? The published record has ip4:66.220.12.128/27 which includes that address, so the most likely reason is that they still had the old record cached.