php - imagen - cadena codificada en base64 se trunca a través de la llamada fgets al analizar IMAP

decodificar base64 javascript (5)

Estoy analizando correos electrónicos con Zend_Mail, y extrañamente parte del contenido se trunca sin una razón obvia y daña las partes del correo electrónico.

Por ejemplo

Content-Disposition: attachment; filename="file.sdv" DQogICAgICBTT05FO0xBTkRJTkdTREE7U0FMR1NEQVRPIDtOQVNKIDtSRURTS0FQICAgICAgICAg ICAgIDsgRklTS0VTTEFHO1BSRVNFUlYgICA7ICBUSUxTVEFORDsgU1TYUlJFTFNFOyAgS1ZBTElU RVQ7T01TVFlQRSAgO01JTlNURVBSSVM7ICAgICBWRVJESTsgICBLVkFOVFVNOyAgUlVORFZFS1Qg IA0KLS0tLS0tLS0tLTstLS0tLS0tLS0tOy0tLS0tLS0tLS07LS0tLS07LS0tLS0tLS0tLS0tLS0t LS0tLS07LS0tLS0tLS0tLTstLS0tLS0tLS0tOy0tLS0tLS0tLS07LS0tLS0tLS0tLTstLS0tLS0t LS0tOy0tLS0tLS0tLTstLS0tLS0tLS0tOy0tLS0tLS0tLS07LS0tLS0tLS0tLTstLS0tLS0tLS0t ICANCiAgICAgICAgIDA7MjAxMC4wOS4wODsyMDEwLjA5LjA4O05vcnNrO0dhcm4gICAgICAgICAg ICAgICAgOyAgICAgIDEwMjE7RkVSU0sgICAgIDsgICAgICAgMjEwOyAgIDQwMjA5OTk7ICAgICAg ICAyMDtFZ2Vub3ZlcnQ7ICAgICAgICAgIDsgICAzMDcyLDE2OyAgICAgICAyMTE7ICAgICAyNTMs MiAgDQogICAgICAgICAwOzIwMTAuMDkuMDg7MjAxMC4wOS4wODtOb3JzaztHYXJuICAgICAgICAg

Se trunca a

Content-Disposition: attachment; filename="file.sdv" DQogICAgICBTT05FO0xBTkRJTkdTREE7U0FMR1NEQVRPIDtOQVNKIDtSRURTS0FQICAgICAgICAg ICAgIDsgRklTS0VTTEFHO1BSRVNFUlYgICA7ICBUSUxTVEFORDsgU1TYUlJFTFNFOyAgS1ZBTElU RVQ7T01TVFlQRSAgO01JTlNURVBSSVM7ICAgICBWRVJESTsgICBLVkFOVFVNOyAgUlVORFZFS1Qg IA0KLS0tLS0tLS0tLTstLS0tLS0tLS0tOy0tLS0tLS0tLS07LS0tLS07LS0tLS0tLS0tLS0tLS0t LS0tLS07LS0tLS0tLS0tLTstLS0tLS0tLS0tOy0tLS0tLS0tLS07LS0tLS0tLS0tLTstLS0tLS0t LS

un var_dump en cada línea muestra esto.

string(78) "DQogICAgICBTT05FO0xBTkRJTkdTREE7U0FMR1NEQVRPIDtOQVNKIDtSRURTS0FQICAgICAgICAg " string(78) "ICAgIDsgRklTS0VTTEFHO1BSRVNFUlYgICA7ICBUSUxTVEFORDsgU1TYUlJFTFNFOyAgS1ZBTElU " string(78) "RVQ7T01TVFlQRSAgO01JTlNURVBSSVM7ICAgICBWRVJESTsgICBLVkFOVFVNOyAgUlVORFZFS1Qg " string(78) "IA0KLS0tLS0tLS0tLTstLS0tLS0tLS0tOy0tLS0tLS0tLS07LS0tLS07LS0tLS0tLS0tLS0tLS0t " string(78) "LS0tLS07LS0tLS0tLS0tLTstLS0tLS0tLS0tOy0tLS0tLS0tLS07LS0tLS0tLS0tLTstLS0tLS0t " string(5) "LS) " string(17) "TAG5 OK Success "

o en otro correo electrónico a

