[solved] Email is working in develop but not on the server

Quick question for you all:

I’ve added a simple “feedback” form to my app using the email package. When I run the app on my localhost, the form works and I get an actual email in my inbox when I follow it through. However, I keep getting the following error on my server output pointing at the Email.send() line when sending a message through that form:

Exception while invoking method 'sendFeedbackEmail' Error: connect ETIMEDOUT

I’m using the free-tier on a Mailgun account. On the server, calling export MAIL_URL=smtp://postmaster@[blah]:[blah]@smtp.mailgun.org:587 meteor doesn’t seem to have any effect. I even hard-coded the MAIL_URL variable like so:

if (Meteor.isServer) {
    process.env.MAIL_URL = "smtp://postmaster@[blah]:[blah]@smtp.mailgun.org:587";
}

Still, this works on development but not once it’s live. Any ideas on how to fix this?

PS:
For context, the code I use to send it is simple:

if (Meteor.isServer) {
Meteor.methods({
    sendFeedbackEmail: function(message) {
        check(message, {
            senderName: String,
            senderEmail: String,
            body: String
        });

        var emailText =  "senderName: " + message.senderName +
            " | senderEmail: " + message.senderEmail +
            " | message body: " + message.body

        Email.send({
            to: "my_email@gmail.com",
            from: "feedback@smtp.mailgun.org",
            subject: "[Site feedback]",
            text: emailText
        });
    }
})
}

and how you call that export?
deploying using mupx and configuring it into mupx config file, or what is your deploy setup ?

Do you have any outgoing rules on your server?

@shock
It’s fairly janky - I have it running on a Google Compute Engine instance so I upload the code manually to it. I don’t know a lot about servers (like, at all… :O) so I’ve tried it a few different ways, including typing that export command on the shell where the app is running (starting and stopping the app in between). Does it matter what directory of the shell I’m in when I call export?

well, that export is only active on that exact shell instance you executed it.
normally we added all exports to .bashrc or some other shell init script in good old days
now mupx is taking care of it for me, so I did not played with it

it’s a port issue, see the following document

https://cloud.google.com/compute/docs/tutorials/sending-mail/

@garrilla erm, that might be the issue. I screenshotted the firewall rules I currently have on my server. Should I be allowing port 587 in addition, then?

Not sure if you did it but I needed to encode @ my username:

"env":
 {
   "MAIL_URL": "smtp://username%40mg.yourdomainexample.com:password@smtp.mailgun.org:465"
 }

Host: smtp.mailgun.org
Port: 2525

according to https://cloud.google.com/compute/docs/tutorials/sending-mail/using-mailgun

or add that 587

my reading of the document that i posted was that only “Google Apps customers can send email through ports 587 or 465 using their Google Apps domain” and “Note that SMTP relaying through Google Apps is only allowed through ports 465 or 587.”

so mailgun must go out on 2525

Yeah, it looks like I need to go through 2525 - seems like a whole lot of additional steps/installations though. I guess I thought the point of the email package was that Meteor would take care of that sort of tedious backend work? I tried adding an “allow” rule on my firewall to tcp:587, but it still isn’t sending.

At the moment I would rather get the app live than wrestle more with it, so I’ll just include a straight link to my email instead. Thanks anyway for all the input - I’ll update this thread once I get back to it.

Just use that export with :2525 at the end instead of 587.
I would expect that should do the trick
and enable 2525 in firewall to be sure

This is not a limitation in the email package but a constraint set by Google.

and then do what @shock suggests - the extra steps, to install postfix, should not be at all neccesary in this case.

Whoa, it worked! I did as suggested, made an “allow” port at tcp:2525 and changed the smtp url to port 2525. Thanks a bunch for the help!

2 Likes

Had the same issue here using Digital Ocean droplets. I solved the problem using port 2525 instead port 25 or 587