diff options
author | Matthew Barnes <mbarnes@redhat.com> | 2012-11-09 04:36:58 +0800 |
---|---|---|
committer | Matthew Barnes <mbarnes@redhat.com> | 2012-11-09 04:42:32 +0800 |
commit | 72524d4d30d8191bf50d288c505417354acaf45b (patch) | |
tree | 85cca3a5736adb5732c43cf87a4034740213ad53 /mail | |
parent | 6de9a0e56e9a6800e39a43cb04bc5e0045ff8790 (diff) | |
download | gsoc2013-evolution-72524d4d30d8191bf50d288c505417354acaf45b.tar.gz gsoc2013-evolution-72524d4d30d8191bf50d288c505417354acaf45b.tar.zst gsoc2013-evolution-72524d4d30d8191bf50d288c505417354acaf45b.zip |
Document why I decided not to implement RFC 6186.
Diffstat (limited to 'mail')
-rw-r--r-- | mail/e-mail-autoconfig.c | 46 |
1 files changed, 46 insertions, 0 deletions
diff --git a/mail/e-mail-autoconfig.c b/mail/e-mail-autoconfig.c index a9e9773050..69b7329b23 100644 --- a/mail/e-mail-autoconfig.c +++ b/mail/e-mail-autoconfig.c @@ -16,6 +16,52 @@ * */ +/* XXX Thoughts on RFC 6186: Use of SRV Records for Locating Email + * Submission/Access Services + * + * RFC 6186 specifies using SRV DNS lookups to aid in automatic + * configuration of mail accounts. While it may be tempting to + * implement the RFC here (I was tempted at least), upon closer + * examination I find the RFC to be insufficient. + * + * An SRV DNS lookup only provides a host name and port number. + * The RFC assumes the account's user name can be derived from + * the email address, and suggests probing the mail server for + * a valid user name by actually attempting authentication, + * first with the user's full email address and then falling + * back to only the local part. + * + * I'm uncomfortable with this for a number of reasons: + * + * 1) I would prefer the user have a chance to manually review + * the settings before transmitting credentials of any kind, + * since DNS responses can be spoofed. + * + * 2) Authentication at this phase would require asking for + * a password either before or during auto-configuration. + * Asking before assumes a password-based authentication + * mechanism is to be used, which is not always the case, + * and asking during may raise the user's suspicion about + * what's going on behind the scenes (it would mine). + * + * 3) For better or worse, our architecture isn't really built + * to handle authentication at this stage. EMailSession is + * wired into too many other areas to be reused here without + * risking unwanted side-effects, therefore it would require + * a custom CamelSession subclass with an authenticate_sync() + * implementation similar to EMailSession. + * + * While the technical limitations of (3) could be overcome, my concerns + * in (1) and (2) still stand. I think for the time being a better solution + * is to have an administrator script on api.gnome.org that compares the host + * and port settings in each clientConfig file to the _imap._tcp, _pop3._tcp, + * and _submission._tcp SRV records for that service provider (if available) + * to help ensure the static XML content remains accurate. It would also be + * instructive to track how many service providers even implement RFC 6186. + * + * Recording my thoughts here for posterity. -- mbarnes + */ + #include "e-mail-autoconfig.h" #include <config.h> |