Re: [Jmap] Fwd: Re: WG Review: JSON Mail Access Protocol (jmap) - reducing configuration complexity

["Adrien de Croy" <[e-mail]>]

I've dealt with a lot of customer support issues relating to inability 
to send mail where reading was available.

the first point I'd make is that most users wouldn't imagine in a 
million years that you would have a different system for sending mail vs 
reading it, and they are often incredulous when we point that out.  I 
actually have a lot of sympathy for that POV.

Apart from that, the main issues we see people battling are, in no 
particular order

* issues with ISPs.  Common to block port 25, many admins don't know 
about Submit port (587)
* issues with firewalls, need to open / map additional ports
* issues with incorrect user data entry due to double the configuration
* various client software issues exacerbated by this

We (since our SMTP + IMAP is integrated) don't see so many issues 
relating to dealing with 2 different products (or more) to support mail 
(e.g. separate vendor for SMTP vs IMAP), but I would expect those would 
come with admin problems as well, especially if they use locked-in user 
databases that other products can't access, different support for 
different auth methods, different support for different crypto 
algorithms (recent changes to OpenSSL to deprecate RC4 and 3-DES 
highlighted some of these).

In short, managing 1 port and endpoint requires work.  Managing 2 
requires more.

I don't know how many people get SMTP and IMAP from the same place, but 
I would expect it to be the majority of users.  It would be interesting 
if someone could get some answers on that.

Adrien


------ Original Message ------
From: "Dave Crocker" <[e-mail]>
To: "Gren Elliot" <[e-mail]>; "[e-mail]" <[e-mail]>
Cc: "[e-mail]" <[e-mail]>; "[e-mail]" <[e-mail]>
Sent: 8/02/2017 9:12:31 AM
Subject: Re: [Jmap] Fwd: Re: WG Review: JSON Mail Access Protocol (jmap) 
- reducing configuration complexity

>On 2/7/2017 7:38 AM, Gren Elliot wrote:
>>You will either be using IMAP/SMTP to access your mail/submit your
>>messages or you will be using JMAP.  If you have the option of the
>>latter, you’ve just halved the number of things that need configuring.
>
>
>The primary argument being put forward here is simplification of 
>end-user configuration effort.
>
>While that has an intuitive appeal, a basic question for any effort to 
>replace and existing technology is how big the benefit will be and for 
>how much of the market?
>
>In this case, for most people, the configuration effort is quite rare. 
>So while it might be a bit of a hassle, it has no effect on daily life.
>
>Well, ok, there are some folk who have to make this change more often, 
>due to Draconian and misguided local policies -- the current advice 
>about password changes, from the UX community, is not to make changes 
>often, since this becomes a serious attack surface.
>
>But how large a community is this and why is this problem not mitigated 
>simply by having the user interface take one password specification and 
>map it to the two, underlying (and existing) protocols?
>
>d/
>
>--
>   Dave Crocker
>   Brandenburg InternetWorking
>   bbiw.net
>
>_______________________________________________
>Jmap mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/jmap