[Kolab-devel] inbox transport

[Bernhard Reiter]

On Tuesday 02 November 2004 23:11, Steffen Hansen wrote:
> On Tuesday 02 November 2004 17:53, Bernhard Reiter wrote:
> > It is needed only in the case that a multi-group account
(Sorry, should have read: "group" account.)
> > shall be read by many OL users immedeately.
> > In this case vacation and forwarding will not be used normally.
>
> Ok, can you summarize why exactly we need this?

Okay:
Think about a group account: sales at our.domain
You want people to operate in there, so somebody can make an appointment
with the sales section and you have a real calendar and stuff.
To be able to comfortable work with three outlook clients
on the group account, they all need to see the emails immedeately (within minutes).

> I understand that Outlook is too dumb to run new mail from the IMAP
> INBOX thru it's iCal filters so it wants to fetch new mail over POP3
> instead and then later upload it to INBOX/Inbox.

Yes, the bad part is that it also needs pop to send out ical messages.
From my understanding only the pop part  can parse and create iCalendar.
This is why a plug-in does not have a huge choice.
So we are looking for a solution for this.
Solutions that I have disregarded so far:

a) Implementing an iCalendar parser in the plug-in would 
only solve this partially as OL still does only on the current folder
for registrations. Beside that it bears high risks and quite some work.

b) A pop3 proxy, but this would have a hard time fighting against 
a lot of anti virus software that hooks into the pop3 transport by various
methods.

For Proko2 it is acceptable that only for registration of invitation messages
somebody has to change the outlook profile and get the message via pop.
So we only need to transport the other emails to the default.inbox.

> Kontact OTOH has no problems like that and just sees unseen messages in
> INBOX as new mail.

Correct.

> Who has a problem here that we're trying to solve? Outlook or Kontact?
> Kontact could just as well move the mail to INBOX/Inbox coulnd't it?
> That could even happen before IMAP sync by issuing a COPY and a DELETE
> so kontact doesn't have to download all new mail and then upload it
> again.

In a setting with a permanently running Kontact in the group, this would work,
but this is quite dirty as you can imagine.
But we think of a sales@ group with only OL clients,
even one permanently running OL getting all the pop3 stuff would solve the issue.
So I aim to not have a permanently running client.

> Next thing is that a Sieve script installed by the server wont know the
> name of the "Inbox" folder -- only the client knows if it's called
> Inbox or Posteingang or whatever, so only the client can install that
> script.

The server should be able the see imap annotation.
(If we do not have that imap annotation yet, we should start using it.)
I had hoped that we already mark the standard folder with an imap annotation.
A faster solution could be to make this folder configurable, too. (hmm?)

> Sorry if I still don't really understand the problem, but I have to
> "resist" attempts at pushing functionality from the client to the
> server in order to keep in line with the original Kolab scalability
> thoughts.

That is fine, I want you to understand the problem of course.
Please let me know immedeately or call me, when this still is unclear.
We need this in the next two days.

	Bernhard
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2145 bytes
Desc: signature
URL: <http://lists.kolab.org/pipermail/devel/attachments/20041103/c09b1499/attachment.p7s>