Bug 3140

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

(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

(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!"

(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. :)

(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).

(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.

For what it's worth, 

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

is about being able to query SRV using libc.

(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?

Absolutely :(

How about GNetworkService?

https://developer.gnome.org/gio/stable/GNetworkService.html

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

(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 :)

(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.

(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.

(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.

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).

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.

Really great so far! Thanks!

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?

(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 ;-)

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

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.