transport-email unable to send to GMail recipient
-
@JamfoFL I definitely agree that it's a frustrating and confusing experience. It doesn't help that there's no bounce messages and the host doesn't provide any deliverability trace options.
I'll see if I can poke around so more and possibly reach out to them to figure out what the issue is. I haven't reached out to them yet as I've generally found them lacking but I haven't been able to find any good hosting recommendations. It seems everyone dislikes their host, or if they did happen to like them, the host ends up gobbled up by that group who's acquiring them all.
-
@CJ Cool. If you get anything useful from them, I'll be happy to look... even though I imagine with all your private info in it, it's probably not something you'll want to share. Fingers crossed they send you something useful and, when you look, you'll have that "A-ha!" moment that will finally make this all make some sense!
-
@JamfoFL After a bunch of back and forth with tech support they said that the emails are getting sent to /dev/null and they have no idea why. Now I have to wait for more senior techs to investigate and attempt to figure out the issue.
-
@CJ Yeesh... I have my fingers and toes crossed that they can figure out what is going on for you, or at least give us more info for a place to look!
-
@JamfoFL It turns out that the issue is because XCP-ng sends HELO 127.0.0.1 and the SMTP server considers that suspicious and spammy. Therefore the email gets dropped.
TrueNAS appears to use a HELO of the server name, which is apparently acceptable to the SMTP server. Which is odd as support wanted me to use a HELO of the actual SMTP server.
-
Is there anything we can do on our side?
-
@CJ @olivierlambert Looking at the RFC, the SMTP HELO command needs to be followed by a domain name, not an IP address.
Testing my XO (source) install, it does send the host/domain name of the XO machine in the HELO message and not 127.0.0.1. So the the question is, why is your install sending 127.0.0.1 or why is the SMTP server seeing that in the HELO message.
I also test XCP-ng (which uses
ssmtp) and it also sent the name, not IP. -
@Andrew @olivierlambert If anyone can provide me with the proper place to look for logs, etc, I can attempt to determine what's going on. My XOA is a source install as well.
Also, now that I know what's causing the problem, I can use my own domain to review the test messages as they still work.
-
So if XO from sources it's NOT XOA
(XOA is only meant for the virtual appliance we deliver). I'll be curious to see if you have the same issue with XOA, that would help to rule out a XO-related issue 
-
@olivierlambert Sorry, didn't realize.
How can I test it in XOA? I don't have the transport-email plugin.
-
This post is deleted! -
@Andrew I think I figured out why it's happening. It looks like NodeMailer is getting the hostname and because mine isn't a FQDN then it sets the default hostname to 127.0.0.1
https://github.com/nodemailer/nodemailer/blob/master/lib/smtp-connection/index.js#L1788
Is your hostname a FQDN?
Apparently Debian thinks hostname should not return a FQDN. https://www.debian.org/doc/manuals/debian-reference/ch03.en.html#_the_hostname
-
@olivierlambert @Andrew That did it. If the hostname of the machine doesn't contain a . then NodeMailer sets it to 127.0.0.1 and therefore sends helo 127.0.0.1 when it connects to the SMTP server.
It looks like if a client name is passed to NodeMailer it skips this check, so would it be possible for XO to expose the field as an optional parameter?
-
Thanks for your feedback, let me add @julien-f in the convo
-
@CJ Which field would you want to be optional?
-
@julien-f The client hostname, although I don't know that that's really the best solution. This seems like a weird edge case that doesn't seem to affect most people.
Right now I've added the domain to my /etc/hostname file even though it's against Debian convention.
-
@CJ Please test the branch
email-local-hostnamewhich make the local hostname configurable and keep me posted.
