mailing list archives

meli community discussions

⚠️ if something does not work as intended when interracting with the mailing lists,
reach out Github mirror Gitea repo @epilys:matrix.org

E-mail headers
From: Gilles LAMIRAL <gilles.lamiral@laposte.net>
To: imap-protocol@u.washington.edu
Date: Fri, 08 Jun 2018 12:34:54 -0000
Message-ID: 55109D4C.2080900@laposte.net permalink / raw / eml / mbox
Dear Imapeers,

I'm writing to discuss about thr OpenEmailSurvey project
http://www.openemailsurvey.org/

I got this link from Dovecot's CTO, Ville Savolainen. A few months ago
I asked Ville some questions about OpenEmailSurvey but he might be
busy running Dovecot businesses. No problem with that. This imap discussion
list may be a better place to get some answers and collaboration, more
people, more perspectives.

My main goal is to add a wizard mode to imapsync, a mode where options
for specific imap servers are set automagically. Avoiding that users
and I always read and apply the same FAQ items is a user experience
improvement I aim.

It looks like the OpenEmailSurvey project is tremendous for that
purpose. So I have questions about it.

Do you share on OpenEmailSurvey project?
Is there a mailing-list or similar?
Are code or principles to detect real imap server softwares open?

When users ask me about problems with imap servers they even don't
know the software name, I usually look at the CAPABILITY response,
NAMESPACE, some other imap responses or some nmap service detection.
I always get the name of it. I haven't formalized it yet in a script,
I've played by hand for now, not so often. I'm lazy, so before doing
it all by myself I ask you if I'll have to reinvent the wheel or not
on that matter.

My other questions about OpenEmailSurvey, less important for my
purpose, are the followings:

100% IPv4 scanned is claimed: How do you deal with abuse reports?
What means a crossed out imap server on
http://www.openemailsurvey.org/ ?

In fact, I  started a similar project some years ago (2008). It was
quite efficient, millions of servers scanned everyday from a small
connexion. But I encountered warning issues from my ISP, abuse
complains. It was a pure statistical study but I finally named it Scanty
and put it somewhere with ideas to avoid those abuse complains, ideas
like reverse resolution ok (PTR), abuse complains IP list hardcoded
("never come back here"), whois resolution, don't come back too often
etc.

At that time, 2008, I got around 0.24% of all hosts with port 143 open
on imap while OpenEmailSurvey scored 0.1% in 2013. It looks like Gmail and Big
cloud webmails have stolen half of the imap market share.

Thanks in advance for your input.


-- 
Au revoir,                             09 51 84 42 42
Gilles Lamiral. France, Baulon (35580) 06 20 79 76 06
Reply
E-mail headers
From: tss@iki.fi
To: imap-protocol@localhost
Date: Fri, 08 Jun 2018 12:34:54 -0000
Message-ID: 7C224ADC-D72B-4D77-8320-4D9D94C508DF@iki.fi permalink / raw / eml / mbox
On 24 Mar 2015, at 08:10, Gilles LAMIRAL <gilles.lamiral@laposte.net> wrote:

> My main goal is to add a wizard mode to imapsync, a mode where options
> for specific imap servers are set automagically. Avoiding that users
> and I always read and apply the same FAQ items is a user experience
> improvement I aim.

What kind of options? In theory you should get everything from CAPABILITY and NAMESPACE replies of course. This kind of detection sounds very much like what the ID extension RFC says MUST NOT be used for any behavioral differences. But I suppose in practise it may be useful/necessary sometimes.

> Do you share on OpenEmailSurvey project?
> Is there a mailing-list or similar?
> Are code or principles to detect real imap server softwares open?

Not really. It sends a couple of IMAP commands to server (capability, id, unknowncmd, logout) and saves the unique replies to database. Then with some manual work and scripts the different replies are assigned to different servers. Ugly and time consuming work that I wouldn't recommend for any IMAP client developers to use.

An old mapping list is available in http://www.imapwiki.org/Specs/Raw but a new one would require some SQL database dump and maybe some other things..

> My other questions about OpenEmailSurvey, less important for my
> purpose, are the followings:
> 
> 100% IPv4 scanned is claimed: How do you deal with abuse reports?

In earlier years there weren't that many of them and we added the reported networks to the zmap blacklist, but this year there were enough of them to stop the scan entirely. Anybody want to host such a scan? :) Or maybe it would work to just make it run more slowly..

