On 08/23/2017 07:07 PM, Rupert Gallagher wrote:

I still find impediments to the adoption of any of those "solutions". Too many software dependencies, like PHP, DB, python, and a virtual machine. --- There are two portable file formats for calendar and contacts that work across applications and systems, but no server that can use them, and use them safely. You will need however a database to store them. Could be SQL or IMAP ( as in kolab)

And a server. If the server is Apache/nginx it will use php to extract them from database. I can't say there are too many dependencies, because the vaste majority of web applications around use the same stack.

Sent from ProtonMail Mobile

On Wed, Aug 23, 2017 at 10:41 AM, Infoomatic infoomatic@gmx.at wrote:

...

Hello, > Please witch add-on possibilities exist to synchronize the Calednar with > Dovecot and Postfix. > > Can give me here any a possible direction ? Postfix and Dovecot are responsible for mailing. If you want a calendar, you probably want a CalDav server or a Microsoft ActiveSync compatible server. There are various solutions out there, I know of caldav servers and libraries from sabredav.io, calendarserver.org, agendav.org, davical.org, radicale.org and bedework at apereo.org If you want a more integrated solution there is open-xchange (dovecot company is part of), sogo.nu, kolab.org, obm.org, horde, citadel, zimbra, zarafa While I have not tried all of those, I can recommend sogo.nu. I have not tried all of the above, and when I evaluated some of them (back then in 2012/13), some did not meet our expectations concerning speed, ease of setup/administration and stability. But things might have changed of course. Hope this helps, infoomatic

I can't say you are wrong ( you can better use a hammer.. ) but caldav is more or less web based.

