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