DQogICAgICBTT05FO0xBTkRJTkdTREE7U0FMR1NEQVRPIDtOQVNKIDtSRURTS0FQICAgICAgICAg ICAgIDsgRklTS0VTTEFHO1BSRVNFUlYgICA7ICBUSUxTVEFORDsgU1TYUlJFTFNFOyAgS1ZBTElU RVQ7T01TVFlQRSAgO01JTlNURVBSSVM7ICAgICBWRVJESTsgICBLVkFOVFVNOyAgUlVORFZFS1Qg IA0KLS0tLS0tLS0tLTstLS0tLS0tLS0tOy0tLS0tLS0tLS07LS0tLS07LS0tLS0tLS0tLS0tLS0t LS0tLS07LS0tLS0tLS0tLTstLS0tLS0tLS0tOy0tLS0tLS0tLS07LS0tLS0tLS0tLTstLS0tLS0t LS0tOy0tLS0tLS0tLTstLS0tLS0tLS0tO

No puedo entender por qué se detiene allí. Las transiciones deberían haberse detenido solo al final de la línea. Esta es la línea que obtiene la cadena del servidor IMAP.

$line = @fgets($this->_socket);

El texto codificado contiene una cadena como, pero de nuevo esto se trunca en varias partes en diferentes correos electrónicos.

----------;----------;----------;-----;--------------------;----------;----------;--

Intenté agregar un tamaño a fgets () pero sin resultados. También habilité / deshabilité la opción "auto_detect_line_endings" php_ini, nuevamente sin resultado.

También abrí un informe de error con ZF, aunque el error no parece estar en la biblioteca.

¿Ves algo extraño con esta cadena codificada?

ACTUALIZAR

Una nueva investigación muestra que los correos electrónicos se truncan después de 584 caracteres. Todavía no sé por qué. Envié una pregunta a google también. Mira aquí .

A Encabezados de correo electrónico incorrectos:

Delivered-To: [email protected] Received: by 10.216.3.208 with SMTP id 58cs248812weh; Fri, 20 Nov 2009 05:14:14 -0800 (PST) Received: by 10.204.153.217 with SMTP id l25mr1285471bkw.108.1258722853863; Fri, 20 Nov 2009 05:14:13 -0800 (PST) Return-Path: <> Received: from MTX4.mbn1.net (mtx4.mbn1.net [213.188.129.252]) by mx.google.com with SMTP id 2si1800716bwz.60.2009.11.20.05.14.12; Fri, 20 Nov 2009 05:14:13 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of MTX4.mbn1.net designates 213.188.129.252 as permitted sender) client-ip=213.188.129.252; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of MTX4.mbn1.net designates 213.188.129.252 as permitted sender) smtp.mail= Resent-From: <[email protected]> Content-Type: multipart/mixed; boundary="===============1703099044==" MIME-Version: 1.0 From: <[email protected]> To: <[email protected]> CC: Subject: some subject Message-ID: <[email protected]> X-OriginalArrivalTime: 20 Nov 2009 13:14:08.0121 (UTC) FILETIME=[5792C690:01CA69E3] Date: Fri, 20 Nov 2009 14:14:08 +0100 X-STA-Metric: 0 (engine=030) X-STA-NotSpam: tlf: vedlagt skip:__ 40 fil cc:2**0 X-STA-Spam: header:MIME-Version: charset:us-ascii header:Subject:1 to:2**0 header:From:1 X-BTI-AntiSpam: score:0,sta:0/030,dnsbl:passed,sw:off,bsn:38/passed,spf:off,bsctr:passed/1,dk:off,pbmf:none,ipr:0/3,trusted:no,ts:no,bs:no,ubl:passed X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply Resent-Message-Id: <[email protected]> Resent-Date: Fri, 20 Nov 2009 14:14:11 +0100 (CET) --===============1703099044== Content-Type: application/octet-stream MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="file.sdv" DQpHUlVQUEVOQVZOICAgICAgICAgIDtLSthQRTtQUk9EQU5MO1BBS0tFTlI7TU9UVEFLTkFWTiAg ICAgICAgICAgICAgICAgICAgO1NPTjtMQU5ESU5HU0RBO1NBTEdTREFUTyA7TkFTSiA7UkVEU0tB UCAgIDtGSVNLRVNMQUcgO1BSRVNFUlYgICA7VElMU1RBTkQ7U1TYUlJFTFM7S1ZBTElURVQ7TUlO U1RFUFJJUzsgICAgICAgIFZFUkRJOyAgICAgS1ZBTlRVTTsgICAgUlVORFZFS1QgICAgDQotLS0t LS0tLS0tLS0tLS0tLS0tLTstLS0tLTstLS0tLS0tOy0tLS0tLS07LS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tOy0tLTstLS0tLS0tLS0tOy0tLS0tLS0tLS07LS0tLS07LS0tLS0tLS0tLTst LS0tLS0tLS0tOy0tLS0tLS0tLS07LS0tLS0tLS07LS0tLS0tLS07LS0tLS0tLS07LS0tLS0tLS0t LTstLS0tLS0tLS0tLS0tOy0tLS0tLS0tLS0tLTstLS0tLS0tLS0tLS0gICAgDQpMb3JlbnR6ZW4g ....