I like the approach in kolab ( store contact in mailboxes, it works with dovecot, I have few server using it) but there is no usable client side implementation. I tried to fix the synckolab plugin for thunderbird in the past ( it works but i'm afraid some parts should be rewritten ) but I think there is no real interest for this approach. So we need to serve a web protocol, using a web server seems wise....

On 08/23/2017 09:49 PM, Rupert Gallagher wrote:

We murdered web applications with a chainsaw. Web 2.0 has too many security holes.

On Wed, Aug 23, 2017 at 8:35 PM, Mihai Badici mailto:mihai@badici.ro> wrote:

...

the vaste majority of web applications around use the same stack.

On Wed, Aug 23, 2017 at 7:22 PM, Tanstaafl tanstaafl@libertytrek.org wrote:

I would have to put in a plug for SOGo - very lightweight, ...

Care to elaborate?

https://github.com/inverse-inc/sogo/blob/master/Documentation/SOGoInstallati...

Too many requirements.

Sent from ProtonMail Mobile

Lookup radicale.

-- openSUSE - SUSE Linux is my linux openSUSE is good for you www.opensuse.org

Hi,

I realise that this is in fact off-topic, but: like others, I'd also like to recommend SOGo.

Someone in this thread said: it has too many dependancies, but I disagree, and in fact I consider it a good thing that it depends on other components.

Consider SOGo like an exchange server. And they (inverse.ca) only implemented the missing bits, and for the rest they depend on stable and mature other components.

While that means dependancies, yes, it also means: do what you're good at and what's missing, and for the rest: reuse what is readily available. Don't reinvent the wheel.

Besides that: most places will have many of the requirements in place already.

MJ

On 08/24/2017 07:38 AM, Rupert Gallagher wrote:

We tried installing Radicale months ago, and decided to postpone testing. Its footprint exceeds 140MB, because of python. It requires python, which is a security hazard on production servers. Security mitigations are absent: must use a virtual machine.

Sent from ProtonMail Mobile

On Thu, Aug 24, 2017 at 12:11 AM, Marcus Rueckert darix@opensu.se wrote:

...

Lookup radicale. -- openSUSE - SUSE Linux is my linux openSUSE is good for you www.opensuse.org

Re: portable formats and their mime type

https://en.m.wikipedia.org/wiki/ICalendar https://en.m.wikipedia.org/wiki/VCard

Re: dependencies

• db: why? just use the ical and vcard files! They are files, they are in a directory, they can be used like dovecot uses eml files! No need for postgresql or mysql.

• webmail: why? We use dovecot!!!

• apache web: why? we use nginx.

• linux: why? we use other unix systems.

• python: why? it takes 140MB all by itself, it is an interpreter (slow), it is a security hazard, we would have to install it on purpose and sanbox it in a virtual machine! So we have to install a vm manager.

Bloody hell...

Sent from ProtonMail Mobile

On Thu, Aug 24, 2017 at 4:25 PM, Tanstaafl tanstaafl@libertytrek.org wrote:

On Wed Aug 23 2017 14:26:15 GMT-0400 (Eastern Standard Time), Rupert Gallagher wrote: > On Wed, Aug 23, 2017 at 7:22 PM, Tanstaafl wrote: > >> I would have to put in a plug for SOGo - very lightweight, ... > >> Care to elaborate? > > https://github.com/inverse-inc/sogo/blob/master/Documentation/SOGoInstallati... > > Too many requirements. I obviously meant would you care to elaborate on this comment of yours: "There are two portable file formats for calendar and contacts that work across applications and systems, but no server that can use them, and use them safely." Any client<>server system will have some basic requirements. SOGo is very easy to install (as long as you are using a repo+package manager, and aren't trying to install each dependency manually by hand). @libertytrek.org> @protonmail.com>

“Webmail? We use dovecot.” And how exactly do you read and write mail using dovecot? On Thu, Aug 24, 2017 at 10:56 AM Gregory Sloop gregs@sloop.net wrote:

RG> Re: portable formats and their mime type

RG> https://en.m.wikipedia.org/wiki/ICalendar RG> https://en.m.wikipedia.org/wiki/VCard

RG> Re: dependencies

RG> - db: why? just use the ical and vcard files! They are files, RG> they are in a directory, they can be used like dovecot uses eml RG> files! No need for postgresql or mysql.

RG> - webmail: why? We use dovecot!!!

RG> - apache web: why? we use nginx.

RG> - linux: why? we use other unix systems.

RG> - python: why? it takes 140MB all by itself, it is an interpreter RG> (slow), it is a security hazard, we would have to install it on RG> purpose and sanbox it in a virtual machine! So we have to install a vm manager.

RG> Bloody hell...

This is a little tongue-in-cheek, but... Do you also yell "Get offa my lawn you dirty punk kids!" regularly?

I thought I had the curmudgeonly-old-man schtick down, but you're like Obi Wan. :)

On Thu, Aug 24, 2017 at 11:28 PM Rupert Gallagher ruga@protonmail.com wrote:

On Thu, Aug 24, 2017 at 10:55 PM, Roger Klorese rogerklorese@gmail.com wrote:

...

"Webmail? We use dovecot." And how exactly do you read and write mail using dovecot?

With a MUA.

And you’re suggesting that webmail is somehow more of a risk than lots of users each running their own MUA. I see.

handle big number of users and big amount of data.

You must be working for the NSA.

Sent from ProtonMail Mobile

On Fri, Aug 25, 2017 at 2:15 PM, Robert Wolf r.wolf.conf@gmail.com wrote:

On Thu, 24 Aug 2017, Rupert Gallagher wrote: > Re: dependencies > > - db: why? just use the ical and vcard files! They are files, they are in a > directory, they can be used like dovecot uses eml files! No need for > postgresql or mysql. *** Usually, the DB server is one host, Webclient is other host, IMAP server (or cluster) are other hosts, SMTP Server(-s) is other host. All these Servers need access same data on one place. Yes, you can use IMAP to store contacts and events, as e.g. Kerio, Groupwise, and probably some other do and then write some interface server to convert data from IMAP to HTTP. But many vcard and vcal servers store the data in DB (AFAIK SOGo.nu stores these in DB). Btw, dovecot can use SOLR/Lucene for indexing too. Dovecot does use local index files too, but probably if you have really many emails, then you want really indexing server (which can run on different hardware). Why? Because of searching. DB creates indexes and can search fast. Maybe for 100 items is searching on FS and in DB same fast, but with more and more items, FS will be slower. You know probably, how the vcard and vcal looks like (if not, please see one). This is a text. Everything is text. Even dates are text. You cannot search in these files e.g. "if event starts after 2017/8/25". You have to read every file, parse the dates and then can you compare. If you convert these vcal into DB, into correct fields, you can search faster the in FS. And the searching does not mean only if use want find something. The server must search for alarms, to do free/busy search, etc. > - webmail: why? We use dovecot!!! *** Webmail is client, dovecot is server. Do you have only dovecot? No client? Then why do you need dovecot at all, if none reads the emails? No, really, you need some client. Webmail is easy to use, Webbrowser is everywhere. I use alpine, but for BFU is webmail the best. OK, let's say the client for contacts and events could be thunderbird. Calender is intergrated in TB and it does use HTTP. E.g. even if the calender items are stored in Kerio in a maildir-like folder invisible over IMAP, the communication between TB client and Kerio servers runs over HTTP for vcal. SOGO AddOn for contacts for Thunderbird use HTTP too (it works even with Kerio). All these clients and server for ical and contacts use caldav and carddav (DAV over HTTP). Nobody writes server (or client), that use IMAP, because these is no client (or server) which synchronize vcal or vcard over IMAP. > - apache web: why? we use nginx. *** This should not matter, if you know, how to configure nginx to provide same functionality as apache. You can use your favourite webserver, as long as it supports the requirements of the app. E.g. if the vcard/vcal application is written in PHP, then the webserver must be able to run PHP. > - linux: why? we use other unix systems. *** because the programmers develop it on linux and have tested it on linux. For most things, you can use other unix too. Sometimes, it is possible to run it even on Windows, e.g. apache, nginx, php, perl, mysql, ... these run on Windows too. > - python: why? it takes 140MB all by itself, *** It must be written in some prg lang. Someone can C, then he writes it in C - but then, the same libraries must be installed or the developer must compile for every different system with different libraries. Python, Perl, PHP and other interpreted languages are compiled on the fly on the currently running system. Developer can simply pack original source code and this will run on every platform. Therefore, many people use interpreted langs to let their apps run on many platform without many special "IFs" and without compiling for X different platforms. > it is an interpreter (slow) *** I would not expect really big speed difference between good written python code and C code for some vcard/vcal server. > it is a security hazard *** I would say, there could be more security errors (buffer overflow etc) in C code, than in python code. > we would have to install it on purpose and sanbox it in a virtual machine! So > we have to install a vm manager. *** As I say, the most secure server is switched off server and disconnected from LAN and power. You have to choose between security, functionality and complexity. Either you provide only smtp+imap server or you want provide more features (webclient, vcal/vcard, ...) and then you need more software. For a few users could be no problem to have really some small/light server, which stores all data as files on local disk. But I think the programmers of such vcard/vcal servers think about to be able handle big number of users and big amount of data. Therefore they expect some real DB. More feature == more requirements. Regards, Robert Wolf.