HIGHESTMODSEQ tracking

[Kostya Vasilyev]

2014-07-16 0:13 GMT+04:00 Michael M Slusarz <slusarz at curecanti.org>:

> Quoting Kostya Vasilyev <kmansoft at gmail.com>:
>
>>
>>
>> It seems you enjoy pointing out to people when they're "wrong" or
>> "incorrect" so much, you actually put meaning into their words that's not
>> there? Or it it just me?
>>
>
> I was just trying to point out that this statement is very
> dangerous/incorrect:
>
>
> "In any case, the point stands - with Gmail, it's much easier to be
> confident, from actual testing, that things works a certain way."
>
> Gmail behavior may/can/will change overnight, and you will have no idea.


Yes I will have a very good idea.

First, I use GMail myself, and second, I'll get messages from my users if
the changes cause something in my app to break.

And because Gmail's software is pretty much identical for everyone (less
the staged rollouts that I'm sure they use), I can see those changes very
easily (one such case happened just recently).

And not just for Gmail -- I get messages from users about other issues too,
and then I can react by:

-  putting a banner on my web site / forum (e.g. Yahoo recently letting
their SSL certificate for SMTP expire)

- or making changes to my software


>  It makes a lot more sense to pick a local server of a known version, that
> has deterministic behavior, to develop with.


For development, I use about a dozen test accounts, from Fastmail (probably
my overall favorite) to Gmail, Yahoo, Dovecot, Yandex, Hotmail, and a few
more that you've probably not heard of.

However, I'm not at liberty to pick mail servers  / services for my users.

Sometimes the decision is made for them by someone else -- a corporate mail
system, or a web hosting company.

Assuming latest versions of mail server software in those cases would be
foolish on my part.

And yes, sometimes I look at the app's network logs and tell the user "you
won't be able to do this, the server is broken".

However, I'd like to avoid such cases if I can, and sometimes have to
implement compatibility hacks.


>
>
>   For the "more than 50% market share" of Dovecot / Cyrus, do you have a
>>>
>>>> breakdown by version number? At least in terms of 1.* vs 2.0 and higher?
>>>>
>>>>
>>> I do not.
>>>
>>
>>
>> And without being able to get a version number from a Dovecot session (or
>> so it seems to me -- nothing returned from ID...).... it looks kind of
>> sad.
>>
>
> ID extension is pretty much worthless for version identification.  It is
> trivially spoofed -- and some servers do exactly this in the real world.
>  All it takes is one server/version to be spoofed to make that data
> worthless.
>

I'm not talking about doing it for security purposes, and for
compatibility, spoofing seems to me like less of an issue.

In the realm of technically possible, someone could even write a random
text generator and run it on port 993.

Why, GoDaddy has been doing exactly this for years, and they're even able
to charge their customers for it.



>
> It's possible to do some level of basic version sniffing by things like
> banner messages, Human-readable responses, CAPABILITY lists, and ordering
> of responses to various commands.  However, this is really only useful for
> broad statistical surveys and not precise version determination.
>

Well, in theory, CAPABILITY is all you need, because all mail servers /
services are strictly RFC compliant...

...and when they're not, they get fixed / upgraded very quickly...

...as soon as just one user relays a message from the developer of some
"random" mail app to the mail service's support.

Hahaha.

I'd feel more confident about enabling CONDSTORE / modseq for Dovecot if I
could exclude versions below 2.0, just to be safe. This has more practical
value to me than a statistical survey.

Oh well.

Anyway, this thread has gotten quite far off-topic, thanks again for
sharing your real-world experiences with Dovecot and its CONDSTORE / modseq
support.

-- K