> What means a crossed out imap server on
> http://www.openemailsurvey.org/ ?

Software used by only a single service provider. Possibly only an IMAP proxy, but maybe also a backend. We only bothered to add that to a couple of providers with a ton of IP addresses.
Reply
E-mail headers
From: brong@fastmail.fm
To: imap-protocol@localhost
Date: Fri, 08 Jun 2018 12:34:54 -0000
Message-ID: 1427153195.246194.244290758.41EF7C3D@webmail.messagingengine.com permalink / raw / eml / mbox
On Tue, Mar 24, 2015, at 10:10 AM, Gilles LAMIRAL wrote:
> At that time, 2008, I got around 0.24% of all hosts with port 143 open
> on imap while OpenEmailSurvey scored 0.1% in 2013. It looks like Gmail and Big
> cloud webmails have stolen half of the imap market share.

I wonder how many sites there are where you just can't tell anyway.

FastMail doesn't even listen on port 143, because it leaks cleartext passwords to active attackers:

https://www.fastmail.com/help/technical/ssltlsstarttls.html

And even once you try port 993:

* OK IMAP4 ready
. CAPABILITY
* CAPABILITY IMAP4 IMAP4rev1 LITERAL+ ID ENABLE UIDPLUS SASL-IR AUTH=PLAIN
. OK completed

You're talking to nginx.  It's only once you log in that you see what's really there:

. OK [CAPABILITY IMAP4rev1 LITERAL+ ID ENABLE ACL RIGHTS=kxten QUOTA MAILBOX-REFERRALS NAMESPACE UIDPLUS NO_ATOMIC_RENAME UNSELECT CHILDREN MULTIAPPEND BINARY CATENATE CONDSTORE ESEARCH SEARCH=FUZZY SORT SORT=MODSEQ SORT=DISPLAY SORT=UID THREAD=ORDEREDSUBJECT THREAD=REFERENCES ANNOTATEMORE ANNOTATE-EXPERIMENT-1 METADATA LIST-EXTENDED LIST-STATUS LIST-MYRIGHTS WITHIN QRESYNC SCAN XLIST XMOVE MOVE SPECIAL-USE CREATE-SPECIAL-USE DIGEST=SHA1 LOGINDISABLED XCONVERSATIONS COMPRESS=DEFLATE X-QUOTA=STORAGE X-QUOTA=MESSAGE X-QUOTA=X-ANNOTATION-STORAGE X-QUOTA=X-NUM-FOLDERS IDLE] User logged in SESSIONID=<sloti30t15-1470551-1427153102-1-6352514379123523087>

Bron.

-- 
  Bron Gondwana
  brong@fastmail.fm
Reply
E-mail headers
From: Pidgeot18@verizon.net
To: imap-protocol@localhost
Date: Fri, 08 Jun 2018 12:34:54 -0000
Message-ID: 5510BC3A.9020702@verizon.net permalink / raw / eml / mbox
On 3/23/2015 6:10 PM, Gilles LAMIRAL wrote:
> My main goal is to add a wizard mode to imapsync, a mode where options
> for specific imap servers are set automagically. Avoiding that users
> and I always read and apply the same FAQ items is a user experience
> improvement I aim.

