Intergration with off-site e-mail services (Mandrill, Amazon SES, etc...)

[nrep]

For larger forums, sending e-mail via Mandrill, Amazon SES and other e-mail services can be very useful. It offloads work from the server and provides a more reliable method of mail delivery (as it is sent from managed, trusted IPs).

These services also provide excellent bounce handling, which can be integrated via simple webhooks.

There is an excellent addon already that does this, but it is so useful that it could really be a core feature.

 

[Alpha1]

I have been speaking to Sparkpost and Elastic Email about possible integration. Both show interest to offer their services but are unfamiliar with XenForo code and see no examples. Their service API's are superior according to them.

with swiftmailer as the underlying email handler you already have the generic email framework sort of .

Then my suggestion is to refine it from 'sort of' email provider framework to a full one. Indeed with interface.

The difficulty with such integrations is what @Sim describes here:

I have spent a long time developing my SparkPost solution. Getting it to send emails was the easy part - dealing with the nuances and complexities of optimising the system was what took the longest.

Sending emails really is easy - ensuring those emails appear in people's inboxes and not their spam folders is a LOT more complicated, especially when you are sending a lot of emails and start to include non-transactional emails in the mix.

Years ago I developed a vbulletin bounced email system (together with a developer) which took months of daily testing, analysing the results, tweaking the code for each encountered situation. And that was just bounces. Email is highly complex and diverse by nature. This will surely manifest in the integration with external email providers. Some factors will be unique, but there surely are similarities. Similarities that are encountered once one integration is provided.

This is why I think it would be beneficial to have an interface and at least one implemented integration, as well as some documentation with developers to get more happening.

 

[Mouth]

you would need to check the external libs if or how they handle bounced emails etc.

As the OP says ....

These services also provide excellent bounce handling, which can be integrated via simple webhooks.

... bounce handling and notification is available. Likely easier than handling via POP/IMAP retrieval.

so it would be pretty straight forward to implement another esp lib into xF.

So not much more to do here.

I believe you're contradictory, and perhaps confused?

 

[Alpha1]

Come one guys, please keep things constructive. It would be great if this suggestion can manifest in some form. This thread going off the rails is not productive.

... bounce handling and notification is available

There is a world of difference between SMTP and API in this regard. Getting a status code (if lucky) and hoping this gets interpreted correctly is way different than exact information from an API.

 

[S Thomas]

Let me try to explain it another way. There are currently two ways of integrating an ESP which are being discussed here:

I have been speaking to Sparkpost and Elastic Email about possible integration. Both show interest to offer their services but are unfamiliar with XenForo code and see no examples. Their service API's are superior according to them.

The thing here is probably that they want to integrate their native API without SwiftMailer. At least that would be my guess. This is the first way to integrate an ESP. Just plain application (XF) <-> API (ESP) communication. That's why they would call their APIs superior. Because they simply have more functionality inbuilt.

The second way is to use a SwiftMailer integration, like for example Sim is using that one for SparkPost, I peeked into the SendGrid one etc, which means there is already a lot there to begin with (but not everything). This means application (XF) <-> Bridge (SwiftMailer + Integration) <-> API (ESP).

What these integrations do is to simply make the ESP's native API compatible with SwiftMailer. What the ESP devs now would have to do is to integrate their stuff into XF using the already existing libs (or extending them) following the already existing XF code for handling various parts of emailing.

Otherwise, if they really want to create a native XF addon with no external dependencies other than those of their APIs, then you're right, the XF documentation on that one is weak and a common interface would make sense.
But then again, there is already the option to use and extend SwiftMailer + integrations. So either way, the ESP devs have to decide on what they want to get familiar with - either XF & SwiftMailer or XF & Guzzle.

 

[Mike Fara]

API integration is possible and was done by a third party developer for XF 1.* already. We are at the point where you can get the bounce/unsubscribe to work if you add integration. At least I know this is the case with Mailgun and Sendgrid. They just need to add native support. So yes I must upvote this suggestion. How its integrated is simply semantics, but it can be done and it is proven to have been done already. XFROCKS did it with [BD] Mails

Point being, it should be a core feature.

 

[GazCBG]

Was using [BD] Mails by XFRocks for Mailgun API in XF 1., but have now setup a new site and it appears XFRocks hasn't or isn't upgrading it to XF 2. which is a really shame.

I would normally use SMTP in this case, but my hosting provider is forcing all email through their servers first, so I need some sort of API to send it.

 

[phucvandinh]

Up vote. Sending email via API is much faster than SMTP and doesn't log the server IP on email header which is a way to prevent IP leak.

 

[Sim]

FYI I my SparkPost addon is available with full bounced email handling - https://xenforo.com/community/resources/sparkpost-mail-transport.7537/

sending emails is easy. But that's less than half the story. Dealing with bounced messages and other feedback loops, handling unsubscribe requests, differentiating between transactional and non-transactional emails, optimising for deliverability, managing dedicated IP addresses and facilitiating IP address warmup protocols - that all takes time.

I have spent a long time developing my SparkPost solution. Getting it to send emails was the easy part - dealing with the nuances and complexities of optimising the system was what took the longest.

I also have a much more sophisticated version of my addon which I have not yet released and I might make available as a paid addon. It has more sophisticated analytics support, dedicated IP address support, suppression list management and more. For most people my free addon will do everything they need.

 

[DavidXLD]

I dream of the ability to use the API of sendgrid, sendinblue,.. instead of basic smtp integration.
I use [TH] Monetize for automatizing emails send to my members and I would like to have click URL details, statistics by categories,...
A lot of the rich statistics provided on transactional emails are available only if we use specific functionalities of mass email senders (sendgrid, sendinblue, mailgun,...) with their API by passing adidtionnal information tag through the header.
And obviously it will make bounce handling easier.
Since I move to XF 2.1 and can no use "BD mails" anymore, it is a nightmare :-(
a big +1

 

[Salamanca]

+1

Using Sendinblue

 

[USY]

+1

Using Sendinblue