MailKit анализирует значение ENVELOPE, возвращаемое сервером IMAP. Если вы посмотрите на Протокол протокола , предоставляют ли ответы сервера IMAP ненулевое значение In-Reply-To в ответе ENVELOPE?
Значение ENVELOPE имеет следующий синтаксис:
envelope = "(" env-date SP env-subject SP env-from SP
env-sender SP env-reply-to SP env-to SP env-cc SP
env-bcc SP env-in-reply-to SP env-message-id ")"
env-bcc = "(" 1*address ")" / nil
env-cc = "(" 1*address ")" / nil
env-date = nstring
env-from = "(" 1*address ")" / nil
env-in-reply-to = nstring
env-message-id = nstring
env-reply-to = "(" 1*address ")" / nil
env-sender = "(" 1*address ")" / nil
env-subject = nstring
env-to = "(" 1*address ")" / nil
TL; DR, вы будете искать в строке с именем в скобках ENVELOPE вторую от последней строки.
Редактировать:
Хорошо, теперь, когда вы вставили журнал, мы можем посмотреть, что мы получили с сервера. Вот соответствующий бит:
... ENVELOPE ("Tue, 07 Apr 2020 16:36:22 GMT" "Re: Hi dear friend" (({15}
S: test@mypc.local NIL "test" "mypc.local")) (({15}
S: test@mypc.local NIL "test" "mypc.local")) ((NIL NIL "test" "mypc.local")) ((NIL NIL "someone" "mypc.local")) NIL NIL NIL "<e938d94ca6ac4be085192f00cdc7fdd6@mypc.local>")
env-date = "Вт, 07 апреля 2020 16:36:22 GMT"
env-subject = "Re: Привет, дорогой друг"
env-from = (("test@mypc.local" NIL "тест" "myp c .local"))
env-sender = (("test@mypc.local" NIL "тест") "myp c .local"))
env-reply-to = ((NIL NIL "test" "myp c .local"))
env-to = ((NIL NIL "кто-то" "myp c .local"))
env-cc = NIL
env-bcc = NIL
env-in-reply-to = NIL
env-message-id = ""
Итак, проблема в том, что IMAP-сервер сообщает MailKit, что значение In-Reply-To равно NIL (он же null).
Исходя из необработанных заголовков, которые вы возвращаете для этого сообщения, ясно, что сервер SmarterMail IMAP содержит ошибки по крайней мере 2 способами:
- Значение
env-in-reply-to отправляется как NIL когда оно должно быть явно "<specified-message-id>" env-sender отправляется как дубликат env-from, но должно быть NIL в вашем случае на основе заголовков, потому что он сопоставляется с Sender: он ader, которого нет в вашем примере сообщения.
Вопрос к вам: буквально "<specified-message-id>" находится в заголовках? Интересно, может быть, SmarterMail отправляет NIL, потому что это технически недопустимый синтаксис и, возможно, SmarterMail не может его проанализировать?
Просто мысль.
Относительно " Новый вопрос "в вашем посте:
Да, вы можете запросить заголовок In-Reply-To и вручную его проанализировать - это прекрасно. Фактически, способ MessageSummaryItems.References работает так: он запрашивает HEADER.FIELDS (REFERENCES) и затем анализирует необработанный заголовок. Поскольку вы также отправляете MessageSummaryItems.Headers, MailKit знает, что бессмысленно снова запрашивать References, так как это будет частью ответа Headers.
Я бы, наверное, не рекомендуется запрашивать полный набор MessageSummaryItems.Headers (если только у вас нет особой c необходимости извлекать их все), поскольку вам не нужно много дополнительных данных. Опять же, когда речь идет о сломанном сервере IMAP, возможно, лучше попросить Headers, чем Envelope.
Идея Envelope состоит в том, что это более или менее все, что вам нужно клиенту знать о том, чтобы отобразить список сообщений для пользователя.
Причина, по которой MailKit имеет MessageSummaryItems.References (а не какой-либо другой отдельный заголовок), заключается в том, что для выполнения требуется заголовок References правильная нарезка резьбы с использованием методов MailKit.MessageThreader.Thread(). Он также будет использовать значение Envelope.InReplyTo, но это не обязательно, я не думаю, потому что технически, References означает , предполагается, что должен иметь тот же токен msg-id, что и один его значений.
Заголовок References представляет собой цепочку значений заголовка Message-Id, возвращающуюся к root "диалога" (это немного сложнее, чем это, поскольку клиентам разрешено обрезать некоторые из них). msg-id значения, как только список становится слишком длинным, но это общая идея).