New Mailer extension

[GiovanniSalmeri]

I have published a new experimental extension Mailer. Unlike the others, it is directed (for now) only principally to developers who intend to use advanced mail functions in their extensions. Its features are almost on par with PHPmailer (some things less, some things more) although the code (written from scratch) is much shorter and simpler:

• Integrated SMTP and sendmail/qmail support
• SMTP authentication with PLAIN mechanism over SMTPS and SMTP+STARTTLS transports
• Send emails with multiple To, Cc, Bcc and Reply-To addresses
• Multipart/alternative emails
• Multipart/mixed emails (attachments)
• Validates and sanitises email addresses and other fields automatically
• Protects against header injection attacks
• International domain names like https://bücher.de (requires php-intl)
• Composition and automatic handling of iCal parts
• Generation of HTML parts from markdown
• Generation of mail in format message/rfc822
• Detailed error messages
• Easy contact form

I hope it will be useful to other people and will help to broaden the range of applications of Yellow :-). Every comment, suggestion and correction is welcomed!

[schulle4u]

This looks like a promising project, will have a closer look at the code. Just a quick hint for your documentation: the download link doesn't work, your repository uses main as branch name, your README references the master branch.

[GiovanniSalmeri]

Thank you, renamed!

[markseuffert]

Good work, two more tips. I suggest to add the topic datenstrom-yellow to your repository, see GitHub documentation. Your documentation mentions the file system/settings/system.ini, I think this should be system/extensions/yellow-system.ini. Hope this helps.

[GiovanniSalmeri]

Fixed in YellowMailer... and in all my other extensions. Thank you!

[antalyanakliye]

Good Job...

[GiovanniSalmeri]

I have added a Contact form as a sort of demo. In this way, also webmasters will find something useful in this extension. In comparison with the standard Contact extension, this version has 1. optional different subjects/emails 2. optional AJAX operation 3. HTML5 validation, and obviously a SMTP/sendmail/qmail backend. With little variations it can be adapted to send attachments and HTML messages.

[pawell0]

I have published a new experimental extension Mailer.

Latest version did not work in any way - with built in form and without it. Yellow version - latest 0.8.22

[GiovanniSalmeri]

Dziękuję bardzo! 😊

[markseuffert]

One more observation. Language strings will grow over time and I wonder if there's an alternative solution.

I suggest to use the following process for experimental extensions: Extensions should include at least the English language, they should include max the languages supported on the official website. Which are en de sv at the time being. Additional languages should be collected somewhere else, apart from installation files. For example in the README. Now users can manually copy/paste the corresponding language strings into their yellow-language.ini file. Of course, once an extension becomes published it can make full use of our multi language support with about 20 languages. With the idea that the bulk of the translation is done in one place. See also #841.

What do you think?

[pawell0]

I think these strings should be the part of the translation packages - eg. polish.php. It's simple as that. But this is only my suggestion, nothing else. That kind of aproach can also make another problems in the future. Which way be better? I don't know. BTW. At the beginning I started to put those strings into the polish.php language file, but later I noticed that they are the part of the plugin itself. So I leaved them there ... 😉

[GiovanniSalmeri]

One more observation. Language strings will grow over time and I wonder if there's an alternative solution.

Just some random thougths.

• For the time being I do not see big drawbacks in the current scheme (each extension with its own strings included, except "core" extensions which have their strings centralised in english.php, german.php etc.). Yes, strings grow over time, but we are talking about few hundreds of bytes.
• From the point of view of the webmaster (who is the "user" of Yellow) things should be as easy as possible. Copy-pasting is not difficult per se for webmasters, but is a step more and inevitably gives the impression that their own language is second-tier.
• Also from the point of view of the humble developers things should be easy. If I maintain extension xyz and its strings are scattered among english.php, german.php etc. (of which I am not the maintainer), updating the extension could become rather cumbersome.
• If one day (when Yellow has conquered the world 😁) languages and/or localised extensions should be too many for the current solution to work well, perhaps a greater granularity could be considered: for example an extension xyz.php could have its files xyz-en.php, xyz-de.php etc, or something similar. More files, but all explicit and clear.

Just my 2 cents! 😊

[markseuffert]

Yes, you can make extensions in any way you like. Please note that published extensions can provide the best user experience. This is where you should expect things to be the easiest to use and where most of the design, development, documentation time should go. If you want to work together, have a look at our contributing guidelines.

[GiovanniSalmeri]

For the record: I have updated the Mailer extension.

1. I have unbundled the example (which now is a separate extension Multicontact)
2. Now Mailer is better integrated with Yellow. All extension which use toolbox->mail will automatically use Mailer (therefore SMTP, sendmail or qmail) when sending mail

I am not 100% satisfied with the manner in which the old functionalities (HTML messages, attachments, iCal) are kept while using the new API. I considered several solutions, the one that I have chosen seemed to me the easiest to use (and to code...). Comments for this new iteration are welcomed!

[annaesvensson]

Good work. Maybe split this up? An SMTP extension for those who want to replace Datenstrom Yellow's built-in sendmail functionality. Would be lovely to have something like this. I think other extensions can take care of generating emails. The API is suitable for sending all kind of emails, plaintext messages, HTML messages and attachments. What we could need is an extension that takes what is given to the event handler onMail() and transports it via SMTP. Uses cases for such an extension are a local development environment with MAMP/XAMPP, a web server without properly configured mail transfer agent and people who have trouble getting their mail system to work.

See also previous discussions in #542 and #904.

[GiovanniSalmeri]

Maybe split this up?

You are right, it is exactly what I had begun to do, before realising 1. that this was a bit less easy than expected and required a lot of attention from my part in order not to break all 2. that my available time in these days was short 😞. So I have preferred to publish a provisional half-baked solution rather than doing nothing and leaving the impression that I was not interested in revising this extension.

Anyway (I write it here in order to clarify): as it is now Mailer is "an extension that takes what is given to the event handler onMail() and transports it via SMTP", out of the box. It does also other things, but the user can totally ignore what is written in the README under "How to use Mailer for sending complex emails".

"A bit less easy than expected": the problem is that toolbox->mail requires as different arguments $headers (as an associative array) and $message; but in MIME messages some $headers depend on how the message is built. Therefore a function for generating email that interfaces nicely with toolbox->mail must have more or less this form: list($fullHeaders, $message) = generateEmail($coreHeaders, $text, $stylesheet = null, $attachments = [], $iCal = null). But now Mailer has (for good reasons) a function make which creates an RFC2822/RFC2045 full mail message. Perhaps this night I thought of a simple solution, when I have time I will try it!

Thank you very much for your attention and comments!

[GiovanniSalmeri]

I have published two updates of Mailer: in the first I have fixed some glitches in sanitisation, in the second I have modified the interface, which now is slightly better integrated with the API of Yellow (I have left in the code functions for backwards compatibility). I have also rewritten the README: I hope that now it is clearer. I have done some testing and all seems to work well.

As regards the splitting in two extensions (one for email transfer, one for email creation), unfortunately I am still unclear: this splitting would be very logical, but I see something against it: 1. most similar libraries (like PHPmailer) do both things (so developers expect one extension for "all things email"), 2. the extension for email creation would anyway depend on the extension for email transfer (because relying upon PHP mail function for complex contents is not a good idea and is discouraged even by PHP manual). Anyway for further modifications I prefer to wait for the solution of #910 and #909, in case the fix should involve some changes in the API.