Para aquellos interesados en una respuesta y no en la (ex) recompensa, más pistas.

Gmail está devolviendo un valor corto en respuesta a RFC822.SIZE, que puede generar mensajes truncados. (Están desactivados en un byte por cada línea de encabezado, aparentemente sin contar dos caracteres para CR / LF).

¿Has intentado emitir otros datos y ver si obtienes el resto de los datos? Es posible que esté recuperando un correo electrónico de varias partes que requeriría varias solicitudes.

Pero independientemente, está utilizando funciones diseñadas para el acceso a archivos en una red. Por lo general, esto funciona bien, pero dependiendo de la red, pueden surgir problemas. Por ejemplo, puede usar file_get_contents para recuperar una página web. Pero si el problema genera una redirección, falla. Pero usar curl será mucho más exitoso.

Si realmente quieres leer el socket de red, debes probar socket_read. Eso está diseñado con la red en mente, como curl.

No conozco a Zend y olvidé todo sobre PHP pero jugué con MIME y HTTP antes (C ++).

Sugiero que comiences a buscar la manera de agregar una entrada de encabezado Content-Length . Da una pista al "decodificador / cargador de mensajes" para esperar un cierto tamaño en el contenido (carga útil del mensaje). (No estoy seguro si IMAP lo hace)

En el código anterior trataría de convencer a los expertos para que lean una cantidad específica de datos esperados de la red. Podría ser que los datos estén almacenados en un búfer o que aún no se envíen a través de la red (comunicación asíncrona) y fgets solo lee un búfer interno deteniéndose así antes de que se haya leído todo el mensaje.

Para ver si este es el caso, envíe un pequeño mensaje que caiga dentro de su "punto de ruptura 584".
Haga una red rastreando el ver si realmente fluyen todos los datos. (Probablemente necesites hacer una configuración local)

El código al que te refieres está aquí ?

1: intente eliminar el @ para obtener más detalles

2: intente utilizar http://www.php.net/manual/en/function.fread.php en lugar de fgets

Esto podría tener algo que ver con el servidor IMAP, porque veo que TAG5 OK Success como respuesta, incluso si no debería estar allí.

Creo que estás buscando en el lugar equivocado.

El servidor imap le da un mensaje de correo truncado, y luego devuelve su línea de estado TAG5 OK Success .

No veo cómo su manejo del zócalo (/ php) haría desaparecer unos pocos kb de flujo, para arreglar mágicamente el flujo justo antes de esta línea de estado.

Entonces, o el mensaje se trunca solo (¿ha verificado el contenido del mensaje de otra forma?) O el servidor imap simplemente se ha roto.

Las primeras cosas que haría, son:

encuentre un entorno lo suficientemente silencioso para poner su proyecto, donde puede strace -f -s 10240 -p <pid> el proceso de apache para verificar la interacción del socket (suponiendo un entorno Linux / Apache)
y / o: use tcpdump , ethereal o equivalente para verificar lo que entra en la línea

Supongo que verá exactamente las mismas cadenas truncadas entrando en el cable. Lo que significa que puedes cambiar tu enfoque al servidor imap.

Asegurarte a ti mismo que estás buscando en el lugar correcto puede ahorrar mucho tiempo.

Lo más probable es que uno de los hardware de su servidor esté en peligro y, por lo tanto, desee cambiarlo por completo o simplemente cambiar los módulos de RAM o las unidades de disco. Tengo cierta experiencia con la codificación basada en web y correo y puedo confirmar que la cadena codificada en base64 es muy segura. Al menos usa un algoritmo de mapeo de texturas.