A rails application in production should use smtp or sendmail to send mails?
SMTP is the protocol that is used by nearly all Internet hosts to send mail. This protocol is spoken by sendmail. Sendmail determines where to send your message and how.
Some mail programs (most, today) will connect directly to a mail server and speak SMTP to it. However, the "traditional" method - and arguable the better method - is to let sendmail do it.
There are two reasons for this: 1) nearly every program in UNIX that does what sendmail does is designed to be a drop-in replacement (this includes Postfix and Exim for instance); and 2) sendmail or its replacement was designed to handle mail and nothing else - by using sendmail you don't have to design a SMTP client.
The Mutt email client for UNIX is one email client that still refuses to talk SMTP directly to a mail server; a good (technical) description is on the wiki.
If you have a choice (on UNIX anyway) of talking SMTP directly or using sendmail, use sendmail - especially on servers.
As NDP already mentioned, they both work fine - that is, if your volume of messages doesn't exceed a certain amount.
For example, if your application can talk SMTP to either the local SMTP server (on IP 127.0.0.1, Port 25) or a server in the same subnet (i.e., over a low-latency link), and that server does not use any content filters before it queues a message, you will usually be able to submit a lot more mails over SMTP in a shorter time.
A useful link for Postfix may be General Mail Delivery Performance Tips - note the quote saying
Submit mail via SMTP instead of /usr/sbin/sendmail.
However, on modern hardware, if you don't plan to submit more than about 10 messages per second, you shouldn't notice any real difference.
Your question is incorrect - SMTP stands for Simple Mail Transfer Protocol whereas sendmail is the software piece to send the mail using this protocol.
Use sendmail.
They both will work fine. Action Mailer supports both.
I have used SMTP on several projects successfully. My sense was that this was a little more "standard", but I may be wrong.
I haven't used sendmail. My concern would be that it may be harder to set up in a development environment if you aren't developing directly on Unix/Linux. Where you can talk directly to any SMTP server -- even a remote one, -- you would have to install sendmail on the rails machine to get it to work.
The main problem I run into with email is sending messages asynchronously. Without a local SMTP server, a local sendmail instance is going to be more performant.
Either way, it looks pretty easy to switch if you decide you picked wrong.
Related
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.
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.
I have built several applications in delphi using the indy components suite(version 10.5.2 i think) and they all are working. I have just finished setting up the POP3server and it works locally. I can see mail sent locally on there. I have been using "localhost" as my hostname. However, i want to graduate to a higher level of function. I want to be able to receive email from the internet such from msn, gmail, yahoo ... The problem is I don't know how to do this. What address should I be using inorder to do this? So far "myhouse#localhost" has been working but only internally; can't seem to get external mail in there. Is it possible to receive mail like this? Thanks.
You need to register a domain, and then setup its DNS records (in particular, its MX records) to point to your server machine. That way, when an email is destined for any "#yourdomain" address by any sending service, it will be routed to your server machine (which needs to run an SMTP server to receive emails - POP3 is for downloading emails from your mailbox, not for putting emails into it). If your server does not have a static IP, then you need to use a service like DynDNS to mange the DNS records for you so they can account for your dynamic IP whenever it changes.
"The Internet" doesn't use POP3 to send and receive email, it uses SMTP. Here's how email "flows" from the sending computer to the receiving computer:
Server needs to send email to address: myhome#localhost. The first thing it does is isolate the server name, that's the part after "#". Next it uses DNS to lookup the SERVER IP for the computer that's supposed to receive email for the given domain. DNS contains a special record for this purpose, it's called the "MX" record. You can use command line tools like dig on Linux or nslookup on Windows to find this address, or you can use an online tool like the one found at http://www.mxtoolbox.com/ (google found this site, I assume there are many others!).
If you try to locate the MX record for your "localhost" domain you'll obviously discover it's not possible, because it's not a fully-qualified name. You first need to get yourself an domain name, so you can register a MX record!
Things you need in order to RECEIVE email
Need an "real" IP address. Servers outside your local network need to contact your server, and they obviously need a way to do it. Make sure no routers along the way block SMTP ports.
You need to register an domain name, add a MX record and point it to your "real" IP address.
Need to run SMTP server software on your box. You can use Indy components to write one.
Things you need in order to SEND email
Theoretically sending email with SMTP is the easy part. You just contact the responsible server using SMTP and send email, that's the way the protocol works: any computer in the world may send email to any SMTP server.
Practically sending email is the most difficult thing you'd have to do, mostly because foreign SMTP servers don't trust you (ever heard of SPAM?). Here are some of the things you might need to do so foreign SMTP servers accept email from you. There's no definitive list because the protocol itself doesn't include a clear authentication mechanism, so every big SMTP server out there uses it's own heuristics to decide rather to accept email from you or not. You'll find yahoo especially fun!
You need to have REVERSE DNS for the IP you're using to send email.
You need to send from one of the SMTP servers listed in DNS as your MX servers.
Your DNS records need to have long TTL (this rules out Dynamic DNS services)
Many other things...
What people usually do?
eMail is hard, there's a surprisingly small number of full SMTP servers available for your own server: Exchange, Notes, Postfix, QMail, Sendmail. They're all notoriously difficult to configure. Most people would use hosted mail services, some people would use the SMTP services provided by the ISP, and very few would install one of the mentioned services.
If you really want to write your own SMTP server go ahead, but you might want to install one of the ready-made ones before, to get a bit of eMail and DNS experience. The Linux ones are cheap to install and may also help with development (you don't want to send too much bad email to your free yahoo address, you might get blacklisted!)
POP3 is a protocol to read email from a mailbox. The TidPOP3Server component implements a POP3 server (and AFAIK it has no host property to set...), while TidPOP3 implements a POP3 client. To read mail from GMail or any POP3 server you need a TidPOP3 component. The hostname to set is the DNS name the service instructs you to use (i.e. pop3.mydomain.com).
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...
How would i go about to receive mails in a Ruby on Rails application without going through a mail server like PostFix or to fetch them by pop3 etc.
What i was to do is to catch all mails sent to #mydomain.com and just do something with them in my application. I don't need to store the mails or anything like that.
Is this posible?
I just implemented this for my SAAS to autoprocess mailer-bounce notification messages.
Call me, call you?
You call me
You can set up a local mail server. It would then respond to an incoming email, and start up a rails executable to process the email. This method is NOT recommended since starting up rails is a big task (takes multiple secs and lots of memory). You don't want a Rails bad boy started up just because you received an email. You'd be writing your own DDOS attack. (Attacking yourself.)
I call you
Instead, poll for email on your own schedule by using a single job to process all currently waiting emails. You need to set up a background job handler since stock rails is focused on responding to web requests. I use delayed_job, but there are other alternatives including kicking off a cron job every so in often.
Another benefit is that you don't need to manage a mail server. Leave that headache to someone else. Then use the Ruby library net::imap to read the incoming mail and process it.
If your process doesn't recognize the email format, then forward the msg to a human for processing.
And be sure that if the process sends mail in addition to reading/processing it, that the process uses a different email address as its From address. Otherwise, odds are good that sometime along the way, you'll end up in an email loop and many gigabytes of messages going back and forth. For example, your process receives a message, responds to it, but in the meantime the sender (a human) has switched on vacation response. And your robot then responds to the vacation response..... oops....
Writing your own mail server
Re:
How would i go about to receive mails in a Ruby on Rails application without going through a mail server like PostFix or to fetch them by pop3 etc.
What i was to do is to catch all mails sent to #mydomain.com and just do something with them in my application. I don't need to store the mails or anything like that.
Direct answer: Yes, you could do this by writing an smtp server and setting up dns so your machine will be the mail destination for the domain. Your smtp server would process the messages on the fly, they would not be stored on your system at any point.
Is this a good idea? No, not at all. While appearances may be to the contrary, email is a store and forward system. Trying to avoid storing the messages before your app processes them is not smart. It would be a very very poor "optimization." However, using an access protocol (POP3 or IMAP) is a good way to avoid the costs of installing, configuring and managing a mail server.
You can do this if you write your own mail server, or if your mail server supports hooks to run external programs upon receipt of mail (e.g. procmail).
If you don't have procmail available (or, if on something like Exchange Server, don't feel like writing custom rules or extensions), you're simply better off using a pop3 library to fetch mail.
Obviously, writing a mail server is more difficult than any of the alternatives.
If you're mostly worried about checking potentially hundreds of email accounts, that's solvable by configuring your email server properly. If you're on a hosted provider, ask your server administrator about creating a "catch-all" account that routes all mail to unknown addresses to a single account.
If you're aiming to avoid having to poll a server, consider the IMAP IDLE command. I've successfully written a Ruby client that opens a connection to an IMAP server, and gets told by the server when new mail arrives.