I have a desktop app that has been sending email via Mandrill for well over a year. I use my email as the email address and the end-users email as the sender. This way, when the recipient replies to the email, it goes to the sender’s email.
Mandrill has since joined with Mailchimp and now requires SPF and DKIM authentication. I was able to set this up successfully for my email address, but now this is required for every end-user’s email (see their message quoted below).
Of course, most end-users don’t know how to log into their web hosting service so that I can set this up for them. Also, this doesn’t seem to scale very well either.
I’m thinking, I somehow use a mail client (such as Thunderbird) without having to deal with all this stuff. What are my options here?
[quote]If you signed up for a Mandrill account on or after December 1st, 2015, you must add SPF and DKIM records and verify ownership of your sending domains before you can send email through your account. Mandrill will not send any email from unverified domains or domains without valid SPF and DKIM records, including public domains like gmail.com, yahoo.com, and more.
Custom signing domains are only available to Mandrill accounts created before December 1st, 2015. If you signed up for a new Mandrill account on or after December 1st, 2015, the signing_domain parameter will be ignored.
Mail sent from unverified domains or domains without valid SPF and DKIM records will be rejected with the reject_reason, unsigned.
Learn more about SPF and DKIM, and domain verification[/quote]
What is the purpose of sending the mails? Why do you use the end-users email as sender? Telling most users about SPF and DKIM will hopelessly confuse them except if you target admin persons.
If it’s a “send us a bug report” or similar type function, I would just use your email for both fields and use the user’s email for Reply-To. It’s how I handle my contact forms on my websites.
You won’t have to walk users through authorization, and you can still just hit “reply” in your email client.
Most mail servers are going to flag an email where the return address doesn’t match the domain it came from. If this is a case where you have clients who have clients, then you’re just going to have to educate your clients on how to set up email that they are sending to their clients through your app. Inform them that times have changed. If it were me, I would require them to have their own Mandrill account, anyway. Allowing them to use yours is a potential liability.
My proposal would be to give the users a choice: if they don’t have many emails use your address as sender. If they send more emails then prepare a thorough documentation or a video of what they have to do with the new security specs. I’l also charge more for this option because you have more work.
There’s other ways to do this that don’t require e-mails. If it’s a desktop application on OS X you can take advantage of the built-in notification system and schedule a notification to appear at a certain time.
Or you could write your own notification system.
You may even be able to tie into the user’s calendar application and insert notifications there, then these would appear on the users phone as well as their computer.
[quote=279797:@Sam Rowlands]There’s other ways to do this that don’t require e-mails. If it’s a desktop application on OS X you can take advantage of the built-in notification system and schedule a notification to appear at a certain time.
Or you could write your own notification system.
You may even be able to tie into the user’s calendar application and insert notifications there, then these would appear on the users phone as well as their computer.[/quote]
The end-user needs to send emails to their clients reminding them of appointments and/or ordered items in stock, such as a medical doctor reminding patients of appointments.
I give them a form that looks very much like the account settings in their email client. They are responsible for providing their own email service and credentials. That way there’s never a problem. They’re free to use whatever service they want, and it’s a one-time setup for them. Store that data with their profile in the database and use it whenever they send an email.
Ah, I see. I was mistaken in my earlier comments then.
Sendgrid might be worth looking at, as I think they still use simple authentication. (To be honest, though, I use them via PHP, not Xojo, so I don’t know whether they will be easy to use with Xojo or not.)
Sendgrid is easy to use. Examples have been given a couple of times here on the forum. However, a dedicated IP address costs 80 bucks per month. In the last weeks I’ve had problems with this 2 times. One of their IPs ended up on a spam list.
Looks like Mailchimp and Sendgrid provide similar services. Lately Mailchimp has started charging me a couple of months ago and I am already up to $25/month.
Having a dedicated IP and eliminating the need for SPF and DKIM authentication would be a big plus, but at more than 3X the price? Almost $1000 a year to add simple email seems pricey.
This is a huge headache, but so is SPF and DKIM authentication. Did you decide to bite the bullet and go for the dedicated IP with Sendgrid?
So Sendgrid gives you a shared IP to use which you code within your application. When it gets spammed, what happens? Do they notify you and/or move you to a new IP? Does that mean you have to modify your application and update all your users? How do they (and you) handle this when it happens?
I contacted Sendgrid and they sorted out everything. My application didn’t have to be updated. After having to do that 2 times I was fed up and ready to move. I wouldn’t mind 20-30 bucks. But 80 is too expensive at the moment.
Unfortunately, Mandrill (aka Mailchimp) stopped letting me send emails using my one API key tied to my customers return to address. This way they could send emails out and retrieve the replies. If I use my email as the return address, the customers won’t recognize the email address and secondly, I would have to figure out a way to forward the emails to each customer.
The solution to this is now to configure each customer’s web host. If they would know their password, I could configure it - but that’s a big if. Most of my customers don’t even know the password to their computer (let alone their router, or web host).