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" <dhc(_at_)dcrocker(_dot_)net>
To: "Gren Elliot" <fatkudu(_at_)gmail(_dot_)com>; "ietf(_at_)ietf(_dot_)org"
<ietf(_at_)ietf(_dot_)org>
Cc: "jmap(_at_)ietf(_dot_)org" <jmap(_at_)ietf(_dot_)org>; "iesg(_at_)ietf(_dot_)org"
<iesg(_at_)ietf(_dot_)org>
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
Jmap(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/jmap