Menu

#73 Unsafe login with 163 emails

unknown
open
None
unknown
5
2024-07-30
2024-02-24
shanyi
No

Unsafe login with 163 emails

env

version: e70c300f7446ba6ec1259f459a0f0e1d2d592ed9
OS: MacOS

~/.mbsyncrc

IMAPAccount 163account1
Host imap.163.com
User xxx
Pass xxxx
TLSType IMAPS
AuthMechs LOGIN
Port 993

IMAPStore 163account1-remote
Account 163account1

MaildirStore 163account1-local
Path ~/Mail/163account1/
INBOX ~/Mail/163account1/INBOX
SubFolders Verbatim

Channel 163account1
Far :163account1-remote:
Near :163account1-local:
Patterns *
Create Both
Expunge Both
SyncState *

error

run mbsync -a, then...

......
Opening far side box INBOX...
F: [ 66] Enter open_box
F: >>> 11 SELECT "&g0l6P3ux-"
F: [ 66] Leave open_box
Opening near side box INBOX...
F: [ 65] Callback leave open_box
F: 11 NO SELECT Unsafe Login. Please contact kefu@188.com for help
F: [ 66] Callback enter open_box, sts=2
Error: channel 163account1: both far side INBOX and near side INBOX cannot be opened.
F: Enter free_store
F: Leave free_store
N: Enter free_store
N: Leave free_store
F: >>> 12 LOGOUT
F: >>> 26 LOGOUT
F: [ 66] Callback leave open_box
F: * BYE IMAP4rev1 Server logging out
F: 12 OK LOGOUT completed
F: * BYE LOGOUT received
F: 26 OK LOGOUT Completed
Processed 14 box(es) in 2 channel(s),
pulled 0 new message(s) and 0 flag update(s),
expunged 0 message(s) from near side,
pushed 0 new message(s) and 0 flag update(s),
expunged 0 message(s) from far side.

F: 11 NO SELECT Unsafe Login. Please contact kefu@188.com for help

Solution to the error

The IMAP server at imap.163.com implemented the IMAP ID extension. To successfully authenticate, the IMAP client must send client ID.

ref:
- https://github.com/OfflineIMAP/offlineimap/issues/696
- https://help.mail.163.com/faqDetail.do?code=d7a5dc8471cd0c0e8b4b8f4f8e49998b374173cfe9171305fa1ce630d7f67ac2eda07326646e6eb0
- https://www.ietf.org/rfc/rfc2971.txt

I tried to modify the source code, but I am not familiar with C language, it is impossible to deal with. I hope it can be repaired as soon as possible, thank you very much.

Discussion

  • Oswald Buddenhagen

    i can implement that, but the RFC states rather plainly that the server must not make operation dependent on it. it is blatantly and intentionally violating the standard.

     
    • shanyi

      shanyi - 2024-02-25

      I completely agree with your perspective. This security check is nonsense.

       
    • shanyi

      shanyi - 2024-02-25

      However, I believe that implementing this feature could greatly benefit users facing similar challenges without compromising the project's integrity.

      Given the significant user base and the widespread use of NetEase services, accommodating their requirements becomes essential for ensuring compatibility and user satisfaction. While it's not ideal to have to adjust for such specific demands, doing so can help maintain a seamless experience for a large number of users.

      To address this, I propose adding a configurable option within our application. This way, users who need to interact with NetEase's servers can enable this feature, while others can leave it disabled, thus adhering to the standard behavior. This approach allows for flexibility and respects the diverse needs of our user base.

      Thank you very much for considering this request. I am truly grateful for your efforts in maintaining isync and for your commitment to its users. Your work does not go unnoticed, and I look forward to any possibility of accommodating this feature in the future.

       
  • Oswald Buddenhagen

    is 163.com still misbehaving this way?

     

Log in to post a comment.