Providers running dovecot?

[Olivier Cailloux]

Le vendredi 09 octobre 2020 à 11:22 +0200, Piotr Auksztulewicz a
écrit :
> On Fri, Oct 09, 2020 at 10:15:10AM +0200, Olivier Cailloux wrote:
> > The real, “final” question I am interested in is, but which might be
> > slightly off-topic on this list (the reason I asked the other
> > question), is to find providers that satisfy these two conditions:
> > a) offer free e-mail accounts
> > b) implement correctly the IMAP SEARCH feature of RFC 3501.
> 
> IMO this is the right question to ask, even here.

You are probably right, in retrospect, I should have started with that
question.

> 
> > That is because my client uses the IMAP SEARCH feature, and it is
> > usually implemented incorrectly (e.g. in GMail or MS Exchange).
> 
> Probably it would be more informative to describe which features you
> need that are implemented "incorrectly".

Well, support of the IMAP SEARCH command is the specific feature I
need. See https://tools.ietf.org/html/rfc3501#section-6.4.4.

> 
> Reality check: RFCs are not government-enforced standards. There are many
> sensible RFCs that never got implemented widely, or nearly at all, are
> implemented partially, or there are widely deployed not-fully-compliant
> software systems. If your client software requires a feature that's not
> widely available, you're just limiting your audience.

Sad but true, I believe you are completely right. I will perhaps have
to abandon my hope of finding compliant providers.

> 
> You may try to find a different way to achieve your goal using the
> features that are widely implemented. Real, successful software packages
> very often contain options to do some quirks in order to stay interoperable
> with existing noncompliant implementations.

This is precisely the problem in my case: it is impossible to work
nicely around the lack of IMAP SEARCH feature on the side of my
software, which is client-side, because that support must be provided
server side. In a nutshell, the SEARCH command lets a client ask a
server: “give me all e-mails whose subject and date match such and such
criteria”. As a client, if the server does not implement IMAP SEARCH, I
simply can’t know which e-mails match such and such criteria, short of
downloading all e-mail headers and filtering them, which is orders of
magnitude slower if my user has many e-mails in her box.

Admittedly, I can work around this more or less nicely, e.g. by
downloading all headers once, storing them on the device of my user,
and searching this local database, instead of re-downloading all
headers every time my software runs. (This is how Thunderbird, and, I
suppose, most MUAs out there, work.) But this creates other
inconvenience for the user: this database takes space, takes time and
bandwidth to build, has to be re-built when the user changes device,
there is a security issue with having these e-mail headers stored
locally; not talking about the fact that it will make my software much
more complex for a single feature that really should, conceptually, be
implemented server side. Hence my willingness to actively try to find
compliant providers before giving up.

An alternative is to try to understand what exactly bugs in the
implementation of IMAP SEARCH of each of the main providers out there
(GMail; MS Exchange; and so on) and work around this on a case-by-case
basis. I suppose this has been investigated already by some developers;
if anybody knows where I could ask about this, I’d be very happy to ask
there, as I guess this discussion is becoming completely OT for this
list. 

But the general lack of support for remote search in well known
softwares such as Thunderbird (that seem to systematically perform
searches client-side, on the local database) makes me rather
pessimistic about the possibility of working around those bugs; after
all, if the server sometimes (or often) replies incorrectly, as my
tests indicate, there may be nothing the client can do to guess what
the right answer is.
--
Olivier