Re: [imap5] Where is IMAP5 ?

[Giovanni Panozzo <[e-mail]>]

>
> Inside the supermarket you don't find meat at the same place
> than fish and you don't ask fish to the butcher.

But we used the car, find a place to park, walk inside the supermarket 
one time (and not two). We saved a lot of time and money. Then, inside 
the supermarket we can talk to the butcher or take fish.

I hope the same will happen for IMAP5: one single portocol for access 
(write less code, configure less parameters), but access more services.

>>> How it was when bandwidth was 33.6 kbps?
>
>> It was shit - it's still shit.
>
> Just for you. Nobody else cares about halfing bandwith on
> 1% of email traffic.

I care. Sometimes that 1% traffic is the most expensive traffic you have 
paid for in the last 3 years. I happened to me last week with my 3G 
connection and my android.

> You say it right. One side is sending a message, another one is
> saving a message. How IMAP could handle all errors than can
> occur during a email submission? By becoming a SMTP server.

Wrong. With UID SUBMIT, IMAP servers will become also SMTP clients, not 
SMTP servers. We just move SMTP the client logic from the user client to 
the server.
The user can still have all the notifications he likes via the IMAP 
channel or via a returning DSN.


>>> 50 IMAP current server softwares implementations to be changed and learn
>>> them how to post locally while every email client software know currently
>>> how to post anywhere. How good it will be, you deserve a poster!
>>
>> The saving will be purely bandwidth, and simplicity for those who
>> are building both ends and hence can rely on the IMAP software
>> having this facility.
>
> No. How IMAP can submit locally? smtp port? pipe? unix socket? shared memory?
> forking command? It will oblige IMAP sysadmins to configure IMAP server
> softwares so they can post locally. More work than configuring
> a SMTP server independently.

A little configuration work for one person (the server sysadmin) will 
save a lot of work for the user and helpdesk people to configure SMTP on 
hundred devices. When we used IMAP+SMTP I lost a lot of time at the 
phone with the user just to discover that... the network he was using is 
blocking outgoing SMTP (port 25) and sometimes also blocking SMTPS.

Two channels (IMAP+SMTP) creates a lot of user support requests at your 
helpdesk service.
Three channels (IMAP+SMTP+*DAV) means more user support again, because 
http/https could also be blocked, transparent proxyed and many other 
horrible things.

A *LOT* of user support at the phone.

This is one of the points because my IT chiefs decided to move to 
Blackberries or ActiveSync in the last 5 years. End user configuration 
and support !