emails sent from production server end up in spam - ruby-on-rails

I use sendmail to send emails from my application. I always send the emails from SOME_NAME#MY_DOMAIN.com but they always endup in spam folder.
I know that I should do some stuff on the DNS side to make my emails be marked as non-spam, but I don't know what they are.
I am a newbie and this is my first time setting up a production server, a domain and everything else myself. I appreciate if someone helps me.

What sort of environment are you deploying to?
This frequently happens to applications deployed to cloud services, like Amazon or RackSpace. Their entire IP blocks are registered as spam at services like Spamhaus, which is a sensible precaution or else we'd be getting even more spam than usual. You should enter your server's IP address in that field to see if you're listed as a spammer.
If you are, you can request to Spamhaus that the block be lifted. Getting in touch with Amazon's support stuff also helps. Finally, you can get around the issue entirely by using a sendmail service of some sort -- Amazon SES is pretty good, and there's even a Gem out there that provides integration to Rails apps.

Related

A Docker IMAP server for repeat-testing INBOUND email? Reverse mailhog?

Woo-hoo! Thanks that we have mailhog for reliable Docker-based testing environments for outbound mail ... allowing us to easily debug mail-sending services without bothering production users ...
... but what about inbound emails?
On one of our sites, users can send an email to a designated support-address and their email will automagically be entered into a ticket system. (As you can well imagine, I am now tasked with replacing that system.) So, is(n't) there already a sort of "reverse mailhog" system, which would allow me to define an "incoming-mail server" which I could from time to time say "had just received thus-and-so message?"
Since this now seems to me to be "just as obvious a requirement as the one 'mailhog' so adroitly solved," I now ask the community – am I overlooking something wonderful that I literally don't yet know about? (Pretty-please tell me in your reply that the answer is 'yes.')

Are any HTTP log files saved on my system by default?

I have an application hosted on Amazon EC2 on a Ubuntu machine, written in Ruby (on Rails), deployed with Capistrano and running on Nginx.
Last friday one module of my application has crashed and nobody in the company noticed until this morning. We spent some money with Facebook and Google ads and received a few hundreds of visits, but nobody created an account due to this bug.
I wonder if this configuration is saving the HTTP requests and its bodies somewhere in a log file. But we didnt explicitly set it, so it would only happen if any of these technologies do it by default.
Do you know whether there is such log or not?
Nope, that wouldn't be anywhere in a usable form (I'm inferring you want to try to create the accounts from request bodies in log files). You'll have the requests themselves in your nginx logs, and the rails logs will contain more info about the request, but as a matter of security, by default, any sensitive information (e.g. passwords) would be scrubbed from them. You may still be able to get some info from them.
To answer your question a little more specifically, the usual place for these logs on your system would be:
/var/log/nginx/
/path/to/your/rails/app/log/production.log
On a separate note, I would recommend looking into an error reporting service like Honeybadger, Airbrake, Raygun, Appsignal, or others so that you don't have silent failures like this moving forward.

Rails: test mailgun on localhost

I have a Rails app running on Heroku that uses Mailgun to process incoming emails. I haven't been able to figure how I can debug my email processing locally (on localhost) instead of having to push everything up to heroku every time I make a change. (this is just a test app - I'm the only one using it)
Is it possible to work with Mailgun locally? If so, how do I go about it?
Thank you in advance
Mailgun gives you the option to store a message for later retrieval. If you configure it that way, you'll be able to fetch messages from development for processing without having to set up a publicly-accessible webhook for Mailgun to hit.
But I'm assuming you have production configured with an HTTP endpoint, and it's no fun to do things differently between environments. There are a few tools that will let you set up a public endpoint that routes to localhost:
ngrok, which I've used to good effect to test Twilio. You can set up a permanent subdomain so you don't have to constantly change your Mailgun configuration.
UltraHook, which I haven't personally used, but looks the same.
Localtunnel which looks easiest to start up, but like you get a different host at every boot.
If you have a permanent publicly-accessible server, you can also maintain your own tunnel.
mailgun provides a sandbox that you can use for localhost the only downside to this is that you have to add the test email to valid recipient.
using this gem might be another possible solution:
https://github.com/ryanb/letter_opener/ or https://github.com/fgrehm/letter_opener_web for more advanced features
follow installation from repo
mail will open in new tab

