Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Show server support (or not) for required or desired standards, extensions and features (diagnostics) #411

Open
marclaporte opened this issue Jun 25, 2020 · 1 comment
Assignees
Labels
enhancement suggest an improvement

Comments

@marclaporte
Copy link
Member

Cypht is designed to work with standard SMTP/IMAP servers, and JMAP:
#180

And one day, we'll likely add support for Microsoft Exchange:
#247

And perhaps we'll even add more options to send email:
https://dev.tiki.org/Transaction-Email-Sending-API

Furthermore, we should be in a position to take advantage of evolving standards:
"This document updates RFC 3501 (IMAP4rev1) with persistent identifiers on mailboxes and messages to allow clients to more efficiently reuse cached data when resources have changed location on the server."
Source: https://tools.ietf.org/html/rfc8474

With all these options, there could be some features that work differently depending on server support. Thus, we should add sections which report on features/standards supported by the servers.

As an example, in Tiki Wiki CMS Groupware, we have:
"tiki-check.php is a standalone script for server environment settings diagnostics before installing Tiki, or for an existing Tiki installation. While it was designed for Tiki, and it's bundled in Tiki, it is very useful for any PHP app, as it checks over 100 different things and provides contextual feedback. Started in 2012, this script has been refined over the years and it copes with all kinds of weird edge cases." Source: https://doc.tiki.org/Server-Check

Jason wrote: "If the move extension is not supported, we fall back to copy/delete/expunge. I'm surprised this hasn't come up before. We want to take advantage of any extensions present, but we don't want to rely on them for basic functionality."
Source: #158 (comment)

I hope we can leverage some existing Open Source code.

Thanks!

@marclaporte
Copy link
Member Author

An example of why we should do this: #516

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement suggest an improvement
Projects
None yet
Development

No branches or pull requests

2 participants