How can I see Discourse’s log about its sending of emails? Mandrill isn’t receiving any from my newly launched instance and DO say the droplet isn’t blocking either.
In on your forum’s admin -
I can’t log into Discourse though, since I can’t receive the sign-up activation email.
You’ll need to create the admin account at the command line then.
I can set up Mandrill for you if you sign up for the $99 one-time install, and that’s 100% guaranteed to work: http://discourse.org/buy – it’s also kind of a great deal for the (secret, I cannot disclose) free tier we have a special reseller coupon for. Mandrill offers zero free tier as of a few months ago, except for special resellers like us.
Thanks, wasn’t aware of the CLI option for creating an admin account. I’m checking with Mandrill as to why the emails aren’t received.
@codinghorror Now that I am able to log in, I can see this SMTP error ‘Bad sender address syntax’. I can’t see that it reoccurs though, even though I’ve tried sending activation mails several times after.
Also, is it possible to configure Discourse to log its sending mail over SMTP? If I could see what Discourse is doing wrt. SMTP in detail, maybe I could figure out what’s going on. Mandrill are asking for more information as well.
It should be all logged in your rails logs … see:
Thanks @sam. However, the log doesn’t tell me what is going wrong, it only says
Sent mail to email@example.com. I need to figure out what leads to this error at Mandrill:
Illegal address syntax from unknown[220.127.116.11] in MAIL command: <firstname.lastname@example.org>.
I guess the issue is that the sender’s address is an IP (18.104.22.168). I’ve tried changing the setting
notification email, but the email still goes undelivered even though I have no way of telling if the email from address is still email@example.com.
Bottom line: Is it possible to enable more verbose logging of the sending of mail? Mandrill are specifically requesting logging of the SMTP response (from Mandrill), since they’re not logging the whole SMTP conversation themselves and can’t pinpoint the error.
Basically, you’ll need to buy a DNS name for this to work. Delivering mail to an IP address was never supposed to work
(and I do mean literally never, in the history of SMTP, to my knowledge)..
Thanks, but I’m pretty sure this is no longer the problem since I adjusted Discourse’s address from the IP to test.forums.muzhack.com. Mandrill also say they no longer see the sender address error, which backs this up.
My problem right now is I am unable to effectively debug the sending of mails from Discourse, since there is so little logging.
As I mentioned, it’s unclear what exactly is wrong, but it is almost certainly something specific to your configuration. Buy a $99 install and I’ll get you set up on a (secret reseller) Mandrill free tier and everything will work perfectly.
How about whether it’s possible to increase Discourse’s granularity of logging regarding its sending of email to Mandrill though? Wouldn’t it be in Discourse’s best interest to figure out why integration with Mandrill is failing? I mean, even Mandrill can’t understand (from what they’re saying) why their system can’t accept the emails that Discourse is sending.
There is a limit to what we can troubleshoot without a customer relationship. We have no knowledge of systemic email problems for people following our guide, or hosted customers.
Every time I set Discourse up following our guide, meticulously step by step, email works fine. (We set up Mandrill for the one time install customers),
@codinghorror I totally get that. However, I don’t expect you to troubleshoot. I’m merely asking whether it’s possible to enable more logging of the SMTP interaction, eventually if I can add this myself to the source code.
I’ve set up a production instance of Disourse without problems before, the one I’m struggling with now is merely a test instance. I’d like to know why it won’t integrate with Mandrill though, so I’m able to solve this sort of problem especially if it should affect an instance that I actually depend on.
This is not true. IP addresses in the domain part of a message address are specified in & supported by RFC 2822. Just make sure they’re in square brackets. It looks like the mail @aknudsen was sending did not have the brackets. Now, OTOH, whether or not mail host operators support this standard is a question for them.
Suddenly I feel really old.
I think I found out what my problem was. My updated container settings weren’t taken into account, since I had to call
launcher rebuild app in order to accomplish this. I’d only been restarting the container, through
launcher restart app. I guess you learn something every day…
I still wish it’d have been easier to see which SMTP parameters Discourse were using though, as I could’ve pinpointed the issue way earlier.
In the specification, and actually supported are two different things. Best practices have been to reject such addresses since at least as far back as we started getting rid of open relays. IIRC SMTP source routing and hybrid uucp/internet paths are in the spec too, when was the last time we saw one of those?
I had this exact problem, and it was because I used the ip number as DISCOURSE_HOSTNAME before I had the domain set up. This does NOT work, at least not when hosted in Digital Ocean.
The reason is that the Notification email in (Admin/Settings/Required) gets set to firstname.lastname@example.org which (on some mailservers) results in the error: Job exception: 401 4.1.7 Bad sender address syntax
Ruby backtrace error messages: “block in deliver”.
- Create a admin user manually
- Go to Admin/Settings/Required and change Notification email to a working email.
Could possibly work by changing to email@example.com but untested.
Troubleshooting email on a new Discourse install
Amazon SES not working with Discourse new install
@codinghorror Perhaps the notification email verification needs to be improved to handle this? Even if "firstname.lastname@example.org" is a RFC valid email, if it doesn’t work on Digital Ocean you might want to give the admin a warning? Many like me who just want to quickly evaluate Discourse don’t want to set up a domain but just use the IP.
Possibly this has not come up enough to warrant engineering effort in my opinion.