2016-04-28 28 views
0

Ich habe ein paar Probleme zu verstehen rfc4978.
Wie ich es verstehe, ist alles komprimiert, nachdem der Server OK einschließlich der Befehlsnamen zurückgibt. Jedoch scheint es, dass ich mehrere Dinge falsch verstanden habe (weil [Gmail]/sfgs nicht umbenannt wird und offensichtlich die Datei nicht gesendet wird).Wie man mit OpenSSL imap-Komprimierung mit IMAP-Server in der Shell sprechen?

$ cat deflatecommands /dev/stdin | socat - OPENSSL:imap.googlemail.com:993,compress=none 
* CAPABILITY IMAP4rev1 UNSELECT IDLE NAMESPACE QUOTA ID XLIST CHILDREN X-GM-EXT-1 UIDPLUS COMPRESS=DEFLATE ENABLE MOVE CONDSTORE ESEARCH UTF8=ACCEPT APPENDLIMIT=35882577 LIST-EXTENDED LIST-STATUS 
a001 OK [email protected] authenticated (Success) 
a002 OK Success 
2016/04/28 21:47:03 socat[16204.25769803872] E SSL_write(): Broken pipe 

wo deflatecommands enthält:

a001 LOGIN myus.tyer mypassord 
a002 COMPRESS DEFLATE 
xÚK400VrõsôuUPŠvÏMÌ̉Õ/NK/[email protected]‰— Ô) 

, die gibt unkomprimiert:

a001 LOGIN myus.tyer mypassord 
a002 COMPRESS DEFLATE 
a003 RENAME "[Gmail]/sfgs" "[Gmail]/xxxxxxxxxxx" 

Natürlich deflatecommands verwendet crfl Zeilenende in beiden unkomprimierten und komprimierten Teilen. deflatecommands mit erstellt:

$ openssl zlib a003 > a003.zlib 
$ cat a001 a002 a003.zlib > defaltecommands 
+0

Eine letzte Sache wegen der Geschwindigkeit meiner Verbindung, nichts wird gesendet, bevor "a002 OK Success" wenn auf dem Bildschirm gedruckt wird. – user2284570

+0

Ich bin mir nicht sicher, ob das funktioniert. Alle drei Befehle werden in einem Paket gesendet, aber der Server wird wahrscheinlich den Eingabepuffer leeren, wenn die Komprimierung aktiviert wird. Sie werden wahrscheinlich eine Pause zwischen der Komprimierung und dem komprimierten Befehl benötigen. Wenn im komprimierten Teil ein CRLF vorhanden ist, ist dies ebenfalls ein Problem. Sie müssen die Datei im Binärmodus bearbeiten und sicherstellen, dass kein Klartext CRLF vorhanden ist. – Max

+0

@Max: Es gibt kein unkomprimiertes ᴄʀʟꜰ in 'a003.zlib'. Und wieder werden keine komprimierten Bytes gesendet, bevor GImap "OK erfolgreich" zurückgegeben hat. – user2284570

Antwort

0

Warum brauchen Sie IMAP von Shell zu sprechen? Während ich Ihnen die Wahl des Heavy Pipelines applaudiere, das IMAP tatsächlich unterstützt, gibt es eine Grenze für die erlaubten Pipelinebefehle. LOGIN ist in der Theorie sicher, aber ich würde nichts direkt danach in die Warteschlange stellen, ohne auf sein Ergebnis zu warten (und das ist der Moment, in dem deine naive Muschelpfeife an ihre Grenzen stoßen wird). COMPRESS DEFLATE ist nicht sicher zu Pipeline mit irgendwelchen Mitteln, weil der Server transparente Komprimierung einschalten muss. In vielen Sprachen beinhaltet dies normalerweise ein Leeren der Netzwerkpuffer auf verschiedenen Ebenen.

Warum verkomplizieren Sie die ganze Angelegenheit mit der Aktivierung der COMPRESS Erweiterung? Es ist keineswegs notwendig, und es wird nicht wirklich eine messbare Menge an Bytes in diesem speziellen Szenario speichern.

+0

'Es ist keineswegs notwendig, und es wird nicht wirklich sparen Sie messbare Menge an Bytes in diesem speziellen Szenario. ** Es ist falsch! ** Ich plane Senden etwas Gb groß, aber das geben 50 MB einmal deflate komprimiert . Es ist zu groß, um über einen herkömmlichen E-Mail-Client ausgeführt zu werden, und würde bei unkomprimierter Internet-Verbindung mit 243 KB/s * (Upload-Geschwindigkeit) zu viel Zeit in Anspruch nehmen. Bitte gehen Sie nicht davon aus, dass ich versuche, das falsche Problem zu lösen. http://StackOverflow.com/q/14959461/2284570 * (und tatsächlich benutze ich jetzt ein kleines Shell-Skript für wartende Server-Antworten, bevor ich fortfahre) *. – user2284570

+0

Viel Glück versuchen, etwas "GB groß" in GMail zu speichern. Wie auch immer, Sie haben sich entschieden, Shell-Skripte zu verwenden, nun, Sie werden mit den ausgelösten Schmerzen fertig werden müssen. –

Verwandte Themen