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.> 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". 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. 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. -- Piotr "Malgond" Auksztulewicz firstname at lastname.net
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
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