Textpattern CMS support forum
You are not logged in. Register | Login | Help
- Topics: Active | Unanswered
SMTP E-mail options
[ 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)
The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.
Txp Builders – finely-crafted code, design and Txp
Offline
Re: SMTP E-mail options
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)
Offline
Re: SMTP E-mail options
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?
The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.
Txp Builders – finely-crafted code, design and Txp
Offline
Re: SMTP E-mail options
- 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?
Yiannis
——————————
NeMe | hblack.art | EMAP | A Sea change | Toolkit of Care
I do my best editing after I click on the submit button.
Offline
Re: SMTP E-mail options
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)
Offline
Re: SMTP E-mail options
- 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.
aks_cron : Cron inside Textpattern | aks_article : extended article_custom tag
aks_cache : cache for TxP | aks_dragdrop : Drag&Drop categories (article, link, image, file)
Offline
Re: SMTP E-mail options
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.
The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.
Txp Builders – finely-crafted code, design and Txp
Offline