Providers running dovecot?

[Chris Bennett]

On Sat, Oct 10, 2020 at 04:31:07PM +0200, Olivier Cailloux wrote:
> 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
> 
> 

Some projects just can't get around the lack of compliance from vendors,
whether it's from incompetence or their not needing/desiring to do it.

Several years ago, I wanted to move lpd forward.
After weeks of looking at the hardware with non-compliance, I finally
just had to drop the project because it was truly a vast and
hopeless situation.
It was an excellent, but frustrating lesson.

I wish you luck, but you might be in the same spot I found myself.

Chris Bennett