Sending email using IP address as the domain?

(Arve Knudsen) #1

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.

Troubleshooting email on a new Discourse install
(Allen - Watchman Monitoring) #2

In on your forum’s admin - /admin/email/sent

(Arve Knudsen) #3

I can’t log into Discourse though, since I can’t receive the sign-up activation email.

(Jeff Atwood) #4

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: – 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.

(Arve Knudsen) #5

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.

(Arve Knudsen) #6

@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.

(Sam Saffron) #7

It should be all logged in your rails logs … see:


(Arve Knudsen) #8

Thanks @sam. However, the log doesn’t tell me what is going wrong, it only says Sent mail to I need to figure out what leads to this error at Mandrill: Illegal address syntax from unknown[] in MAIL command: <noreply@>.

I guess the issue is that the sender’s address is an IP ( 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 noreply@

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.

(Kane York) #9

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).in Discourse.

(Arve Knudsen) #10

Thanks, but I’m pretty sure this is no longer the problem since I adjusted Discourse’s address from the IP to 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.

(Jeff Atwood) #11

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.

(Arve Knudsen) #12

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.

(Jeff Atwood) #13

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),

(Arve Knudsen) #14

@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.

(Michael Downey) #15

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. :smile:

(Arve Knudsen) #16

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.

(Stephanie Daugherty) #17

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 noreply@ 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”.

Solved by:

  1. Create a admin user manually
  2. Go to Admin/Settings/Required and change Notification email to a working email.

Could possibly work by changing to noreply@[] 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 "noreply@" 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.

Related discussion:

(Jeff Atwood) #20

Possibly this has not come up enough to warrant engineering effort in my opinion.