Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 5 years ago.
Improve this question
I would like to write some integration tests which verify if user receive registration confirmation e-mails.
Ideally, for this purpose I would like:
Create temporary e-mail account.
Pass it in registration form.
Check if we receive e-mail.
Delete e-mail account.
Are there any disposable e-mail accounts which provides a simple API? I couldn't find any, but existing ones are fairly easy to parse/make requests (e.g. http://10minutemail.com/).
Is this sounds like a good idea? The alternative is use some gmail account and use tags for this purpose. However, dealing with msgs in spam folder, other folders, etc. sounds a bit more complicated.
you can test with your email from Gmail, just append +something to your email address:
myemail#gmail.com
you can have a test account that will deliver to your normal Gmail address:
myemail+testuser1#gmail.com
myemail+testusern#gmail.com
http://mailinator.com supports POP3.
Connect to the server via POP3 with any username and check e-mail.
I know this question is relatively old, but this fits your purposes quite well:
https://www.guerrillamail.com
Disposable email addresses
Emails are deleted after 60 minutes
Customizable temporary email address dashboard
I use it on the daily while testing emails or for signing up for services that I'll only use once, that require email verification.
I highly recommend it!
You may use special services for QA/QC engineers with API:
https://mailtrap.io
http://www.emailvoid.com
https://mailcatcher.me
https://mailsac.com
More you can read in article http://railsware.com/blog/2012/06/18/remove-qa-headache-while-testing-email-delivery/
If you're running on a linux machine it'll already have an email service running (username#localhost... eg root#localhost) which is kinda perfect for testing emailing scripts.
I don't know why you'd go to the trouble of automating this when it would be better to rather use dependency injection and create a mock-mailing class so you can adequately do integration testing - instead of the last stage of transmitting the email it simply writes the content to a file, a database, or just stays alive in the mock-object long enough it can be tested before it's garbage collected.
Related
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 9 years ago.
Improve this question
My server needs to send emails on the behalf of my client, and the client wants this email to at least appear to originate from them.
The easy way is to just spoof the From address. The hard way is to get the client's username and password, and actually send from that account.
My questions are:
Will spoofed email trigger spam filters? (In my test, Apple Mail did not think it was spam.)
Is this considered a bad practice, or unethical, or in any way frowned upon?
The emails are going out only to people who have specifically and explicitly requested the email, and it will likely be a small number of people (less than one per day). We are not sending out spam at all.
Because this is an important client, I don't want to do anything that would reflect negatively on them (or myself).
Thanks. Hope this isn't too subjective.
Email spoofing is not completely preventable, since the basic protocols from email exchange don't verify anything.
This might help you decide:
http://en.wikipedia.org/wiki/Email_spoofing
Which says historically:
In the early Internet, "legitimately spoofed" email was common. For example, a visiting user might use the local organization's SMTP server to send email from the user's foreign address. Since most servers were configured as "open relays", this was a common practice. As spam email became an annoying problem, these sorts of "legitimate" uses fell out of favor.
I would think it is acceptable as long as the message is spoofed to a return address you would like people to respond to.
However, it would be more standard and appropriate to use email/pass.
I suppose it depends on how difficult this would be in your situation, but if reasonably able, don't spoof.
You said:
The emails are going out only to people who have specifically and explicitly requested the email, and it will likely be a small number of people (less than one per day).
If the email contents have perhaps a small footnote, I don't think it would be terrible. I have seen similar things from many companies. It's your decision.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
I am interested to know the technical background of how this services can determine if my email reached the inbox or not(as this is the key servicethis providers offer). If I send an email to somebody wh uses Yahoo messenger or Gmail or maybe just an enterprise email address, what does the ISP have to do with that? Isn't the email filtered after it reached the Yahoo or Enterprise server, and than moved to Inbox or Junk or whatever other folder?
(full disclosure: I currently work for SendGrid as a web developer, so I have some insight but maybe not the low-level technical answers you're seeking)
From a slightly simplistic view, when we go through the SMTP process of delivering a message to an ISP/ESP, we generally know that the message has been "delivered" and we track it as such in your statistics. We also set up feedback loops (FBL's) with ISP's/ESP's which can ping back to us if a user flags a message as spam, which we then subtract from the "delivered" total.
How they route the message and make the decision to move it an Inbox or Junk folder is based on whatever criteria they have, and as far as I know, there is no FBL that can be set up to alert us to that fact.
We do, however, work very hard with our customers to teach them how to "warm up" an IP address for sending good, non-spammy messages, which builds up a "reputation" for an IP address (search google for "sender score"). Obviously the closer to 100% the better. We also have automated systems in place which may alert us if outgoing messages seem "spammy" and we'll put them on hold and alert you so you can make corrections. After all, our reputation is also on the line.
Hope that helps a little.
Well, if I recall correctly, SendGrid uses embedded images in the email and tracks if the image gets loaded as a way to determine if the target user read the email. This, of course, is fairly unreliable.
I certainly never allow my email client to automatically show images by default, so the image won't be requested and SendGrid won't be able to count this email as opened.
See these links for more details... now comes the RTFM! :)
http://docs.sendgrid.com/documentation/apps/click-tracking/
http://en.wikipedia.org/wiki/Email_tracking
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
Ok, I'm a bit confused with these mail protocols so I just have to ask.
I'm making an app for a very special use case we have at work. We have two e-mail servers sending mail to eachother (two seperate domains). The problem is that one of the servers is frequently moved (the server is in the field, and has to be mobile). When that server is moved, it can't be connected to our network and therefore mail cannot be sendt to this server.
What I'm making is an app that will be between our two e-mail servers, intercepting the e-mail trafic that goes between them and, if one of the servers cannot be reached, my app should store the e-mails in a buffer, so that when it detects that the e-mail server is back online, it can safely send the e-mails the other server did not recieve due to it being offline. The e-mails in the buffer should also be able to be sendt to an alternative e-mail so they can be acted upon immidietly should the recieving e-mail server be down for longer than normal...
So, I've figured out that I need to use the SMTP-protocoll to send e-mail, but what do I use to recieve them? All examples I've read so far in C# and Python are about connecting to an allready established POP3/Imap4 server and recieve mail from there, and I think setting up my own POP3/IMAP4 server for intercepting mail before sending it on is doing it the really hard way...
So how do i recieve/intercept e-mail without the use of POP3/IMAP4?
If I understand the question correctly you simply want to buffer your emails. You could be much better off either using a third party to act as a backup mail server or set up additional mail servers as lower priority servers to collect the mail should one of the servers not be reached. You can ask on ServerFault about setting something like this up. I can't see the real benefit of writing an app yourself.
If you do wish to write something yourself then you will most likely wish to write both an SMTP server and and SMTP client one to accept the emails and one to deliver the message.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
[Our website] is very dependent on being able to successfully send email to its members. We are currently having trouble reaching all our members, especially hotmail users.
What do you recommend we do to improve our sending of email?
We are sending heavily user customized emails. So a third party solution would need a good api
to support this.
Possible solutions:
Would sending email through the app
engine help for delivery rates?
Does returnpath help? http://www.returnpath.net/
Update:
Some good comments on how to improve and test our own email sending capabilities. Another option would be a third party solution.
We're sending updates on your networks activities, registration emails, new comment emails, new follower emails these type of things. Especially your networks activity is highly individual and problematic with most third party emailing solutions. Would need a very flexible email solution.
Are there sufficiently capable solutions out there?
We had a similar issue a while back.. You probably want to read up on Microsoft's Sender ID:
https://www.microsoft.com/mscorp/safety/technologies/senderid/default.mspx
and look at the link called "Sender ID SPF Record Submission Form".
Postmark and Sendgrid seem to offer a very decent api to use for sending email and improving deliverability. As a bonus stats are also handled by them.
1 ) using shared ip
2 ) sending more than 1000 email per hours may cause Spam
3 ) sending from root server without SMTP login may cause this problem
4 ) contents email has links from websites blocked from RBL ( Real Time Blacklist )
5 ) ...
I'd in general be pessimistic about the IP reputation of platform-as-a-service type offerings. Testing Google AppEngine is on my to-do list, but I've there's been much talk about Amazon EC2 presenting a real problem -- these products are not very efficient preventing use by spammers, and reputation is taking a hit.
As for the practical steps of setting up outbound email, Jeff Atwood has a very nice and nearly comprehensive article on his blog.
What I'd certainly suggest is:
Make sure your sending IP has a reverse DNS.
Check your IP reputation for example at senderscore.org (though that's heavily US centric)
Make sure bounces are handled on your side, and postmaster#your.domain is reachable
Set up SPF and DKIM. SenderID if you want to.
Sign up for all feedback loops at major mailbox providers / ISPs and act on spam complaints -- if your user complain, you're doing something wrong. Also, set a "friendly name" on your From: address, as some mailboxes will only display the local part -- " Update" is friendlier than only seeing "automatic" (Gmail does this).
Watch the volume you send. If it's high from the start (>1000s/day to each major ISP) you may get blocked outright.
You'll find a lot of deliverability tips, most of the time from interested parties (email service providers). A relatively reputable resource is deliverability.com, backed in part by Return Path. Of course, going with a commercial email service provider might be a solution for you, but your use case is quite specific and you'll need real-time individual messaging, not marketing newsletters, if I understand you right.
I worked for a company that re-sold Return Path's tool -- so take this with a pinch of salt: It' won't help you get delivered. It can, however, be a valuable tool tracking down where your problems are. It is on the other hand expensive, and hiring a specialist that can go through your specific case might be more affordable. Or reading a lot and experimenting a lot yourself.
#chryss does a great job pointing out the important factors that need to be taken into consideration:
-- reverse DNS, sender reputation, list management (ie, cleaning lists of addresses who have marked your email spam, invalid addresses, etc and keeping track of hard and soft bounces and acting accordingly to those events), SPF records, DKIM signatures, ISP feedback loops, ISP rate limits. Also, email content is important to keep in mind.
Generally speaking, this is all pretty complicated and annoying stuff to deal with, especially as your email volume increases.
In terms of IP reputation with PaaS systems, the key thing to remember is this:
-- if you share an IP with someone who earns a poor reputation (say, a spammer on EC2), that reputation will negatively affect your deliverability. On the other hand, if you send from a dedicated IP, you have the opportunity to earn your own reputation - if you are a good sender, follow best practices, and your customers want the emails they expect to receive from you (which they should since it sounds like you are sending mostly transactional emails), you will maintain a great reputation and should enjoy good deliverability (granted all of the technical stuff mentioned above is taken care of).
We generally keep an eye on deliverability "chatter" online, and send out all the cool/useful stuff that we find on a daily basis through our twitter feed -- feel free to follow us: twitter.com/sendgrid. We are also beginning to ramp up our own blogging, so you can join the conversation if you like: blog.sendgrid.com.
If you want a comprehensive solution without having to do a lot of troubleshooting/fact-finding, just check out SendForensics.com. Disclaimer: I am affiliated with the company.
Regards,
Russ
Deliverability issues generally happen if there is something wrong with any or all of the following elements:
Email Content
Server Configuration
Email address and Domain reputation
IP address reputation
More information here
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Closed 4 years ago.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Improve this question
My VPS provider (Slicehost) doesn't provide an SMTP server. I use Google Apps to send and receive mail for my domains, but I want to be able to programmatically send e-mail.
I've been Googling this issue on and off for many months, and I just can't seem to get a clear picture of what I need to do. Do I just need an MTA like postfix? Do I configure it as a "satellite", or an "internet" site? Do I need to make any DNS changes? If I want to programmatically receive e-mail someday, are there any configuration options I should be careful about tinkering with? Also, if my VPS host did provide an SMTP server, what wouldn't I need to do, that I'm doing now?
Thank you!
Edit: A quick synopsis of my findings:
Update /etc/hosts and /etc/hostname to reflect the FQDN (for example, mail.domain.com or sub.domain.com instead of slicename)
Reboot and verify with hostname -f
Set up reverse DNS (which is owned by whoever owns the IP pool) to point at the same FQDN
Check that the RDNS has propogated with dig -x server.ip.address
sudo aptitude install postfix telnet mailx
Use internet site setting
Set FQDN to whatever was chosen above
Test with mail whateveryouremailis#gmail.com
Have you looked here, seems to me that there is plenty of information to get started. I found mail-server-slice-setup to be quite informative.
To my experience, when email providers check for spams, they check 5 main things other than content:
(When I say domain, I'm referring to the domain of the sender's email address.)
"A" record (IP) of the domain name exists
MX records of the domain name exist
PTR record (Reverse lookup) of the sender's IP address exists (Sometimes, I think it is also checked to see if the PTR record has the same A record as the original domain)
SPF record of that domain matches the IP number (This is a list of IP numbers allowed to send emails of that domain. Although this would be a great solution for spam filtering, this is not an official record, so it is not always checked. Check out the SPF setup wizard.)
The IP segment of the server is not a blacklisted segment.
The fifth one is the one that was a problem for me. Apparently email providers such as Hotmail, Gmail, Yahoo drop all incoming email from widely used server providers such as Amazon EC2. In that case, there's simply no way to guarantee the delivery of all outgoing emails, so you would have to relay all outgoing email from some other SMTP server outside the blacklisted segment. The easiest way to do this is configuring Postfix (or whatever MTA you're using) to automatically relay all emails. You can find plenty of articles on this if you do some googling.
If that is not the case, then all you need is a simple MTA like Postfix, as long as all the necessary DNS records listed above are configured properly, you should have no trouble sending emails.
Other answers have provided information about the mechanics of sending email, but one thing you need to consider is what sender address you're going to use, and how you're going to deal with bounce messages.
Let's say you're sending emails from sender#example.com; then (as Murat Ayfer noted) you need to make sure that your host is allowed to send mail according to example.com's SPF record. (This may or may not be configured by IP address -- see the SPF site for more details.) If you're in charge of the example.com domain, then this shouldn't be a problem. Being listed as an acceptable sender for the domain is an important step towards your emails getting through.
The next thing you need to worry about is how to deal with bounced emails. If some other host receives emails for example.com (i.e. the MX record points elsewhere), then it's mainly someone else's problem. (Note however that your application has to be prepared for a failure during the SMTP session to the mailserver on your host, due to syntactically invalid email addresses, for example.) But if you decide that you'll receive mail for example.com on your host, then you need to worry about dealing with retry messages, bounce messages, double bounce messages, and a whole lot of other general mail server administration. There's some info on handling undelivered emails in web applications which might be helpful, but I also suggest getting a good book on Postfix or whatever mail server you decide to use.
Just install something like postfix as "internet site" and you'll be able to send mails directly from your VPS
it should work with default settings but it would be recommended to also read a few docs/how-to's to secure it properly