psw/mailautoconf
1
0
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity

readme file updates

Browse source
This commit is contained in:
Paul Wilde 2021-08-11 20:22:03 +01:00
parent 27e65a8fe0
commit e1398b0a47
1 changed files with 10 additions and 30 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

40
README.MD
View file

@ -44,40 +44,20 @@ First run will create sample.ini files in the config directory. Copy these to co
## Future plans ## Future plans
MailAutoConf is currently in _very_ early stages, with a _very_ limited set of features. MailAutoConf is currently in _very_ early stages, with a _very_ limited set of features.
My hope for MailAutoConf is to mimic the AutoDiscover service found in Microsoft Exchange services, My hope for MailAutoConf is to run as an autoconfig service which provides Calendar and AddressBook locations as well.
but with the intent of providing a set of URLS for each service which may be self-hosted and/or distributed, Calendar and AddressBook is in the autoconfig XML documentation, but currently not implemented. MailAutoConf can generate the correct information for Calendar and AddressBook into the autoconfig XML file, though no clients currently use it.
primary IMAP, SMTP, CalDAV and CardDAV URLS, but hopefully more services can be added in the future.
__For example:__ Things I'd like MailAutoConf to do:
Company X may have many services that are selfhosted i.e. Dovecot for email (IMAP/SMTP) and Nextcloud for Calendar and Contacts. [ ] Autodiscover.xml for Outlook clients - currently does generate, but untested.
Getting a set up like this configured on a mobile device is fairly involved for a standard user and tiresome if the company has many employees. [ ] Autodiscover.json for more modern Outlook clients - this is currently undocumented. I have implemented some features of it but it is currently not working.
There are many points where set up configuration mistakes can happen, leading to service outage for a user, and the difficult job of [ ] Calendars and Address Book - does generate into mail/config-v1.1.xml, but no actual clients support it yet.
the IT consultant trying to talk the user through setting the device up over the phone. [ ] Additional, custom services. For example, Nextcloud - instead of having to type in your Nextcloud instance URL, you can just enter your email address associated with you Nextcloud account and it looks up the URL from autoconfig - wouldn't that be nice?
[ ] Probably loads of stuff I haven't thought of yet.
MailAutoConf intends to patch this problem by providing the URLs and information (Port numbers, SSL/TLS type, domain name, etc.) for each service
in JSON format allowing for the connecting device to automatically set up this information on the device.
## What problems do I expect?
OK, the most glaringly obvious problem is that the JSON response information is no good if the device itself doesn't know what to do with it.
I hope to develop a mobile app with mail, contact and calendar features in it, but we're in _very_ early stages of the base service at the moment.
Once the basic JSON response service is operational, I'll look into the mobile app which will then be when things will start to become useful.
In the perfect world, this service starts to look so fantastic that mobile device Operating System and/or mail app developers start implementing the option
in their own code as an Account Type (i.e. ActiveSync, Office365, iCloud, IMAP, etc. are all already there), but I'm not sure if I see that happening just yet.
### Another problem is authentication.
I'd like all clients to authenticate to the MailAutoConf service, but where do we get that authentication from?
We could have local accounts on the MailAutoConf server obviously, but I don't think this feels "fluent" enough. Maybe, using the primary IMAP server address, we could do an authentication request and if that succeeds the login is accepted and MailAutoConf information is sent.
### More problems regarding authentication.
As we're intended to be used for self-hosted, distributed services, each service may have different usernames and passwords.
This means there will have to be some sort of manual credential entry for each service.
I am less concerned with this issue as it currently isn't really in the scope of MailAutoConf to handle this - the goal is to provide the core information (URL, Ports, etc.) not the credentials to log in. I of course want to make the experience as helpful as possible though, so I'll deal with any features surrounding this when I can.
## When will it be ready for production? ## When will it be ready for production?
Well, not yet. Well, not yet. Though it does sort of work already.
I'm working on this ultimately for my own use for my own small business. I'm hoping once it's good enough I could deploy the set up to customers I'm working on this ultimately for my own use for my own small business. I'm hoping once it's good enough I could deploy the set up to my businesses customers and ultimately get them away from a Microsoft Exchange based environment. There's a long way to go for that right now though.
and ultimately get them away from a Microsoft Exchange based environment. There's a long way to go for that right now though.
If you feel you may be able to help, or ideas on features and their implementation, notice any bugs, or just want to say hi. Please do so and submit a pull request if required. If you feel you may be able to help, or ideas on features and their implementation, notice any bugs, or just want to say hi. Please do so and submit a pull request if required.