I don't know what options you're talking about, but it's worth pointing 
out the Thunderbird autoconfiguration project 
(<https://developer.mozilla.org/en-US/docs/Mozilla/Thunderbird/Autoconfiguration>).
> When users ask me about problems with imap servers they even don't
> know the software name, I usually look at the CAPABILITY response,
> NAMESPACE, some other imap responses or some nmap service detection.
> I always get the name of it. I haven't formalized it yet in a script,
> I've played by hand for now, not so often. I'm lazy, so before doing
> it all by myself I ask you if I'll have to reinvent the wheel or not
> on that matter.

If IMAP ID is supported, that is a useful command to use.

-- 
Beware of bugs in the above code; I have only proved it correct, not tried it. -- Donald E. Knuth
Reply
E-mail headers
From: arnt@gulbrandsen.priv.no
To: imap-protocol@localhost
Date: Fri, 08 Jun 2018 12:34:54 -0000
Message-ID: 184d5bde-ee73-4ad5-b38b-62e86338d7ad@gulbrandsen.priv.no permalink / raw / eml / mbox
Timo Sirainen writes:
> What kind of options? In theory you should get everything from 
> CAPABILITY and NAMESPACE replies of course. This kind of 
> detection sounds very much like what the ID extension RFC says 
> MUST NOT be used for any behavioral differences. But I suppose 
> in practise it may be useful/necessary sometimes.

Imapsync has options for things that neither of those describe, e.g. choice 
of message equality test. I think that for imapsync, it makes a great deal 
of sense to have a --suggest or --autodetect options that says ID to both 
servers and then offers a suggested command line for transferring mail.

Arnt
Reply
E-mail headers
From: tss@iki.fi
To: imap-protocol@localhost
Date: Fri, 08 Jun 2018 12:34:54 -0000
Message-ID: 795C98A0-7472-49BD-AA69-D3B6A357472B@iki.fi permalink / raw / eml / mbox
On 24 Mar 2015, at 08:26, Bron Gondwana <brong@fastmail.fm> wrote:
> 
> On Tue, Mar 24, 2015, at 10:10 AM, Gilles LAMIRAL wrote:
>> At that time, 2008, I got around 0.24% of all hosts with port 143 open
>> on imap while OpenEmailSurvey scored 0.1% in 2013. It looks like Gmail and Big
>> cloud webmails have stolen half of the imap market share.
> 
> I wonder how many sites there are where you just can't tell anyway.
> 
> FastMail doesn't even listen on port 143, because it leaks cleartext passwords to active attackers:
> 
> https://www.fastmail.com/help/technical/ssltlsstarttls.html

openemailsurvey.org main page results contains both 143 + 993 results deduplicated. There are actually also pages for them separately:

http://openemailsurvey.org/imap-143.html
http://openemailsurvey.org/imap-993.html

The 993 port page is before the nicer stats, but I think still from the same year's results.

> And even once you try port 993:
> 
> * OK IMAP4 ready
> . CAPABILITY
> * CAPABILITY IMAP4 IMAP4rev1 LITERAL+ ID ENABLE UIDPLUS SASL-IR AUTH=PLAIN
> . OK completed
> 
> You're talking to nginx.  It's only once you log in that you see what's really there:

Yeah, that's a limitation. But it's still detecting nginx and according to last year's scan there were 0,06% nginx proxies so it doesn't change the results much.
Reply
E-mail headers
From: gilles.lamiral@laposte.net
To: imap-protocol@localhost
Date: Fri, 08 Jun 2018 12:34:54 -0000
Message-ID: 5510BB04.8070407@laposte.net permalink / raw / eml / mbox
Hello Bron,

> I wonder how many sites there are where you just can't tell anyway.

We can.

> FastMail doesn't even listen on port 143, because it leaks cleartext passwords to active attackers:
> https://www.fastmail.com/help/technical/ssltlsstarttls.html
> And even once you try port 993:

Port 993 was imap open 0.16% of all hosts in 2008.

Now you can suggest, "how about hosts opening their port on any unwell unknown ports?"
I don't care since market shares will be the same, same proportions.
I let you the big scan as an exercise, and its abuse complaints as well.

-- 
Au revoir,                             09 51 84 42 42
Gilles Lamiral. France, Baulon (35580) 06 20 79 76 06
Reply
E-mail headers
From: lyndon@orthanc.ca
To: imap-protocol@localhost
Date: Fri, 08 Jun 2018 12:34:54 -0000
Message-ID: F90D4251-9EE1-493B-8A5F-31B8A1B41B87@orthanc.ca permalink / raw / eml / mbox
> . OK [CAPABILITY IMAP4rev1 LITERAL+ ID ENABLE ACL RIGHTS=kxten QUOTA MAILBOX-REFERRALS NAMESPACE UIDPLUS NO_ATOMIC_RENAME UNSELECT CHILDREN MULTIAPPEND BINARY CATENATE CONDSTORE ESEARCH SEARCH=FUZZY SORT SORT=MODSEQ SORT=DISPLAY SORT=UID THREAD=ORDEREDSUBJECT THREAD=REFERENCES ANNOTATEMORE ANNOTATE-EXPERIMENT-1 METADATA LIST-EXTENDED LIST-STATUS LIST-MYRIGHTS WITHIN QRESYNC SCAN XLIST XMOVE MOVE SPECIAL-USE CREATE-SPECIAL-USE DIGEST=SHA1 LOGINDISABLED XCONVERSATIONS COMPRESS=DEFLATE X-QUOTA=STORAGE X-QUOTA=MESSAGE X-QUOTA=X-ANNOTATION-STORAGE X-QUOTA=X-NUM-FOLDERS IDLE]

The number of extensions to this protocol is completely out of control :-P

I would like to see a survey taken of how many clients actually make use of this cornucopia of enhancements to 3516.  I'm pretty sure some of the older cruft could be deprecated without causing major inconvenience.  I'm game to instrument our servers to start collecting data[1]?  Anyone else interested?

--lyndon

[1] pending management signoff, but I don't think that will be a problem.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 817 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mailman13.u.washington.edu/pipermail/imap-protocol/attachments/20150323/a1ff5bda/attachment.sig>
Reply
E-mail headers
From: gilles.lamiral@laposte.net
To: imap-protocol@localhost
Date: Fri, 08 Jun 2018 12:34:54 -0000
Message-ID: 5511EDA6.7060107@laposte.net permalink / raw / eml / mbox
Dear Joshua,

> I don't know what options you're talking about, but it's worth pointing out the Thunderbird autoconfiguration project
> (<https://developer.mozilla.org/en-US/docs/Mozilla/Thunderbird/Autoconfiguration>).

I'll have a look at Thunderbird/Autoconfiguration,
even if I go crazy when I configure a new account with Thunderbird,
it is always irrelevant for what I do, the manual way is first hidden,
maybe presented at the end or after a failure, a headache each time.

I won't start searching the imap hostname from the user login parameter.
I'll start by guessing server software name from the imap responses,
not from a third party scan, and from hard coded rules if possible.

> If IMAP ID is supported, that is a useful command to use.

A server that replied well to ID would have already announced itself
in the first banner. So, for my purpose, ID looks useful when useless.

But thanks to mention ID, I'll add it in imapsync, this way Gmail
and Outlook.com  will be able to know easily how many transfers are made
by imapsync each day (not difficult without ID anyway).


-- 
Au revoir,                             09 51 84 42 42
Gilles Lamiral. France, Baulon (35580) 06 20 79 76 06
Reply
E-mail headers
From: lyndon@orthanc.ca
To: imap-protocol@localhost
Date: Fri, 08 Jun 2018 12:34:54 -0000
Message-ID: D76B576F-CCF8-4AA8-8C7F-71DE89B490B1@orthanc.ca permalink / raw / eml / mbox
On Mar 23, 2015, at 6:42 PM, Lyndon Nerenberg <lyndon@orthanc.ca> wrote:

> 3516

3501. Doh!  (Yes, I contributed to this mess.)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 817 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mailman13.u.washington.edu/pipermail/imap-protocol/attachments/20150323/9aa4486c/attachment.sig>
Reply
E-mail headers
From: brong@fastmail.fm
To: imap-protocol@localhost
Date: Fri, 08 Jun 2018 12:34:54 -0000
Message-ID: 1427226341.922442.244719958.3B420059@webmail.messagingengine.com permalink / raw / eml / mbox
On Tue, Mar 24, 2015, at 12:42 PM, Lyndon Nerenberg wrote:
> > . OK [CAPABILITY IMAP4rev1 LITERAL+ ID ENABLE ACL RIGHTS=kxten QUOTA MAILBOX-REFERRALS NAMESPACE UIDPLUS NO_ATOMIC_RENAME UNSELECT CHILDREN MULTIAPPEND BINARY CATENATE CONDSTORE ESEARCH SEARCH=FUZZY SORT SORT=MODSEQ SORT=DISPLAY SORT=UID THREAD=ORDEREDSUBJECT THREAD=REFERENCES ANNOTATEMORE ANNOTATE-EXPERIMENT-1 METADATA LIST-EXTENDED LIST-STATUS LIST-MYRIGHTS WITHIN QRESYNC SCAN XLIST XMOVE MOVE SPECIAL-USE CREATE-SPECIAL-USE DIGEST=SHA1 LOGINDISABLED XCONVERSATIONS COMPRESS=DEFLATE X-QUOTA=STORAGE X-QUOTA=MESSAGE X-QUOTA=X-ANNOTATION-STORAGE X-QUOTA=X-NUM-FOLDERS IDLE]
> 
> The number of extensions to this protocol is completely out of control :-P

Of these, a bunch are non-standard / never been standardised.

X-QUOTA types.
XMOVE and MOVE are both there - I could probably remove XMOVE except I still have code that uses it.
DIGEST=SHA1 an XCONVERSATIONS are both very FastMail specific
LIST-MYRIGHTS is one of the various LIST things to make more efficient use of the server and avoid some pipelining, in Cyrus at least we already have the ACL loaded when we do a LIST command, so spitting it out right there can be done without re-parsing and potentially re-calculating group membership.

> I would like to see a survey taken of how many clients actually make use of this cornucopia of enhancements to 3516.  I'm pretty sure some of the older cruft could be deprecated without causing major inconvenience.  I'm game to instrument our servers to start collecting data[1]?  Anyone else interested?

I'm interested too actually - I should instrument counts on all the commands that the server supports.

Bron.

-- 
  Bron Gondwana
  brong@fastmail.fm
Reply
E-mail headers
From: brong@fastmail.fm
To: imap-protocol@localhost
Date: Fri, 08 Jun 2018 12:34:54 -0000
Message-ID: 1427238946.968483.244801809.1E105795@webmail.messagingengine.com permalink / raw / eml / mbox
On Wed, Mar 25, 2015, at 10:05 AM, Gilles LAMIRAL wrote:
> Dear Joshua,
> 
> > I don't know what options you're talking about, but it's worth pointing out the Thunderbird autoconfiguration project
> > (<https://developer.mozilla.org/en-US/docs/Mozilla/Thunderbird/Autoconfiguration>).
> 
> I'll have a look at Thunderbird/Autoconfiguration,
> even if I go crazy when I configure a new account with Thunderbird,
> it is always irrelevant for what I do, the manual way is first hidden,
> maybe presented at the end or after a failure, a headache each time.
> 
> I won't start searching the imap hostname from the user login parameter.
> I'll start by guessing server software name from the imap responses,
> not from a third party scan, and from hard coded rules if possible.

https://tools.ietf.org/html/rfc6186 might be your friend too.

> > If IMAP ID is supported, that is a useful command to use.
> 
> A server that replied well to ID would have already announced itself
> in the first banner. So, for my purpose, ID looks useful when useless.
> 
> But thanks to mention ID, I'll add it in imapsync, this way Gmail
> and Outlook.com  will be able to know easily how many transfers are made
> by imapsync each day (not difficult without ID anyway).

We like ID commands at FastMail too - we log them and it gives us both an
idea of usage patterns, and the ability to give more accurate bug reports if we
detect something weird.

Bron.

-- 
  Bron Gondwana
  brong@fastmail.fm
Reply
E-mail headers
From: lyndon@orthanc.ca
To: imap-protocol@localhost
Date: Fri, 08 Jun 2018 12:34:54 -0000
Message-ID: E26991B1-5DB7-49D0-A2D2-6A2DB6492528@orthanc.ca permalink / raw / eml / mbox
On Mar 24, 2015, at 4:05 PM, Gilles LAMIRAL <gilles.lamiral@laposte.net> wrote:

> when I configure a new account with Thunderbird,
> it is always irrelevant for what I do, the manual way is first hidden,
> maybe presented at the end or after a failure, a headache each time.

Amem :-(
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 817 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mailman13.u.washington.edu/pipermail/imap-protocol/attachments/20150324/a6e5e5bb/attachment.sig>
Reply
E-mail headers
From: lyndon@orthanc.ca
To: imap-protocol@localhost
Date: Fri, 08 Jun 2018 12:34:54 -0000
Message-ID: 2FC3E597-358B-4F71-B1F6-68A18C85DB51@orthanc.ca permalink / raw / eml / mbox
On Mar 24, 2015, at 12:45 PM, Bron Gondwana <brong@fastmail.fm> wrote:

> Of these, a bunch are non-standard / never been standardised.

Yes, I noticed.  But there are still a butt-load of RFC extensions that deserve review, I think.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 817 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mailman13.u.washington.edu/pipermail/imap-protocol/attachments/20150324/b344551f/attachment.sig>
Reply
E-mail headers
From: blong@google.com
To: imap-protocol@localhost
Date: Fri, 08 Jun 2018 12:34:54 -0000
Message-ID: CABa8R6t5BB99WbXk0UkVv5h6URn6kpE5jfftHrAKuNtxZFMXXg@mail.gmail.com permalink / raw / eml / mbox
On Tue, Mar 24, 2015 at 4:15 PM, Bron Gondwana <brong@fastmail.fm> wrote:

> On Wed, Mar 25, 2015, at 10:05 AM, Gilles LAMIRAL wrote:
> > Dear Joshua,
> >
> > > I don't know what options you're talking about, but it's worth
> pointing out the Thunderbird autoconfiguration project
> > > (<
> https://developer.mozilla.org/en-US/docs/Mozilla/Thunderbird/Autoconfiguration
> >).
> >
> > I'll have a look at Thunderbird/Autoconfiguration,
> > even if I go crazy when I configure a new account with Thunderbird,
> > it is always irrelevant for what I do, the manual way is first hidden,
> > maybe presented at the end or after a failure, a headache each time.
> >
> > I won't start searching the imap hostname from the user login parameter.
> > I'll start by guessing server software name from the imap responses,
> > not from a third party scan, and from hard coded rules if possible.
>
> https://tools.ietf.org/html/rfc6186 might be your friend too.
>
> > > If IMAP ID is supported, that is a useful command to use.
> >
> > A server that replied well to ID would have already announced itself
> > in the first banner. So, for my purpose, ID looks useful when useless.
> >
> > But thanks to mention ID, I'll add it in imapsync, this way Gmail
> > and Outlook.com  will be able to know easily how many transfers are made
> > by imapsync each day (not difficult without ID anyway).
>
> We like ID commands at FastMail too - we log them and it gives us both an
> idea of usage patterns, and the ability to give more accurate bug reports
> if we
> detect something weird.


We also show it to users in their activity log, which is helpful so they
know what was connecting.

Its also helpful when we need to track down a developer and have a
discussion about what they're doing.



Brandon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman13.u.washington.edu/pipermail/imap-protocol/attachments/20150324/8662aef0/attachment.html>
Reply
E-mail headers
From: asuth@mozilla.com
To: imap-protocol@localhost
Date: Fri, 08 Jun 2018 12:34:54 -0000
Message-ID: CALFQBW2BxiB_CCKtg+VsfQsG25LyQeoi67n1UXqn3SUv8dqJsQ@mail.gmail.com permalink / raw / eml / mbox
On Tue, Mar 24, 2015 at 7:15 PM, Bron Gondwana <brong@fastmail.fm> wrote:

> We like ID commands at FastMail too - we log them and it gives us both an
> idea of usage patterns, and the ability to give more accurate bug reports
> if we
> detect something weird.
>

And some servers can be downright aggressive about.  The Firefox OS email
app experienced the Coremail IMAP servers at 163.com (and presumably all
netease-operated servers) doing things like saying "NO" to a SELECT with
the human-readable string "SELECT The login is not safe! Please update your
mail client: http://mail.163.com/dashi" when we weren't providing a (valid)
ID.  The NO to the select only happened some of the time, but the login
would result in an ad for 163.com's Android/iOS mail clients being injected
into the inbox with apparently very limited duplicate suppression.  Note
that we were using initial-TLS on port 993 with then-current Gecko/NSS.
Some more details at https://bugzilla.mozilla.org/show_bug.cgi?id=1105573
for anyone interested.

Andrew
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman13.u.washington.edu/pipermail/imap-protocol/attachments/20150324/074a44e5/attachment.html>
Reply
E-mail headers
From: brong@fastmail.fm
To: imap-protocol@localhost
Date: Fri, 08 Jun 2018 12:34:54 -0000
Message-ID: 1427252504.1020832.244866921.0886703A@webmail.messagingengine.com permalink / raw / eml / mbox
On Wed, Mar 25, 2015, at 01:51 PM, Lyndon Nerenberg wrote:
> 
> On Mar 24, 2015, at 12:45 PM, Bron Gondwana <brong@fastmail.fm> wrote:
> 
> > Of these, a bunch are non-standard / never been standardised.
> 
> Yes, I noticed.  But there are still a butt-load of RFC extensions that deserve review, I think.

Honestly the simplest thing is what was discussed years ago on the imap5 list, just picking
all the ones which really matter and get significant use, bunding them behind "IMAP5" and
replacing all the other capabilities with just IMAP5.

It has the plus sides of:

a) shorter capability strings
b) a base standard of stuff you have to support to be allowed to claim to be IMAP5

(I would include QRESYNC in that though, or go back and address the expunged hole in condstore)

Bron.

-- 
  Bron Gondwana
  brong@fastmail.fm
Reply
E-mail headers
From: stuart.brandt@teamaol.com
To: imap-protocol@localhost
Date: Fri, 08 Jun 2018 12:34:54 -0000
Message-ID: 5511FC91.2040801@teamaol.com permalink / raw / eml / mbox
Another vote for clients using ID!

It's particularly bothersome with AWS or other cloud hosted email client 
implementations that don't use OAuth2. Only way to truly stop 
unrecognized access is to change password, but then you have to deal 
with repeated accesses that look like cloud originated password cracking 
attempts.

Stuart

On 3/24/15 7:28 PM, Brandon Long wrote:
>
>
> On Tue, Mar 24, 2015 at 4:15 PM, Bron Gondwana <brong@fastmail.fm 
> <mailto:brong@fastmail.fm>> wrote:
>
>     On Wed, Mar 25, 2015, at 10:05 AM, Gilles LAMIRAL wrote:
>     > Dear Joshua,
>     >
>     > > I don't know what options you're talking about, but it's worth
>     pointing out the Thunderbird autoconfiguration project
>     > >
>     (<https://developer.mozilla.org/en-US/docs/Mozilla/Thunderbird/Autoconfiguration>).
>     >
>     > I'll have a look at Thunderbird/Autoconfiguration,
>     > even if I go crazy when I configure a new account with Thunderbird,
>     > it is always irrelevant for what I do, the manual way is first
>     hidden,
>     > maybe presented at the end or after a failure, a headache each time.
>     >
>     > I won't start searching the imap hostname from the user login
>     parameter.
>     > I'll start by guessing server software name from the imap responses,
>     > not from a third party scan, and from hard coded rules if possible.
>
>     https://tools.ietf.org/html/rfc6186 might be your friend too.
>
>     > > If IMAP ID is supported, that is a useful command to use.
>     >
>     > A server that replied well to ID would have already announced itself
>     > in the first banner. So, for my purpose, ID looks useful when
>     useless.
>     >
>     > But thanks to mention ID, I'll add it in imapsync, this way Gmail
>     > and Outlook.com  will be able to know easily how many transfers
>     are made
>     > by imapsync each day (not difficult without ID anyway).
>
>     We like ID commands at FastMail too - we log them and it gives us
>     both an
>     idea of usage patterns, and the ability to give more accurate bug
>     reports if we
>     detect something weird.
>
>
> We also show it to users in their activity log, which is helpful so 
> they know what was connecting.
>
> Its also helpful when we need to track down a developer and have a 
> discussion about what they're doing.
>
>
>
> Brandon
>
>
>
> _______________________________________________
> Imap-protocol mailing list
> Imap-protocol@u.washington.edu
> http://mailman13.u.washington.edu/mailman/listinfo/imap-protocol

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman13.u.washington.edu/pipermail/imap-protocol/attachments/20150324/a9bdb2b6/attachment.html>
Reply
E-mail headers
From: brong@fastmail.fm
To: imap-protocol@localhost
Date: Fri, 08 Jun 2018 12:34:54 -0000
Message-ID: 1427242315.980300.244819753.01E1D55F@webmail.messagingengine.com permalink / raw / eml / mbox
On Wed, Mar 25, 2015, at 10:47 AM, Andrew Sutherland wrote:
> On Tue, Mar 24, 2015 at 7:15 PM, Bron Gondwana
> <brong@fastmail.fm> wrote:
>> We like ID commands at FastMail too - we log them and it gives us
>> both an
>>
idea of usage patterns, and the ability to give more accurate bug
reports if we
>>
detect something weird.
>
> And some servers can be downright aggressive about. The Firefox OS
> email app experienced the Coremail IMAP servers at 163.com (and
> presumably all netease-operated servers) doing things like saying "NO"
> to a SELECT with the human-readable string "SELECT The login is not
> safe! Please update your mail client: http://mail.163.com/dashi" when
> we weren't providing a (valid) ID. The NO to the select only happened
> some of the time, but the login would result in an ad for 163.com's
> Android/iOS mail clients being injected into the inbox with apparently
> very limited duplicate suppression. Note that we were using
> initial-TLS on port 993 with then-current Gecko/NSS. Some more details
> at https://bugzilla.mozilla.org/show_bug.cgi?id=1105573 for anyone
> interested.

Woah, that's really obnoxious.

Are you certain that it's related to the ID command rather than a
general random percentage of connections advertisement?

Bron.


--
Bron Gondwana brong@fastmail.fm


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman13.u.washington.edu/pipermail/imap-protocol/attachments/20150325/7f0d6105/attachment.html>
Reply
E-mail headers
From: gilles.lamiral@laposte.net
To: imap-protocol@localhost
Date: Fri, 08 Jun 2018 12:34:54 -0000
Message-ID: 55120288.5060502@laposte.net permalink / raw / eml / mbox
Hi Andrew,

> >     We like ID commands
>
> And some servers can be downright aggressive about.

So it will end with fake IDs or none.

-- 
Au revoir,                             09 51 84 42 42
Gilles Lamiral. France, Baulon (35580) 06 20 79 76 06
Reply
E-mail headers
From: lyndon@orthanc.ca
To: imap-protocol@localhost
Date: Fri, 08 Jun 2018 12:34:54 -0000
Message-ID: 2DDE9D54-577E-4DA7-99D6-1A531E9C86E0@orthanc.ca permalink / raw / eml / mbox
On Mar 24, 2015, at 8:01 PM, Bron Gondwana <brong@fastmail.fm> wrote:

> Honestly the simplest thing is what was discussed years ago on the imap5 list, just picking
> all the ones which really matter and get significant use, bunding them behind "IMAP5" and
> replacing all the other capabilities with just IMAP5.

But that resets the whole standards track progression.  I would rather we marked the unused extensions as Historic, then cleaned up the bugs in the rest and moved the whole mess forwards towards actual Standard status.  We certainly have enough implementation and interop experience to make this viable.

Proposing an IMAP5 would just let loose a bucket of snakes that would never get herded back into any sort of container.

--lyndon

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 817 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mailman13.u.washington.edu/pipermail/imap-protocol/attachments/20150324/627f5787/attachment.sig>
Reply
E-mail headers
From: asuth@mozilla.com
To: imap-protocol@localhost
Date: Fri, 08 Jun 2018 12:34:54 -0000
Message-ID: CALFQBW0QaBWDXgbXuswiB-UCJd9G_D8Gxkm+fjhCtU+RyUq9_w@mail.gmail.com permalink / raw / eml / mbox
On Tue, Mar 24, 2015 at 8:11 PM, Bron Gondwana <brong@fastmail.fm> wrote:

>  Are you certain that it's related to the ID command rather than a
> general random percentage of connections advertisement?
>

I am not certain.  I was unable to find any discussion/documentation of
this phenomenon on the net and my initial attempts to find contact points
did not bear fruit.  Since using ID made the problem go away as far as I
could tell, I did not pursue further escalation/contact.

However, given that QA of Firefox OS device producers seem to test 163.com
a lot and I received a duplicate of the bug for our v2.0 branch that did
not include the fix (https://bugzil.la/1112549) ~2 weeks after the fix
landed on our v2.1/v2.2 branches, it's probably not the worst guess.

Andrew
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman13.u.washington.edu/pipermail/imap-protocol/attachments/20150324/a0ce5ad2/attachment.html>
Reply
E-mail headers
From: brong@fastmail.fm
To: imap-protocol@localhost
Date: Fri, 08 Jun 2018 12:34:54 -0000
Message-ID: 1427250117.1005085.244856813.6CC2DA89@webmail.messagingengine.com permalink / raw / eml / mbox
On Wed, Mar 25, 2015, at 12:07 PM, Andrew Sutherland wrote:
> On Tue, Mar 24, 2015 at 8:11 PM, Bron Gondwana
> <brong@fastmail.fm> wrote:
>> __
>> Are you certain that it's related to the ID command rather than a
>> general random percentage of connections advertisement?
>
> I am not certain. I was unable to find any discussion/documentation of
> this phenomenon on the net and my initial attempts to find contact
> points did not bear fruit. Since using ID made the problem go away as
> far as I could tell, I did not pursue further escalation/contact.
>
> However, given that QA of Firefox OS device producers seem to test
> 163.com a lot and I received a duplicate of the bug for our v2.0
> branch that did not include the fix (https://bugzil.la/1112549) ~2
> weeks after the fix landed on our v2.1/v2.2 branches, it's probably
> not the worst guess.

Presumably somebody from 163.com could actually clear up the confusion
if they chose to.

Bron.

--
Bron Gondwana brong@fastmail.fm


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman13.u.washington.edu/pipermail/imap-protocol/attachments/20150325/dee4b59c/attachment.html>
Reply