ETIMEDOUT connect error using nodemailer in Nodejs Openshift application

Question

I'm facing some problems using the nodemailer module in my node.js single gear non-scalable application in Openshift. As the documentation suggested, I initialized the transporter object and used the sendMail function. A simplified version of my code is

var transporter = nodemailer.createTransport({
    service: 'Gmail',
    auth: {
        user: 'my.mail@gmail.com',
        pass: 'mypassword'
    }
});

var mail = {
    from: 'my.mail@gmail.com',
    to: 'test@mydomain.com',
    subject: 'Test mail',
    html: 'Test mail'
};

transporter.sendMail(mail, function(error, info) {
    if(error){
        console.log(error);
    }else{
        console.log(info);
    }
});

This code works correctly when I run it on my local machine, but when I try to execute it on the server I got an ETIMEDOUT error, as if the application couln't connect to the smtp server.

{ [Error: connect ETIMEDOUT] code: 'ETIMEDOUT', errno: 'ETIMEDOUT', syscall: 'connect' }

I've tried to increase the timeout connection parameter, but I got the same results.

var transporter = nodemailer.createTransport({
    service: 'Gmail',
    auth: {
        user: 'my.mail@gmail.com',
        pass: 'mypassword'
    },
    connectionTimeout: 5 * 60 * 1000, // 5 min
});

Is there any firewall or default Openshift settings or enviroment variable I'm missing?

Answer 1

I've to run a few more tests, but I think I figured out what the problem was. The authentication via username and password is a not-secure authentication method for Gmail. As written in the Nodemailer documentation

Even though Gmail is the fastest way to get started with sending emails, it is by no means a preferable solution unless you are using OAuth2 authentication. Gmail expects the user to be an actual user not a robot so it runs a lot of heuristics for every login attempt and blocks anything that looks suspicious to defend the user from account hijacking attempts. For example you might run into trouble if your server is in another geographical location – everything works in your dev machine but messages are blocked in production.

I upgraded my authorization method using XOAuth2, as well explained in this guide and now the mails are correctly sent.