Collaborate to update Nextcloud + ISPConfig HowTo?

The existing reference for How To Install Nextcloud with ISPConfig is based on ISPConfig 3.1 and is missing some detail. It also does not go into integration with ISPConfig mailbox accounts. This page has more info than the HowToForge article, but it's also for 3.1 I don't know how valid it is.

I installed the latest NC 20.0.3 this week (updated to the very latest 20.0.4 today). I installed the one and only NC addon that I can find which uses the SOAP API for mail user integration. But I had issues with that which I'm trying to work out now. I really hope the author of that app visits this forum.

I would like to work with someone who is familiar with Nextcloud so that we can update the How To doc for anyone who is using the current software. I'm using Ubuntu with Apache and for now I am running all components on a single server. We should be able to translate to/from, for example, RHEL+nginx as we gain info, and I will test a multi-server installation if it seems beneficial.

I recently worked with @Th0m on his update of the doc for Roundcube integration. I am using Roundcube now and looking at Thunderbird, but I really want to use Nextcloud for Calendar and Contact support - which does not rely on WebDAV functionality in ISPConfig. The end result of this should be our (ISPConfig user/admins) ability to effectively fire up a network of high-quality cloud application servers for consumers and business.

Please post here if you have a working NC/ISPC environment to share notes.
Thanks!

(Is there a better forum for this to get more eyes on it?)

 

I don't know where this discussion belongs but the name 'Plugins/Modules/Addons' seems spot-on to me.

I started this adventure with a Zimbra installation, primarily for the email server. I moved to ISPConfig because it's a better environment for much more than just the email services. Then I started to focus on clients for email, calendar, contacts, etc. The weak link always seems to be that ISPConfig exposes a unique interface for mailbox/alias/identity data. The login user ID / email address ID seems great initially, but getting any client to use it is a huge challenge.

The adapter for Roundcube works but RC itself doesn't have a broad enough ecosystem. Too much seems dependent on Kolab. The ManageSieve integration is better than most but not great. So this isn't an ideal client.

On to Thunderbird, I don't have mail working properly with the ISPConfig back-end but I'll work on it. That has calendar and contacts but that data is stored on the local PC. At the moment I'm thinking I can use the Nextcloud CalDAV/CardDAV interface with the TbSync addons to get server-based (NAS) data to sync across clients. What a hack.

That led me to Nextcloud which is browser based, seems more complete, and there are possibilities for offering hosting services in the future. But again there's that one interface from one guy, and information about that client and this server is incomplete and outdated.

My next candidate is MS Office365 with Outlook. While not a free solution it is complete, extensible, and has a huge ecosystem. It supports multiple IMAP accounts, but once again I'm sure there will be a challenge with ISPConfig mailbox data. If so, I'm a .NET guy and I can probably write that interface myself. But I don't know if Outlook can store calendar/contact data on a non-MS server.

What I'm saying is that the ecosystem around ISPConfig is too small given its presence and positioning as a server/network management platform. I said something like this when I first got started here but the response was dismissive. Don't get me wrong, I'm not saying there's anything wrong with ISPConfig, I appreciate the FOSS and all resource constraints. I'm saying the SOAP/REST interface for mail accounts is a DIY project for every platform that wants to use it, and that becomes a liability when there aren't enough people who both use other platforms, and want to create and continue to maintain the integration.

An RFC-compliant interface for mailbox user/aliases might make this platform easier to use in that area and thus remove a (my perception) barrier to adoption. Until that is created, and I haven't even suggested it until now, I'm comfortable posting my notes here about collaboration to create better documentation to make it easier for people to create and maintain the existing interface. I started with offering to help with the docs for the API itself - and I'll get back to that when I can get my client/server network stable.

How about this... What are YOU guys doing in this area? Which mail clients do you use? Which devices/apps? What interfaces are you using to create identities from aliases - or are you? What do your end-user clients do? Or what do you suggest to them?

Thanks.

 

Jesse - As I go through all of this I wonder what rules are being followed to allow clients to get this data from servers. I think you've poked the hole in my rant. I might be confusing "convenience" functions to get alias data (where there are no RFCs) with SMTP SASL requirements.

Here are some notes about some of this:

• For Dovecot/IMAP login, in dovecot-sql.conf there are specs for queries on dbispconfig. These queries do seem to allow for either the 'login' or the 'email' to be used for the IMAP login.
  
• For Postfix/SMTP, in main.cf this setting is used to get auth info from dbispconfig:
  smtpd_sender_login_maps = proxy:mysql:/etc/postfix/mysql-virtual_sender_login_maps.cf
  
• The query in that .cf file does not allow use of the 'login' name. This might be causing some of my confusion about what does and does not "work".
  
• Common RFCs for SMTP and IMAP authentication - no mention of retrieving a list of aliases, only about authenticating with the localpart or a server-side alias.
  
• Info about how multiple IDs can be used with MS Exchange. This seems to be a Microsoft-created convention, not from RFC.
• This is how QMail stores users and aliases, also not from RFC.

Maybe I do have this wrong:

• It looks like these email clients (Roundcube and Nexcloud) don't need these SOAP interfaces at all.
• SMTP/POP/IMAP is going through normal authentication, and through a MySQL proxy to dbispconfig.
• The SOAP interfaces are just convenience functions to pull the alias info for client-side identities - the intent is to eliminate the need for us to manually enter the detail.

Is that all correct?

And would this enhancement be valid? mysql-virtual_sender_login_maps.cf from

Code:

SELECT email FROM mail_user WHERE email = '%s' AND disablesmtp = 'n' AND ...

to

Code:

SELECT email FROM mail_user WHERE (email = '%s' OR login = '%s') AND disablesmtp = 'n' AND ...

Thanks for your patience.