[求助]Gnus 链接至imap服务器时被挂起,如何debug?

  (setq gnus-secondary-select-methods
		'((nnimap "ustc"
				  (nnimap-address "mail.ustc.edu.cn")
				  (nnimap-server-port 993)
				  (nnimap-stream ssl)
				  (nnimap-inbox "INBOX")
				  (nnimap-authinfo-file "~/.authinfo.gpg"))))

  (setq network-security-level 'high)
  (setq gnutls-algorithm-priority
        "SECURE192:+SECURE128:-VERS-ALL:+VERS-TLS1.2:+VERS-TLS1.3:%PROFILE_MEDIUM"
        gnutls-min-prime-bits 2048
        gnutl-verify-error t)

每次Group buffer进入inbox的时候emacs都会卡住, minibuffer里显示read 0k from mail.ustc.edu.cn就卡住了,而且CPU的一根核心会被拉到100%,如果不及时C-g甚至能把linux都卡死 :rofl:

我试着用 gnutils-cli-debug,返回的结果似乎没啥问题(跟imap.qq.com的返回结果几乎一样):

$:gnutls-cli-debug -V -p 993 mail.ustc.edu.cn

GnuTLS debug client 3.6.13
Checking mail.ustc.edu.cn:993
unknown protocol 'imaps'
whether the server accepts default record size (512 bytes)... yes
                  whether %ALLOW_SMALL_RECORDS is required... no
                        whether we need to disable TLS 1.2... no
                        whether we need to disable TLS 1.1... no
                        whether we need to disable TLS 1.0... no
                        whether %NO_EXTENSIONS is required... no
                               whether %COMPAT is required... no
                             for TLS 1.0 (RFC2246) support... yes
 for TLS 1.0 (RFC2246) support with TLS 1.0 record version... skipped
                             for TLS 1.1 (RFC4346) support... yes
                                  fallback from TLS 1.1 to... skipped
                             for TLS 1.2 (RFC5246) support... yes
                             for TLS 1.3 (RFC8446) support... no
                    for known TLS or SSL protocols support... yes
                       TLS1.2 neg fallback from TLS 1.6 to... failed (server requires fallback dance)
              for inappropriate fallback (RFC7507) support... yes
                               for certificate information... saved in debug-certs.out
                               for certificate chain order... sorted
                                           for trusted CAs... none
                  for safe renegotiation (RFC5746) support... yes
                     for Safe renegotiation support (SCSV)... skipped
                    for encrypt-then-MAC (RFC7366) support... no
                   for ext master secret (RFC7627) support... no
                           for heartbeat (RFC6520) support... yes
                       for version rollback bug in RSA PMS... dunno
                  for version rollback bug in Client Hello... no
            whether the server ignores the RSA PMS version... no
whether small records (512 bytes) are tolerated on handshake... yes
    whether cipher suites not in SSL 3.0 spec are accepted... yes
whether a bogus TLS record version in the client hello is accepted... yes
         whether the server understands TLS closure alerts... partially
            whether the server supports session resumption... yes
                      for anonymous authentication support... no
                       anonymous Diffie-Hellman group info... skipped
                              for RSA key exchange support... yes
                      for ephemeral Diffie-Hellman support... no
                        for RFC7919 Diffie-Hellman support... no
                       ephemeral Diffie-Hellman group info... skipped
                   for ephemeral EC Diffie-Hellman support... no
for VKO GOST-2012 (draft-smyshlyaev-tls12-gost-suites) support... no
                             for curve SECP256r1 (RFC4492)... no
                             for curve SECP384r1 (RFC4492)... no
                             for curve SECP521r1 (RFC4492)... no
                                for curve X25519 (RFC8422)... no
                      for AES-GCM cipher (RFC5288) support... yes
                      for AES-CCM cipher (RFC6655) support... no
                    for AES-CCM-8 cipher (RFC6655) support... no
                      for AES-CBC cipher (RFC3268) support... yes
                 for CAMELLIA-GCM cipher (RFC6367) support... no
                 for CAMELLIA-CBC cipher (RFC5932) support... yes
                     for 3DES-CBC cipher (RFC2246) support... yes
                  for ARCFOUR 128 cipher (RFC2246) support... yes
            for CHACHA20-POLY1305 cipher (RFC7905) support... no
for GOST28147-CNT cipher (draft-smyshlyaev-tls12-gost-suites) support... no
                                       for MD5 MAC support... yes
                                      for SHA1 MAC support... yes
                                    for SHA256 MAC support... yes
for GOST28147-IMIT MAC (draft-smyshlyaev-tls12-gost-suites) support... no
                     for max record size (RFC6066) support... no
                for OCSP status response (RFC6066) support... no

Google上的类似问题基本上都是由于没有配置好gnutls导致的,但是我目前的配置,qq邮箱和outlook都可以,甚至mail.ustc.edu.cn的smtp发信也没问题,就是imap会导致卡死…

是不是inbox邮件太多了,看一下 gnus收邮件,Inbox里面怎么有如此大的一个邮件数量啊,一点emacs就卡住了

https://github.com/redguardtoo/mastering-emacs-in-one-year-guide/blob/master/gnus-guide-en.org 也收录了上述链接的方案

感谢回复,不过我想应该是gnus本身的问题,我用offlineimap 配合gnus的maildir后端就能正常收信,而且我的inbox只有不到100封,应该能排除邮件过多的问题。

比较可惜的时maildir的邮件文件名含有:,在windows上属于做文件名是非法的,windows上如何解决又成了问题 :pensive:

试了下Cygwin,发现在Cygwin里面文件名有:也可以正常使用,使用Cygwin的emacs应该就可以解决了~