configurar - ¿Qué protocolo usa Google para Gmail?(no IMAP o POP)

servidor pop3 gmail

Question

Puede acceder a gmail mediante la interfaz web, el cliente de Android de Google o mediante IMAP. Por lo que puedo decir, la interfaz web y la aplicación de Android utilizan un protocolo completamente diferente al IMAP: no son solo interfaces encima de eso. La razón por la que estoy seguro es que la aplicación de Android puede sin problemas abrir una carpeta con 1m de correo en <3 segundos. Ningún cliente IMAP simple puede hacer eso.

¿Entonces mi pregunta es qué se sabe sobre este protocolo secreto? ¿Dónde está la documentación de referencia para ello? ¿Se ha realizado ingeniería inversa? ¿Google sanciona su uso?

La respuesta de arnt proporciona un método excelente para probar la velocidad bruta de imap de gmail:

$ openssl s_client -host imap.gmail.com -port 993 -crlf 
...
* OK Gimap ready for requests from 12.34.56.78
$ a LOGIN ***@*** ***
a OK
$ c SELECT "[Gmail]/All mail" !!!!
* FLAGS (/Answered /Flagged /Draft /Deleted /Seen)
* OK [PERMANENTFLAGS (/Answered /Flagged /Draft /Deleted /Seen /*)] Flags permitted.
* OK [UIDVALIDITY 673376278] UIDs valid.
* 1142417 EXISTS
* 0 RECENT
* OK [UIDNEXT 1159771] Predicted next UID.
* OK [HIGHESTMODSEQ 8670601]
c OK [READ-WRITE] [Gmail]/All mail selected. (Success)

El comando que he marcado, c SELECT "[Gmail]/All mail" tarda unos 20 segundos en completarse. Dado que ese tiempo es mayor de lo que se necesita para la aplicación GMail en mi teléfono Android con poca potencia para iniciar y cargar la etiqueta de Todo correo que lo hace en menos de 6 segundos, incluso después de que purgue sus cachés. El cliente web es aún más rápido.

A menos que me esté perdiendo algo básico, esto prueba "más allá de toda duda razonable" que los clientes de GMail de Google no usan IMAP, ya que nunca tendrá que esperar 20 segundos para que se complete ningún comando SELECT.

Answer 1

"Ningún otro cliente IMAP puede hacer esto" es una declaración bastante audaz, pero un millón de mensajes también es un número bastante grande. Te animo a que pruebes Trojitá aquí. Lo más probable es que la sincronización inicial sea bastante lenta (transferiría los indicadores para ese millón de mensajes por varias razones técnicas relacionadas con la forma en que se especifican los indicadores IMAP, SELECT , SEARCH y STATUS ), pero la resincronización posterior debería ser muy rápida gracias a CONDSTORE , CONDSTORE y QRESYNC . Me interesaría saber qué tan bien funciona Trojitá con su configuración: la información de contacto se encuentra en la página de inicio.

A su pregunta, la mayoría de los correos electrónicos en la actualidad ofrecen una API privada para su propio uso. Una arquitectura típica es transferir mensajes sobre el estado actualizado a través de JSON, pero no hay un estándar para esto y la interfaz es de propiedad exclusiva. Lo más probable es que la "aplicación" de GMail utilice el mismo método (o similar). No tiene muchas opciones para verificar esto, ya que es probable que esté usando TLS. Con una interfaz web, es trivial ver el tráfico con un complemento de navegador adecuado, pero no tanto con una aplicación de Android independiente.

Answer 2

Después de más investigaciones, descubrí que existe una API para GMail: developers.google.com/gmail/api No creo que la API se haya lanzado cuando publiqué esta pregunta en 2013.

Usando esa API, he creado un programa de demostración que recupera los últimos 100 correos de una etiqueta: https://gist.github.com/bjourne/37a9d15b03862003008a1b0169190dbe

La parte relevante del programa es:

resource = service.users().messages()
result = resource.list(userId = ''me'', labelIds = [label]).execute()
mail_ids = [m[''id''] for m in result[''messages'']]

start = time()
mails = []
batch = BatchHttpRequest()
cb = lambda req, res, exc: mails.append(to_mail(res))
for mail_id in mail_ids:
    get_request = resource.get(**headers_params(mail_id))
    batch.add(get_request, callback = cb)
result = batch.execute()
print(''Took %.2f seconds'' % (time() - start))

Enumera los últimos 100 mensajes ordenados por fecha en una etiqueta (carpeta en terminología IMAP) que contiene más de 570k mensajes.

En mi máquina, este bucle toma alrededor de 0.5 - 0.8 segundos. Puedo afirmar con confianza que ningún cliente IMAP puro en el planeta se acerca siquiera. Probablemente, IMAP nunca se volverá más rápido porque no se ajusta a la manera en que Google almacena el correo internamente.

Así que voy a responder a mi propia pregunta. Esta es la API que están utilizando y no se expuso anteriormente.

Answer 3

La aplicación de Android (al menos las que he usado) usa IMAP. Puede verificar esto ejecutando Wireshark en el servidor.

En cuanto a por qué la aplicación de Android es tan rápida, lo que sé es que utiliza el comando SEARCH para seleccionar los n mensajes más recientes. Los clientes de escritorio como Thunderbird o Outlook son mucho más pesados ​​y descargan encabezados y metadatos para cada mensaje en la carpeta, a pesar de las recomendaciones para ellos.

Un teléfono inteligente no tiene los recursos para almacenar y procesar millones de mensajes de correo electrónico (aunque podrían estar llegando más modernos), por lo que el enfoque de BÚSQUEDA permitió el acceso rápido al correo para dispositivos de mano.

De todos modos, Wireshark puede revelar mucho sobre el comportamiento de los clientes y servidores IMAP. Si tienes mucha curiosidad, dale una oportunidad. No puede hacer esto si el servidor es Gmail, pero puede probarlo en otro servidor (por ejemplo, hMailServer).

Answer 4

Puede probar el rendimiento IMAP de gmail fácilmente (si tiene un buzón de mensajes de un millón). Abra una conexión IMAP con

openssl s_client -connect imap.gmail.com:993 -crlf

luego inicia sesión y abre tu bandeja de entrada.

a login [email protected] yourpassword
b select inbox

O abra su casilla de correo si la bandeja de entrada no es lo suficientemente grande (el nombre puede variar según el idioma de la interfaz de usuario):

c select "[Gmail]/All Mail"

Si SELECT es rápido pero un cliente IMAP es lento, eso se debe a que el cliente envía comandos lentos adicionales / innecesarios. Muchos optan por completar o actualizar una estructura de datos para el millón completo de mensajes, incluso si solo van a mostrar 40 mensajes. Esa es la elección del cliente, no la lentitud de IMAP.