Basic Confusion about ActionMailer RoR

I'm fairly new to Ruby on Rails and actually entirely new to website mailing. In a lot of example tutorials I see a "from" object assigned to, for example, "new#example.com". When I setup the emailing functionality on a localhost the RoR command prompt says that everything finished fine even when I keep "new#example.com" as the from object. Can I actually mail from a localhost port? What would I have to put as my "from" address in order to actually send mail from the my local web application? Just a regular email I have? How would it be authenticated to ensure that the "from" address is actually the real address?
It seems a really fundamental concept and I understand all the model/view/controller actions that have to be done to make it work but I'm confused I guess as to how it actually works
In general the from field can be anything.
Some mail servers may take action if they think that you are claiming to be someone you are not, such as blocking mail or marking it as spam (via mechanisms such as DKIM or SPF). These are done at the domain level, ie the mail server tries to work out whether the server talking to it is allowed to send email claiming to be from #example.com.
Other mail servers mail just silently rewrite your from field if they know who you are, for example if you are talking to the gmail smtp servers and have authenticated as bob then the from field will be set to bob#gmail.com, unless it is already set to an email address gmail knows you own.
By default, in development rails doesn't try and send email at all. For it to send email you need to configure the deluvery_method, usually this involves either setting it to :sendmail (if you have an appropriately configured instance of sendmail running locally) or setting to :smtp and also providing details of an smtp server to use.

How to test sending emails from asp.net on development machine?

How do I accomplish this? The SMTP class throws error on dev machine about not finding an SMTP server. Is there a way to test sending emails on development machine?
Shawn,
Straight from my web.config:
<smtp deliveryMethod="SpecifiedPickupDirectory">
<network host="ignored" />
<specifiedPickupDirectory pickupDirectoryLocation="c:\email_c#" />
</smtp>
this works fine insofar as being able to review the 'emails' that get saved into the pickupDirectoryLocation directory.
Give it a try...
You can dump the files on disk, by configuring System.Net.Mail.SmtpClient to use a deliveryMethod of type SpecifiedPickupDirectory, I found an example on SO
I know this is an old thread, but I just stumbled upon this service:
http://mailtrap.io/
Which is friggin brilliant. It serves as a dummy SMTP server for your app, and doesn't actually send the emails, but allows you to easily view them in the browser (or via API).
It's killer.
There's a couple possible reasons for this.
1) Is your code configured to use local SMTP server during development and you've upgraded to windows 7? There's no longer a SMTP server available on your localhost. Find and download smtp4dev to allow your localhost to trap the sent Emails.
2) If you are using a remote SMTP server, check your windows firewall to confirm that you are allowed to send outgoing mail. If you are, then confirm that your machine/username has rights to send mail via that server. A quick telnet:25 to the server should let you know if your connection is refused or not.
Assuming by "test sending emails" you mean sending test emails instead of formal/unit testing, I like to use smtp4dev:
http://smtp4dev.codeplex.com/
As the page explains, it's a dummy SMTP server, basically intercepting your outgoing messages from your app, allowing you to examine those messages and make sure everything works as you expect. It's a Windows app, which hopefully isn't an issue if you're developing for ASP.NET.
I usually do this by creating a wrapper class for the SmtpClient, then mocking out the wrapper in my tests. This removes the actual mail client/server dependencies from my unit tests. The wrapper itself is relatively thin so I don't feel the need to create tests for it. Usually I do my integration level testing for things like this as exploratory tests in my staging environment. The staging environment typically uses a production mail server, but with "fake" data -- e.g., customer email addresses replaced with my own.
Having said that, I would expect the client to work without errors even on your development system unless your mail server is protected by a firewall or something that would prevent your dev system talking to it. Can you give more detail on what the error you are experiencing?
Without seeing the exception there's not much we can do. As long as the details on your dev machine are pointing to a proper smtp server and have the correct credentials then your code won't be the issue and you should look further down the chain. I had an exception of the target machine refusing the request despite everything else being right. After spending ages double and triple checking the credentials, sending from our server etc I tracked the bug down to McAfee blocking email port 25...

Resources