Bug 3140 - SRV Records for account auto configuration (RFC 6186)
Summary: SRV Records for account auto configuration (RFC 6186)
Status: RESOLVED FIXED
Alias: None
Product: Claws Mail
Classification: Unclassified
Component: Other (show other bugs)
Version: 3.10.0
Hardware: All All
: P3 enhancement
Assignee: users
URL:
Depends on:
Blocks:
 
Reported: 2014-04-16 12:24 CEST by Christian Hesse
Modified: 2014-06-03 13:59 CEST (History)
0 users

See Also:


Attachments
Example program of SRV resolution with c-ares library (2.62 KB, text/x-csrc)
2014-04-21 17:19 CEST, Ricardo Mones
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Christian Hesse 2014-04-16 12:24:57 CEST
RFC 6186 [0] ("Use of SRV Records for Locating Email Submission/Access Services") has been approved recently. It defines a method for using DNS SRV records for e-mail auto configuration (pop, imap, smtp and submission (all with and without tls)). Its implementation should atempt to retrieve the apropiate configuration for a domain with the user just typing in his e-mail address. This could improve the configuration process a lot.

[0] http://tools.ietf.org/search/rfc6186
Comment 1 Christian Hesse 2014-04-16 13:42:13 CEST
Supporting Thunderbirds auto configuration capabilities [0] could be an alternative...

Currently Claws Mail does not support auto configuration at all, no?

