Open source JMAP compliant servers? - email

I'm exploring the possibility of building a centrally hosted email client, embedded within my site. Users would be provisioned a new email address from me, they are not using their existing email. Essentially, I'm looking for the feature set of an email web client (multiple user accounts, get inbox messages, read, delete, compose new, organize, etc) exposed as set of RESTful APIs. A brief web search uncovered very little meeting my desires, but I did come across http://jmap.io. I was unable to find an existing implementation of the specification that I could leverage for my solution, and would love to avoid writing my own. Are there any existing solutions (JMAP or otherwise) that might meet my needs? I've ruled out https://context.io/ because I cannot have the emails stored or consumed by a third party.

I'm actively contributing to the Apache James Server. As part of my work, I am working on a JMAP implementation with my co-workers.
So far, we are able to build a working web-mail on top of it in one of our company product, OpenPaas.
And as it is an Apache project, it is OpenSource. Maybe you want to have a look...
https://github.com/apache/james-project/tree/master/server/protocols/jmap
http://james.apache.org/

I just want to add that as for now (2020) Cyrus IMAP also has JMAP support.

Stalwart JMAP server was just released (September 2022) and it includes full support for JMAP Core, JMAP Mail and JMAP over WebSocket. Support for JMAP Contacts and Calendar will be added as soon as these become IETF standards.

Related

Amazon Java client libraries

I am developing a solution for my client for his Amazon account, however, I am unable to find Amazon MWS Java library other than order APIs
I have already looked up everywhere on google, amazon seller forum, etc. but still I am unable to find java libraries other than order API and that even at Maven repository
I got in touch with Amazon Seller support and they sent me a link where Libraries for Amazon MWS Java, PhP and .Net are available. If anyone in future need it, they can find it here: https://developer.amazonservices.in/tools
Unfortunately, they moved the client libraries and you must first sign in to a professional sellers account to access them. They were available publicly for years.
Googling "amazon mws java" returns links like https://developer.amazonservices.com/doc/orders/orders/v20130901/java.html which require a Developer account (which in MWS terms means only the org's dev primary account as no General Role dev-enabled accounts in an org can get in, only primary and note that is different than the org's primary primary account). Best is whoever has it, post to open source GitHub before MWS reverts client libraries back to primary-only view ignoring they're almost a decade old now.

Online app backend with client-friendly online CMS

