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 *
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
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.
https://github.com/OfflineIMAP/offlineimap3/issues/71
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.
I completely agree with your perspective. This security check is nonsense.
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.
is 163.com still misbehaving this way?