[Top] [All Lists]

Re: Submission and SMTP SRV records

2004-03-16 17:33:03

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

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.