There are a ton of online CMS services out there. And a ton of (new) backend-as-a-service products too. But I can't seem to find what I am looking for.
I am building an app for a client. The app contains data about shops, products, and more. The client must be able to update this data (and not just one person: each shop manager needs to be able to log in and edit the data for their own shop). And of course the app must be able to access this data.
Client edits data online
This has to be extremely user-friendly and completely online. I don't want to sell my client something where they need to install stuff on their server. I don't want to sell them something that's accessible online but looks like phpMyAdmin.
I want a shop owner to be able to go to a webpage, log in, and then see a pretty UI where they can edit the data for their shop. The back-end needs to have a pretty front-end that's auto-generated for whatever data this particular shop owner is allowed to edit.
So there are two bits: storing data in the cloud in such a way that it can be accessed by the app (which I am building with Titanium), and allowing the client to log into the backend and edit the data in a non-tech, user-friendly way.
Here's a list of things I tried...
Backend-as-a-service
Services with a great back-end, but without easy auto-generated data editing website:
Appcelerator (Titanium) Cloud Service
Amazon EC2
Stackmob
BackBeam
WebVanta
Parse
API o Mat
ShepHertz Cloud42
Kii
Online CMS
Services that provide a nice way for clients to edit data, but no easy way for apps to connect:
CloudCMS
(and many others I'm sure)
It's insane that no-one seems to be providing the cross-breed of BaaS and online CMS. So many people are building apps for clients, and so many clients are not tech-savvy and are reluctant to get a special server and host database software they don't understand. Why does this not exist? What am I missing?
With apiOmat it's easy to create your own data-editing app for e.g. with JavaScript SDK and HTML. Or you send a feature request so that they build a module for your preferred CMS.
As you mentioned, Cloud CMS is a really good option (disclaimer: I'm one of the founders). The product provides an enterprise content management backend and an API that lets you plug in some really powerful features right into your mobile apps.
This month, we released a brand new user interface which provides much of what you're asking about. Instant forms, document libraries, search and workflow all in one place.
You can check out Cloud CMS here: http://www.cloudcms.com
I completely agree with your assessment particularly with respect to the last mile (getting the final app built). It's kind of the wild west out there and the strong technologies are still proving out.
You mentioned Titanium - that's a good choice. I also quite like the Ionic Framework (http://www.drifty.com/). It's a step in the right direction.

Openfire vs ejabberd for customer service chat evolving to full chat solution

I need to setup chat as a solution for customer service on a website. Openfire and some of it's plugins (fastpath and webchat) were very simple to setup locally and offer all of the customer service experience options I'd need, and will integrate properly into our CRM.
We have a clustered ejabberd instance running for something else. Before I looked into openfire, this was the obvious choice, since it's already been made secure and tailored to our environment. Having to duplicate all of the customer service functionality in an ejabberd module when it comes out of the box with openfire seems like a bad investment of resources.
Eventually, we would like to enable user to user chat as well, and perhaps turn it into a full scale messaging system.
Is it possible and/or recommended, using s2s or some other technique, to share the same database instance between the two different servers ? Does anyone else have any experience running both servers ? I'm sure there will be lots of gotchas if we go down this route, anything obvious ?
In my case, i was obliged to move to openfire for compatibility reasons.
I have a user list in a sql-server database and the external authentification is really hard and not supported for updated versions of ejabberd.
For me openfire is more open to different database and easy to integrate in existing plateforms

Single sign on solution

Hi I am using CAS for SSO. But problem is that i want reset password,register new user on CAS login screen.Does CAS provide these services or i have to implement?
Or Any other SSO solution exist which fulfill my requirement.
CAS is just a SSO frontend to your existing identity management solution (database, LDAP etc). It does not include any identity management features itself (create user account, reset password etc). I have recently been using the Cloudseal platform which is a full identity management solution and so far I am pretty impressed. I believe Atlassians Crowd also includes this although I have not used it. There are probably other products out there as well.
Both of these are commercial products although they are both free for the first 50 users. Crowd is a traditional standalone platform which you download, install and configure but Cloudseal is a hosted service so there is no installation and less config.
You can certainly modify the spring weblog and login page to allow for the functionality that of course you'd have to implement. You should also ask the question on #cas-user mailing list to see if a similar need in the community has been implemented by other users which you may be able to take advantage of. I remember only recently someone raised the same question to the list and there was a bit of interest in getting this feature developed and integrated. You may want to revisit the topic on the mailing list.
Hope this helps.

Exposed onsite vs IFD deployments for MS Dynamics CRM

I'm working for the first time on a MS Dynamics CRM 4.0 project. Our company has a high number of remote employees and even more remote consultants. As such it will be necessary to make the CRM solution available over the internet. As near as I can tell, I have three options:
Have everyone use a VPN to access an intranet site (typical onsite deployment). However, we have found that VPNs are far from trouble free and cause many support issues. We avoid them like the plague.
Use IFD to expose the CRM on the internet. I don't know much about this except that the URL will be different than the onsite URL, which could cause some headaches (see below).
Expose the CRM site by opening the site to the internet, using SSL to encrypt traffic. We currently do this with our MS sharepoint sites. I'm not sure how secure this would be (one of the reasons for this question).
I'd like to avoid using both the onsite intranet deployment and the IFD together for a couple of reasons. One of the requests for the solution is use email to notify users that they've been assigned a task, and include the URL to the task within the email. For this reason. If both deployments are used, then I'll need to include two URLs and the user would need to know which to use. Which leads to the second reason, the main users of the solution split time between being in the office and being remote. Thus they would need to access the solution two different ways, and know when to use which. Bad.
So, what are the advantages/disadvantages of any of these methods? Any other options? Is there any issue using IFD from within the intranet? Security issues?
UPDATE:
Be sure to read the comments of the accepted answer, as they further explore the ramifications of the various options.
That is the best, you have all the security, and a low maintenance deployment. Also if you are developing custom code (ASPx pages) you will have only one deployment type to support. If your users are already using a VPN Client, this should be the best solution.
This is the Microsoft way to do it. Except for the URL duplication. This solution is used in companies where clients do not want to have a VPN client, or where VPN clients can't pass thru firewalls. Also this solution is almost required if your outlook clients are using "Connect to exchange thru the web". Because in this case all the clients can open Outlook without VPN, CRM should be exposed without VPN, and the IFD deployment is handled natively by the Outlook client. Note that this is SSL enabled (required). EDIT : It's not required, but a best practice, even if the implementation guide says "You must define a URL for the Microsoft Dynamics CRM IFD by using the following format: https://".
This this the worst of all the worlds, you have to maintain the deployment manually, and you will have all the headache of using a deployment as we were using it in CRM 3.0 (NTLM, Kerberos etc). I do not recommend this.
You can use an IFD deployment thru the intranet, but there is some buggy behavior. The external DSN should be configured on the internal DNS server, so that internal client can access the internal server. And because IFD is SSL enabled, you are encrypting internal traffic...
Hope this help!