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

Question

Estoy analizando correos electrónicos con Zend_Mail, y extrañamente parte del contenido se trunca sin una razón obvia y deforma 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é está parando 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.

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

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

También abrí un bug report con ZF aunque el error no parece estar en la biblioteca.

¿Ve algo extraño con esta cadena codificada?

ACTUALIZACIÓN

nueva investigación demuestra que los correos electrónicos se trunca después de 584 caracteres. Todavía no sé por qué. También envió una pregunta a google. Ver here.

A los encabezados de correo electrónico: Mala

Delivered-To: email@removed.com 
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@removed.com> 
Content-Type: multipart/mixed; boundary="===============1703099044==" 
MIME-Version: 1.0 
From: <email@removed.com> 
To: <email@removed.com> 
CC: 
Subject: some subject 
Message-ID: <FLYNDRElQ080Gxw8Zw500000f46email@removed.com> 
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: <19740416124736.CF5804B33EF632B0email@removed.com> 
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 el (ex) de recompensas, más pistas.

Gmail is returning a short value in response to RFC822.SIZE, which can lead to truncated messages. (They are off by one byte for each header line, apparently not counting two characters for CR/LF.)

Answer 1

Creo que está buscando en el lugar equivocado.

El servidor imap le da el 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:

• encuentran un ambiente suficientemente silenciosa para poner su proyecto, donde se puede proceso strace -f -s 10240 -p <pid> de Apache para verificar la interacción zócalo (suponiendo un entorno Linux/Apache)
• y/o: utilizar tcpdump, ethereal o equivalente para comprobar lo que viene en la línea

Mi conjetura es que se pueden ver exactamente las mismas secuencias truncadas que entra en el cable. Lo que significa que puedes cambiar tu enfoque al servidor imap.

Asegúrate de que estás buscando en el lugar correcto, puede ahorrar mucho tiempo.

Answer 2

Ha intentado adoptar otras fgets y ver si le da 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 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 desea leer el zócalo de la red, usted debe tratar socket_read. Eso está diseñado con la red en mente, como curl.

Answer 3

No sabe Zend y olvidó por completo de PHP, pero juega con MIME y HTTP antes (C++).

Sugiero que empiece a buscar la forma de agregar un Content-Length entrada de encabezado. Da una pista al "decodificador/cargador de mensajes" para esperar un cierto tamaño en el contenido (carga útil del mensaje). (No estoy seguro de 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 que solo lea 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 necesite hacer alguna configuración local)

El código al que se refiere es here?

Answer 4

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 memoria RAM o los discos duros. 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.

Answer 5

1: intente eliminar el @ para más verbosidad

2: tratar de usar 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 TAG5 OK Success como respuesta, incluso si no se supone que esté allí.