Rails Mailer Net :: SMTPServerBusy

Question

With my rails site, when I try to send mail via GMail, it works fine. But when I try to send it through MandrillApp, it gives the following error (RController.create is when the delivery command is called):

Net::SMTPServerBusy in RController#create 454 4.7.1 < [e-mail] >: Relay access denied 

Here is my config / environment / development.rb file:

  # ActionMailer Config config.action_mailer.default_url_options = { :host => 'localhost:3000' } config.action_mailer.delivery_method = :smtp config.action_mailer.default :charset => "utf-8" config.action_mailer.perform_deliveries = true config.action_mailer.raise_delivery_errors = true config.action_mailer.delivery_method = :smtp # config.action_mailer.smtp_settings = { # :address => "smtp.gmail.com", # :port => 587, # :domain => 'gmail.com', # :user_name => ' [e-mail] ', # :password => 'password', # :authentication => 'plain', # :enable_starttls_auto => true } config.action_mailer.smtp_settings = { :address => "smtp.mandrillapp.com", :port => 587, :user_name => ENV["EMAIL"], :password => ENV["PASSWORD"] } 

As it is above, the code does not work - I do not receive a letter and no errors appear. If I switch to sending it from GMail, I receive an email almost instantly. I have never worked with Mandrill before, so any help would be appreciated.

Answer 1

I ended up talking with a service representative from Mandrill, and it turned out that I used the actual lines instead of environment variables, so I just had to remove the "ENV" from the configuration file.

In the end, I came back and made environment variables for the sake of security, but I just thought that I would drop it there if someone else would have the same problem and find this question.

Answer 2

You tried to see the following Mandrill SMTP Integration setup. Hope this helps.

Answer 3

You can also check if ENV variables are set first.

Answer 4

If you are using Heroku, you need to set the environment variables in the CLI.

cd to your working directory and ...

 heroku config:set MANDRILL_USERNAME='YOUR USERNAME' heroku config:set MANDRILL_APIKEY="YOUR API KEY" 

Now you can access the environment variables. I know that you work with development.rb, but it can save you a headache when you get to production.rb. I had a headache for several hours with my application.yml file.

Answer 5

I have a suspicion that your problem is caused by Phusion Passenger (therefore, in production). The passenger is known for not setting environment variables.

This SO> problem offers two solutions: hardcoding values ​​or overriding the Ruby shell used by Passenger.

I would suggest a third option: expanding environment variables during deployment. This is pretty much delayed hardcoding, but leaves your passwords out of your code.

You should execute this bash bit immediately after deployment:

 mv config/environments/production.rb config/environments/production.before_sed.rb env | sed 's/[\%]/\\&/g;s/\([^=]*\)=\(.*\)/s%ENV\\[\\"\1\\"\\]%\2%/' > script/expand_env_vars.sed.script cat config/environments/production.before_sed.rb | sed -f script/expand_env_vars.sed.script > config/environments/production.rb 

Here is the equivalent task of deploying Capistrano (many shoots ahead!):

 desc "Replace environment variables with hardcoded values in config files" task :replace_env_vars, roles: :app do run "mv #{release_path}/config/environments/production.rb #{release_path}/config/environments/production.before_sed.rb" run 'env | sed \'s/[\%]/\\&/g;s/\([^=]*\)=\(.*\)/s%ENV\\\[\\\"\1\\\"\\\]%\\\"\2\\\"%/\' > ' + "#{release_path}/script/expand_env_vars.sed.script" run "cat #{release_path}/config/environments/production.before_sed.rb | sed -f #{release_path}/script/expand_env_vars.sed.script > #{release_path}/config/environments/production.rb" end after "deploy:update_code", "deploy:replace_env_vars" 

However, for Capistrano you do not have the same environment variables set in the SSH session that it uses for deployment (it does not execute .bashrc, / etc / profile ...). You must re-export them to ~/.ssh/environment and add the following parameter to /etc/ssh/sshd_config :

 PermitUserEnvironment yes 

These latest instructions were found there . I personally documented my issue a bit on my new blog .

Hope this helps fix some security issues for you :)