如何通過Openssl使用imap壓縮與shell中的imap服務器通話？

我在理解rfc4978時遇到了一些問題。
據我所知，服務器返回OK包括命令名稱後，所有東西都被壓縮。然而，似乎我誤解了幾件事（因爲[Gmail]/sfgs沒有重命名，顯然該文件沒有發送）。如何通過Openssl使用imap壓縮與shell中的imap服務器通話？

$ 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

其中deflatecommands包含：

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

其解壓縮，得到：

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

deflatecommands當然的使用未壓縮和壓縮部分crfl行結尾。

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

來源

2016-04-28 user2284570

由於我的連接速度，最後一件事情，沒有任何事情發送之前'a002 OK Success'if打印在屏幕上。 – user2284570

我不確定這會起作用。所有三個命令都將在一個數據包中發送，但服務器在啓用壓縮時可能會刷新輸入緩衝區。您可能需要在壓縮和壓縮命令之間暫停。另外，如果壓縮部分中存在CRLF，那也是一個問題。您需要以二進制模式編輯文件，並確保沒有明文CRLF。 – Max

@Max：''003.zlib'中沒有未壓縮的ᴄʀʟꜰ。再次，沒有任何壓縮的字節在GImap返回「OK成功」之前發送。 – user2284570

爲什麼你需要從殼談IMAP： deflatecommands與創造的呢？雖然我讚賞您選擇IMAP確實支持的繁重流水線操作，但所允許的流水線命令存在限制。 LOGIN理論上是安全的，但我不會在等待它的結果之前親自排隊任何東西（並且這是您的天真外殼管道將達到其極限的時刻）。 COMPRESS DEFLATE是不是以任何方式安全管道，因爲服務器必須打開透明壓縮。在很多語言中，這通常涉及各個層上的網絡緩衝區的刷新。

爲什麼在激活COMPRESS擴展時會使整個事情變得複雜？這絕不是必要的，在這種特殊情況下它不會真的爲您節省任何可測量的字節數量。

來源

2016-04-30 12:17:40

'這並不是必須的，在這種特殊情況下，它不會真的爲你節省任何可測量的字節數。'**這是錯誤的！**我正計劃發送一些大的數據，但是一旦壓縮後就會給出50Mb 。傳統的電子郵件客戶端太大而無法完成，並且如果解壓縮的話，在243Kb/s *（上傳速度）*互聯網連接上會花費太多時間。請不要以爲我試圖解決錯誤的問題。 http://stackoverflow.com/q/14959461/2284570 *（事實上，我現在使用一個小的shell腳本在繼續之前等待服務器響應）*。 – user2284570

祝你好運，試圖將「GB大」保存到GMail中。無論如何，你選擇使用shell腳本，好吧，你將不得不面對誘發的痛苦。 –

如何通過Openssl使用imap壓縮與shell中的imap服務器通話？

回答

相關問題