[0] https://developer.mozilla.org/en-US/docs/Mozilla/Thunderbird/Autoconfiguration
Comment 2 Paul 2014-04-16 13:47:15 CEST
(In reply to comment #1)
> Currently Claws Mail does not support auto configuration at all, no?

wrong: http://claws-mail.org/manual/claws-mail-manual.html#deploying
Comment 3 Christian Hesse 2014-04-16 13:58:23 CEST
(In reply to comment #2)
> (In reply to comment #1)
> > Currently Claws Mail does not support auto configuration at all, no?
> 
> wrong: http://claws-mail.org/manual/claws-mail-manual.html#deploying

Sure, this is really nice for a business environments, but nothing an ISP can benefit from.

What I would like to see is a feature where you can say: "Just download and install Claws Mail, type your name, mail address and password and you are done!"
Comment 4 Colin Leroy 2014-04-16 14:10:44 CEST
(In reply to comment #3)

> What I would like to see is a feature where you can say: "Just download and
> install Claws Mail, type your name, mail address and password and you are
> done!"

Yes, indeed, that's a different kind of auto-configuration. :)
Comment 5 Ricardo Mones 2014-04-16 16:07:33 CEST
(In reply to comment #3)
> (In reply to comment #2)
> > (In reply to comment #1)
> > > Currently Claws Mail does not support auto configuration at all, no?
> > 
> > wrong: http://claws-mail.org/manual/claws-mail-manual.html#deploying
> 
> Sure, this is really nice for a business environments, but nothing an ISP
> can benefit from.
> 
> What I would like to see is a feature where you can say: "Just download and
> install Claws Mail, type your name, mail address and password and you are
> done!"

Do you know if is there any free mail provider which allows this?

A bind instance with a fake domain can be setup to test this, but if nobody is implementing it on the provider side seems a bit pointless (right now).
Comment 6 Christian Hesse 2014-04-16 16:19:23 CEST
(In reply to comment #5)
> Do you know if is there any free mail provider which allows this?
> 
> A bind instance with a fake domain can be setup to test this, but if nobody
> is implementing it on the provider side seems a bit pointless (right now).

I have set this up for my private domain:

% dig +short SRV _imap._tcp.eworm.de
0 1 143 mx.mylinuxtime.de.

Though I am not a free mail provider. :D

But the next try (ok, it was the second, imap failed) was a hit already:

% dig +short SRV _imaps._tcp.gmail.com
5 0 993 imap.gmail.com.
Comment 7 Colin Leroy 2014-04-21 13:59:55 CEST
For what it's worth, 

https://sourceware.org/bugzilla/show_bug.cgi?id=2099

is about being able to query SRV using libc.
Comment 8 Ricardo Mones 2014-04-21 15:54:19 CEST
(In reply to comment #7)
> For what it's worth, 
> 
> https://sourceware.org/bugzilla/show_bug.cgi?id=2099
> 
> is about being able to query SRV using libc.

That seems unimplemented so far, isn't it?
Comment 9 Colin Leroy 2014-04-21 16:11:17 CEST
Absolutely :(
Comment 10 Christian Hesse 2014-04-21 16:46:48 CEST
How about GNetworkService?

https://developer.gnome.org/gio/stable/GNetworkService.html
Comment 11 Ricardo Mones 2014-04-21 17:19:28 CEST
Created attachment 1365 [details]
Example program of SRV resolution with c-ares library

Build: gcc ares_srv.c -o ares_srv -lcares
Source: https://bugzilla.redhat.com/show_bug.cgi?id=695426
        https://bugzilla.redhat.com/attachment.cgi?id=491425
Author: Jakub Hrozek
Comment 12 Ricardo Mones 2014-04-21 17:20:46 CEST
(In reply to comment #10)
> How about GNetworkService?
> 
> https://developer.gnome.org/gio/stable/GNetworkService.html

(In reply to comment #10)
> How about GNetworkService?
>
> https://developer.gnome.org/gio/stable/GNetworkService.html

‣ Pros:
  • Already coded.
  • Already link to libgio, no new dependencies.
‣ Cons:
  • Requires glib 2.22, no support for older versions.
  • Interface is already defined, wrap code may be required.

With c-ares:

‣ Pros:
  • Support for older versions.
  • Our interface definition, no wrap code required.
‣ Cons:
  • We have to code it on top of c-ares.
  • New library to link, new build dependency.


So, to me this is a draw, unless you start setting different weigths on some of the items or a new killer item appears :)
Comment 13 Colin Leroy 2014-04-21 23:15:15 CEST
(In reply to comment #12)
> (In reply to comment #10)
> > How about GNetworkService?
> > 
> > https://developer.gnome.org/gio/stable/GNetworkService.html
> 
> (In reply to comment #10)
> > How about GNetworkService?
> >
> > https://developer.gnome.org/gio/stable/GNetworkService.html
> 
> ‣ Pros:
>   • Already coded.
>   • Already link to libgio, no new dependencies.
> ‣ Cons:
>   • Requires glib 2.22, no support for older versions.
>   • Interface is already defined, wrap code may be required.
> 
> With c-ares:
> 
> ‣ Pros:
>   • Support for older versions.
>   • Our interface definition, no wrap code required.
> ‣ Cons:
>   • We have to code it on top of c-ares.
>   • New library to link, new build dependency.
> 
> 
> So, to me this is a draw, unless you start setting different weigths on some
> of the items or a new killer item appears :)

Glib 2.22 is rather old now, isn't it?

To me "new build dependency" is a PITA, regarding the Windows port. This is not exactly a hard-blocker, but I tend to a draw too without regarding W32, and in favor of GNetworkService if regarding W32.
Comment 14 Michael Rasmussen 2014-04-21 23:41:36 CEST
(In reply to comment #13)
> 
> Glib 2.22 is rather old now, isn't it?
> 
The feature could be optional. Eg. disabled if Glib < 2.22 is found.
It would be a same to throw away support for RHEL < 7, SLES, Debian Wheezy, Ubuntu 12.04 LTS, and a lot of other enterprise distributions?

> To me "new build dependency" is a PITA, regarding the Windows port. This is
> not exactly a hard-blocker, but I tend to a draw too without regarding W32,
> and in favor of GNetworkService if regarding W32.
I also tend to favor the G-family for cross compiling and general legacy support.
Comment 15 Christian Hesse 2014-04-22 08:00:16 CEST
(In reply to comment #13)
> Glib 2.22 is rather old now, isn't it?

It is.

> To me "new build dependency" is a PITA, regarding the Windows port. This is
> not exactly a hard-blocker, but I tend to a draw too without regarding W32,
> and in favor of GNetworkService if regarding W32.

The Windows version I am running (3.9.3-30-gd68093) tells me it is using GLib 2.28.8. So Win32 should not be a problem.

Not sure what versions of glib the LTS versions of some well known linux distributions use. But this feature could still be a build dependency on recent glib.
Comment 16 Michael Rasmussen 2014-04-22 08:27:32 CEST
It seems that all debian derivative distributions are covered since even squeeze are based on 2.24. RHEL 6 is also covered since it uses 2.22. Only older releases like RHEL 5 derivatives is not covered (2.12).
Comment 17 users 2014-04-25 17:55:03 CEST
Changes related to this bug have been committed.
Please check latest Git and update the bug accordingly.
You can also get the patch from:
http://git.claws-mail.org/

++ ChangeLog	2014-04-25 17:55:03.295516713 +0200
http://git.claws-mail.org/?p=claws.git;a=commitdiff;h=04f37128b2ab40c40a79ebe6295d3e9f3d83220c
Merge: d9d6a5b a9065ae
Author: Colin Leroy <colin@colino.net>
Date:   Fri Apr 25 17:55:02 2014 +0200

    Merge branch 'master' of file:///home/git/claws

http://git.claws-mail.org/?p=claws.git;a=commitdiff;h=a9065aec26499a0e1294c73b6d9e6f039976521e
Author: Colin Leroy <colin@colino.net>
Date:   Fri Apr 25 17:54:24 2014 +0200

    First implementation of auto-configuration (bug #3140)
    Wizard is still to do.
Comment 18 Christian Hesse 2014-04-25 21:28:24 CEST
Really great so far! Thanks!
Comment 19 MoH 2014-04-26 17:53:29 CEST
evolution activly decided against supporting RFC 6186:

https://mail.gnome.org/archives/commits-list/2012-November/msg01976.html


I think his 2 concerns are somewhat valid and one might better supports mozilla's autoconfig scheme?
Comment 20 Ricardo Mones 2014-04-28 11:25:42 CEST
(In reply to comment #19)
> evolution activly decided against supporting RFC 6186:
> 
> https://mail.gnome.org/archives/commits-list/2012-November/msg01976.html
> 
> 
> I think his 2 concerns are somewhat valid and one might better supports
> mozilla's autoconfig scheme?

Point 1) is already addressed, since the user will see which autoconfigured host/port are to be set before pressing forward.

The other points are evolution-only problems (Claws Mail doesn't even require a password to finish the wizard), which may be the ones really weighting heavy in the decission as they probably require architectural code changes.

Our architecture is better in that regard ;-)
Comment 21 Christian Hesse 2014-05-02 10:16:11 CEST
Just testing the new auto-configuration code. First status I get is: "Failed."
This is because my server does not provide pop3 service, hence I add the correct SRV records:

$ dig +short SRV _pop3._tcp.eworm.de
0 0 0 .
$ dig +short SRV _pop3s._tcp.eworm.de
0 0 0 .

RFC 6186 says this is a valid answer when the service is not available. Instead of "Failed." we should give something like "Service POP3 not available.".
Additionally it could make sense to change to IMAP.

Even automatically selecting the protocol with higher priority would be possible. See section 3.4 "Priority for Domain Preferences" [0] in RFC paper.

[0] http://tools.ietf.org/search/rfc6186#section-3.4
Comment 22 Christian Hesse 2014-05-05 12:24:51 CEST
Oh, and just another note... If you decide not to change the protocol based on priority the auto-configure button should move below the server-type dropdown menu as it is protocol dependent.