SMTP E-mail options

Bloke · 2017-09-18 12:32:29

[ Topic split from here ]

gaekwad wrote #307050:

I would really, really like to see Textpattern be able to connect to an external SMTP server or service (like Amazon SES, for example) to minimise the problems associated with email delivery.

How would you recommend we handle that? A toggle setting in Prefs and if SMTP is selected, it offers further options for domain, port(?) username, password, etc? Anything else? Or would this open up a host of other issues that are best solved by a plugin that had access to a better core email delivery framework?

Last edited by Bloke (2017-09-18 14:54:03)

gaekwad · 2017-09-18 12:51:43

Bloke wrote #307051:

(possibly OT) How would you recommend we handle that? A toggle setting in Prefs and if SMTP is selected, it offers further options for domain, port(?) username, password, etc?

Yes. Pretty much that. An A/B radio button:

use PHP mail() to send emails
use SMTP to send emails

…then provide email envelope address, server, port, encryption (none, SSL, TLS), authentication radio button (yes or no), username and password. Perhaps some logging as to what’s happening, server responses, etc.

[…] would this open up a host of other issues that are best solved by a plugin that had access to a better core email delivery framework?

Possibly, yes. I don’t have metrics for how useful it would be overall beyond anecdotal I would really find this useful, but more and more I’m avoiding the headaches of small-scale SMTP sending and letting the professionals take care of it…and that invariably needs this glue to stick it together.

Last edited by gaekwad (2017-09-18 12:58:41)

Bloke · 2017-09-18 14:59:10

I’m inclined to agree that in the age of uber-cheap third party solutions and an increase in server spam heuristics that confine “insecure” or unsigned communication methods to the spam folder / bin that we should look into this.

The question remains whether we simply provide a better email management interface, such that a quick plugin can hook into that and offer SMTP support, or whether it’s worth implementing in its entirety in core, via prefs as you suggest.

Floor’s open. Anyone care to stick their oar in either way and weigh up the pros/cons?

colak · 2017-09-18 17:20:38

PHP mail()
- foolproof
- has a long history in txp
- most servers support it out of the box
SMTP
- each server has different policies
- protocols may differ
Third party SMTP
- where to start and where to stop? Amazon, Gmail, hotmail, the list is endless. Mail clients makes connections to such services simple but is it really?

gaekwad · 2017-09-18 17:48:24

colak wrote #307061:

PHP mail()

foolproof

has a long history in txp

most servers support it out of the box

Valid points. Shared hosting, especially the ones with noisy neighbours, are sometimes prolific sources of spam and end up on various watch lists monitored by the big email providers. It’s very easy to trigger some Gmail/Outlook spam markers and end up missing inboxes.

There’s a reason why agencies and those involved with (legitimate) email marketing use reputable services for transactional emails — these services have an interest in maintaining their mail-sending reputation and react quickly to problems when they arise. Stuff just works.

SMTP

each server has different policies

protocols may differ

RFC821 (1982) dictates how SMTP works. (Edit: and RFC5321 (2008) added Extended SMTP)

Third party SMTP

where to start and where to stop? Amazon, Gmail, hotmail, the list is endless. Mail clients makes connections to such services simple but is it really?

Yes. Sending SMTP email is straightforward; it’s the arrival at the other end that’s becoming a bugbear. If a domain has valid SPF, valid DKIM, reverse DNS and the IP isn’t on any watch lists then it’ll arrive with a zero or sufficiently low spam score in the header that it’ll be treated as ‘good’ email and arrive as expected.

PHPMailer is GPL 2.1 licensed and might be worth a look.

Last edited by gaekwad (2017-09-18 17:50:35)

makss · 2017-09-18 18:39:23

Modular system?

Message module (on/off)

For example, I do not use mail, I will disconnect the module and forget about it. At the same time, the module concept will write more powerful and functional communications system that will not overload the core. It will be possible not to be limited to only one SMTP protocol, but to implement other methods of message delivery.

Bloke · 2017-09-18 21:43:15

makss wrote #307066:

Message module (on/off)

Modularisation is good up to a point, but Textpatten uses email for sending out new author invites and password reset requests, as well as whatever plugin authors dream up. Unless we can find alternative ways of notifying people they have account-related messages (send SMS, Tweet, post on Facebook Timeline(!), …) and give admins or users the option to choose which method of communication, an on/off won’t work in this case.

Textpattern CMS

Textpattern CMS support forum

#1 2017-09-18 12:32:29