I’m running a test setup (currently 2.4.0.beta4) at home on a local mini-PC with Ubuntu 16.04 LTS. Installed it using the excellent 30 minutes install guide. It does have a FQDN. Sending out email via a mailbox at my ISP with SMTP on port 587 with plain authentication has been working fine for over a year.
I just realized that I did not get any email notifications for some time like “new version available”. Checking Admin > Emails > Skipped shows that everything gets a
550-Bad HELO: localhost.localdomain does not exist - Please see RFC 2821
Looking back in the mailbox this could have been started with 2.4.0.beta2. But it could also be some policy change at my ISP at about the same time (end July 2019). Not sure where to start. Where does this localhost.localdomain come from? During installation I only had to edit app.yml and this shows my FQDN correctly at DISCOURSE_HOSTNAME:
I had never heard of mailgun. Do you mean mailgun.com, “Transactional Email API Service”? To give you an idea of my knowledge level: I know vaguely what an API is, but I would not know how to use one. But I could try using SMTP to another mailbox at a different ISP. Will report here tomorrow.
@itsbhanusharma, @jtbayly Thanks! I just managed to sent a test message through mailgun. So the problem was some new policy at my ISP’s SMTP server. I might keep using mailgun.
I did some more research, because I cannot use mailgun for our production forum.
In the header of e-mails that come in via mailgun I still see:
Received: from localhost.localdomain
HELO is the first command in the SMTP dialog (source)
It should be something like
HELO discourse.mydomain.tld
Some SMTP servers like the Postfix have an option to check this against the IP-address of the client. localhost.localdomain resolves to the IP-address of the SMTP server, it is probably in its hosts file. It looks like ISP’s are enabling this in their battle against spammers.
It works with mailgun because mailgun does not execute this check. But it still is a “bad HELO”.
To compare, I sent out e-mail using an email client (Sylpheed) on the same system. This works, even with my ISP’s mailbox and it appears to use
HELO HL80L
HL80L is my local network name. That is still no FQDN, but at least it doesn’t appear as an obvious bogus to my ISP’s server.
So maybe this is something that needs to be improved. But disclaimer: I’m not an SMTP expert.
BTW I got it working again via the mailbox at my ISP by putting an MTA in between as relay. It is a Postfix based app on my NAS. This uses HELO mydomain.tld
I’m going to have a look if we broke something during the switch to Debian 10 or upgrade to Rails 6. In the meantime, setting DISCOURSE_SMTP_DOMAIN in app.yml should work. I guess we should default to the value of DISCOURSE_HOSTNAME if the SMTP domain isn’t set explicitly.
Thanks, @gerhard! DISCOURSE_SMTP_DOMAIN was not present in my app.yml but I took a deep breath, added it and yes, that does the trick. I can use my ISP’s mailbox again. On the receiving end I find in the header:
Received: from XXXXXXX.cable.dynamic.v4.ziggo.nl ([XX.XX.XX.X] helo=mydomain.tld)
by smtp7.mnd.mail.iss.as9143.net with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.90_1)
In the meantime I learned that both RFC 2821 and successor RFC 5321, section 4.1.4 state that:
An SMTP server MAY verify that the domain name argument in the EHLO command actually corresponds to the IP address of the client. However, if the verification fails, the server MUST NOT refuse to accept a message on that basis. Information captured in the verification attempt is for logging and tracing purposes. Note that this prohibition applies to the matching of the parameter to its IP address only; see Section 7.9 for a more extensive discussion of rejecting incoming connections or mail messages.
But many MTA’s like Postfix and Exim still seem to have an optional setting to do that. Possibly administrators are enabling that in the ongoing spam battle.
