Scenario:
User gives you an email address. Before they can sign up for services, they need to validate the email address - you email out a URL, they click on it, then they can subscribe to the services.
Questions:
What does the URL look like? I'm thinking a random guid would be OK.
Do you use that same random key for unsubscribe requests?
Are there any good open source implementations of double-opt in I should be looking at?
I've used a random GUID before such purposes to verify email accounts, and it works well. Unless you are dealing with ultra-secure, ultra-sensitive data then it should suffice. I see no reason not to use the same GUID for unsubscribe requests - that way you just need to store one GUID per account that can be a lookup to your subscribers database (or however you store them). You could add the unsubscribe link to the bottom of all emails, making it a simple one-click option.
This is pretty simple to implement with a random string and a GET request. I probably wouldn't use the same for unsubscribe, because you know most people are going to lose the original email. Do it the same way -- they say they want to unsubscribe, and it does so, but also sends an email saying you've been unsubscribed in case it was an accident.
Edit: You wouldn't even need to ensure a unique string, since you'd pass in the email address too.
Related
I manage a voluntary group project that uses one gmail account for all of its interactions. Up til this year there were two users of the account. Now there are three, and we are looking at maybe three more. Madness! We are constantly chasing each other to see who will handle a given message. Would be so much better to route messages to specific accounts for a given person to deal with. But we still need to have a central archive for all incoming and outgoing messages.
I'm looking at the use of redirects, and am trying to 'frame' a broader concept of what to do, and then get a grip on whatever the necessary details are.
Here's what I think I'm trying to do. Some of it is not very clear!
Whether Gmail will work that way is what I don't know.
Set up a non-gmail domain, e.g. mymail.org.
Within that domain, create six accounts, like info#mymail.org, events#mymail.org, and so on.
Set up our existing gmail account to both send and receive mail addressed to each of those six accounts.
Have gmail redirect incoming messages based on the incoming address.
Have the replies to those messages look like they come from the incoming address. (So that further replies get routed correctly.)
Have a copy of each incoming and outgoing message stored on the one gmail account. This is crucial for recordkeeping or oversight.
Am I asking for something feasible? If not, what is?
Incidentally, I tried using the mymail+bit#gmail.com method of routing for a while. Didn't help much.
You might want to look into Google workspace. I think they must have something along the lines of what you are looking for.
My company is developing a cloud contact management service and on our iOS app we're having some problems launching a particular enterprise email client app when the user presses the "Email" button on one of their contacts.
One member of our team came up with an idea to get around the problems with this enterprise app:
We let the user specify their email address in the app's settings and create our own email composing screen. Tapping the email button on a contact would open the composing screen, they would write their message and then we would send it on their behalf from our servers (or via service like mailchimp).
Basically, this would mean we would have to create an endpoint on our api that would accept a POST request with 'from', 'to', 'subject', and 'body' fields which would send the appropriate email.
This seems like a very bad idea as it's essentially creating a free, anonymous email service that could easily be abused send spam.
A few extra notes about our setup:
We don't verify an accounts email when they sign up
Even if we did verify the account's email, the user would need to be able to specify any email, as they may have signed up with personal email, but want to email someone from their work email.
Our API doesn't currently have any kind of rate limiting
Instead of having a from field in the request, we could instead send the id of the contact they want to email. This doesn't really change anything because if someone wants to abuse the send email endpoint they can also abuse the create contact endpoint.
So exactly how much of a bad idea is this, and how can I convince my team not to do this?
A few thoughts against doing it:
This is the perfect spamming service, which could damage the reputation of your company (reputational risk).
Your email servers would very quickly make it into blacklists (RBLs), making your outgoing emails land in spam folders in very many recipients' mailboxes.
Even if your servers are not yet in RBLs, if you send a forged email like that and proper email security is set up at the recipient end, your emails will still have a good chance to get classified as spam. Have a look at things like SPF and DKIM.
This could even have legal implications. Imagine the scenario when one of your users uses this service for something like blackmail. Would you be able to prove it was not you? Probably yes with the right controls, but would you want the hassle?
Still on the legal side, many countries (the EU, mainly) have data protection regulations which strictly control how personal data like email addresses can be used, especially for commercial advertisement. You probably want to adhere to that, but that would be hard with such a service (note that I'm not a lawyer, in such a case it's probably the abuser of your service that would offend these regulations and not you, I don't know, but it's something to consider).
If anyone can just send emails, it will be fairly easy to perform a denial of service attack against your services.
A few controls you could implement to mitigate some risks:
When adding a sender (from) address, you should validate that by for example sending a (cryptographically random) token and checking if the user can send it back (eg. by clicking a link in the email). If he can, that proves to some extent that he controls the email address and is probably a valid sender.
Limit the possible recipient addresses if you can. The best would be if recipients had to opt in to receive emails. If this is not possible, at least let recipients opt out from further emails. For this, you would have to add something like a footer to emails with "never again" links, and implement a facility to maintain recipients to which you must not send anymore.
Implement rate limiting. Depending on your exact scenario and use case, only allow to send the least number of emails acceptable for your application.
Implement proper logging so that you have an audit log of who exactly sent what email to whom. For this, log metadata like IP addresses as well. For this, you will likely have to authenticate your users.
On an operational level, have monitoring in place, and be prepared to ban offending users, based on a clear ToS shared with your users.
What is the best way of tracking responses for email campaigns? I was thinking on adding something to the reply-to field of the email (for example luqita+campaigns#stackoverflow.com), but I'm not sure if there is something more neat that could avoid this?
I thought about headers too, but it's important to note that the address luqita#stackoverflow.com would send many different campaigns, and the 'in-reply-to' header info would not be useful then to differentiate (while using luqita+campaign1 or luqita+campaign2 could)
What can I do?
So you want to be able to execute some logic when someone replies to an email you have sent through SendGrid? If you have access to change the MX record of the domain of the email address at which you want to receive the replies, you could use SG's Parse API to get a POST request to a script whenever email is receive at the address.
I think you would indeed have to set a magic reply-to address for each campaign. This seems like a perfectly fine solution; it's also how SG itself tracks bounces - it sets the return-path to something like bounces+{attempted-recipient-email}#sendgrid.com. Then examine the 'to' parameter of the POST notification you receive to know which campaign the reply is associated with.
When you say "tracking responses", do you mean that you expect users will reply to the Email, or do you mean that they'll click on a link in the Email and interact with a web site?
SendGrid obviously offers click tracking and open tracking, and you can set up to 10 different categories for tracking campaign stats and see delivery/bounces/opens/clicks/etc based on those categories. They also have a Google Analytics plugin that can feed back some analytics data to Google. And as #LinusR mentioned in his answer, the SendGrid Parse API can be set up in a way that reply Emails can get parsed and posted back to your site.
If the user will be interacting with your web site, you can use the "unique args" setup at SendGrid to set a unique string/hash to append to any URLs that can help identify a particular user, campaign, or whatever else you want to track.
Given there is a "FAILTO=''" option for cfmail, triggering an email to be sent to that email if the email didn't get delivered...
Is there a way to somehow assign an ID or tracking # to an email, store it in a database with that ID... then update the status of that email if it fails?
I'd like to track bouncebacks... preferably WITHOUT sending the FAILTO to a POP3 or IMAP and then checking it with cfimap...
Is there any alternate way of handling this?
Maybe an event gateway that is triggered upon email failure?
UPDATE: I've decided to take a different approach, utilizing the sendgrid API.
I'm hoping that lends me with a few more tools than CF offers.
The short answer to your question is unfortunately no.
A longer version with a possible solution:
The failTo email address populates the return-path in the email header, this then 'should' be used by mail servers for bounce backs (however see - http://www.bennadel.com/blog/1899-GMail-Seems-To-Ignore-The-Return-Path-Header-Defined-By-The-CFMail-FailTo-Attribute.htm for an example where it doesn't)
So you are going to need to monitor an Imap or pop account to see your mails, however you can set up an event gateway to monitor this, with detailed instructions here - http://www.alagad.com/documentation/imapGateway/ImapWatcher%20Gateway%20Documentation.pdf
What you're left with is needing to identify which mail matches which bounceback, when I've done something similar in the past I used unique id's for the failTo email addresses at a domain I owned. If you set that up and then use your listener cfc to look for the id in the return-path.
So your sending code would work along the lines of:
Generate unique id
Send mail
Add row to database with unique id
Your listener.cfc would then need to inspect the email returned and if it finds the unique id update the row with whatever information that you're after.
Hope that that at least helps even if you'll need to set up some other bits.
You could use a directly watcher on the undelivr folder to log the failed emails, only really a solution if its own server and not a shared server though.
As far as I know once it leave the spool and is off to your SMTP server CF assume it's been sent correctly.
The email will trickle down the chain of SMTP servers/relays and if anything happen the only instruction they have is to bounce it back to the from address or failto address if present. CF isn't listening at this point so it can't respond.
We use an external tool called Glock email processor to handle exceptions. It's not free, but works pretty well. You can find it here: http://www.glocksoft.com/email-processor/
You need to configure it to check the failto address and from there you can take many actions. I got it setup as a three strikes system.
Email address bounce, I increment a counter in my email table, at 3 I deactivate that email from the system.
Nothing you can't do yourself with cfpop though.
I'm building a system that allows people to submit text and photos via email in addition to standard access on the website. I'm trying to weight the security advantages of two strategies in particular for verifying submissions from a user. Here they are as follows:
To based auth: Create a secret email address per user and present this to the user for submission. This strategy has the advantage that people can send from multiple devices that might be setup with different mail accounts
From based auth: Only accept emails from addresses that are registered in the user database. The idea being that it is impractical/difficult to impersonate registered users based on the sending address.
Can you think of other possible solutions? Which strategy of the ones proposed makes the most sense to you?
I would suggest that you not use From based authentication, at least not without some additional credentials (a passphrase, etc)
It's way too easy to forge, and certainly not difficult if you know someone's email address.
If you echo the email back to the user for confirmation, you can make things a little more difficult, but realize that your service can end up being used as a sort of spamming relay. (I could send 100 upload requests to you, with a forged FROM address, and you'd go ahead and spam the real person with 100 confirmation requests)
The better option is to check the registered email address but add the need for a code within the email subject known to the user. This way if they forge the email from address, they would still need a key to authenticate the incoming email.
I would go with "from" + confirmation, to avoid forging.
I.e. receive the email, but send a response with auth token in the subject line (or in the body) back to the "from" address. The user either will need reply, or click a link to confirm the submission.
And you post the content only after confirmation.