I guess I'm thinking that if the user still has to configure the
choice
of POP vs. IMAP, the server for POP or IMAP, the means of
authenticating to POP or IMAP, "leave mail on server", and various
other IMAP frobs that sometimes seem necessary, and how to
authenticate
to the submission server, getting rid of the "submission server"
configuration item is a minor gain. especially when you probably
have
to add a "determine submission server automagically using SRV" check
box.
The draft goes out of the way to say that probing for other settings is
not prohibited. There are a couple of places where it lays down the
law,
ensuring consistency where vagaries might otherwise be problematic
(like
saying to check for IMAP SRV RRs before looking for POP3 SRV RRs, since
having different clients do different things would be problematic).
Are clients expected to support both IMAP and POP then? What about
clients for which POP support is good but for which IMAP support sucks?
Most of the options that are provided by messaging clients can be
determined with sensible defaults, or with simple probes. "leave mail
on
server" option is an example of the latter.
Assuming you really meant "former", what's a reasonable default for
"leave mail on server"?
I'd claim that "yes" is reasonable but some ISPs would claim that it
messes with their business model.
"no" as a default would cause mail to be deleted by accident.
Having an ISP set that default is also the wrong thing. Only the user
knows whether he reads mail from multiple locations or from multiple
clients.
Things like finding the IMAP
namespace or choosing a SASL mechanism can be discovered with probes,
and
are examples of the latter.
Well, there are issues like: does the user really want his password
transmitted in cleartext?
OTOH if people were willing to agree on some minimal security profile
for POP/IMAP/SUBMISSION (say, AUTH PLAIN + STARTSSL with no export
ciphers, RSA/SHA1/3DES as a required ciphersuite, and no ciphersuite
with a key strength less than 110 bits) and the configuration mechanism
refused to use a server that didn't support the minimum - then it might
be reasonable.
I haven't been able to find anything that is
mandatory that cannot be dealt with via probes, but that would
certainly
be a show-stopper and if you find anything let me know please. Options
are, umm, options, so they can be handled with defaults like already.
Sometimes it's worse to have a default than to force the user to
specify something.