Это открывает дверь для самых разных вещей, которые мы потенциально могли бы делать, например, отклонять письма, отвечающие на старую версию сообщения. Но это скорее воображение и идеи, которые могут казаться хорошими, но не обязательно таковыми ![]()
Я ещё не видел этого упоминания, поэтому убедитесь, что вы это обработаете:
- Если в письме есть раздел «Предыдущие ответы», (сделайте что-то, чтобы адаптировать его под конкретного получателя).
Я не совсем понимаю, что вы имеете в виду под предыдущими ответами и как мне нужно сделать его более ориентированным на получателя? Как это вписывается в общую стратегию последовательных Message-ID, которую мы подробно описали здесь?
Если кто-то получает раздел «Предыдущие ответы», вам придется полностью отказаться от последовательных идентификаторов сообщений: вы объединяете несколько постов в одно письмо! Не существует единственного корректного идентификатора сообщения, который бы последовательно идентифицировал всё содержимое в разных точках зрения.
Редакция: на самом деле, я полагаю, их можно просто конкатенировать?
topic/1234/post/12345.also-12340-12339
Кроме того, это делает упомянутые ранее триггеры спама ещё более серьёзными: вы не просто подменяете ссылку для отписки при том же идентификаторе сообщения, а в разных версиях, доставляемых с одним и тем же идентификатором, фактически включаются и исключаются определённые слова.
От Kane York через Discourse Meta, 02 авг 2022, 04:26:
Если кто-то получает раздел «Предыдущие ответы», вам нужно полностью
отказаться от последовательных идентификаторов сообщений: вы объединяете
несколько постов в одно письмо!
Не могли бы вы немного подробнее об этом рассказать? Как выглядит письмо в
этом случае? Есть пример?
Не существует единственного корректного идентификатора сообщения,
который последовательно идентифицировал бы весь контент с разных точек зрения.
Для большинства целей достаточно выбрать один, например, первый, если этот
пример всё ещё является ответом.
Редакция: на самом деле, я полагаю, можно просто конкатенировать их?
topic/1234/post/12345.also-12340-12339
Я начинаю думать, что вы смешиваете какую-то ссылку на исходные посты
форума Discourse с идентификатором сообщения (message-id). Message-id
идентифицирует электронные письма. Для поста-ответа message-id в заголовках
In-Reply-To и References должен совпадать с message-id соответствующих
предшествующих электронных писем. Когда кто-то публикует пост в теме, каждая
копия этого поста, отправленная по электронной почте тем, кто запросил
электронные копии, должна иметь одинаковый message-id.
Кроме того, это делает упомянутые ранее триггеры спама ещё более серьёзными:
вы не просто меняете ссылку для отписки под тем же message-id, в разных
версиях, доставляемых с тем же message-id, фактически включаются и
исключаются разные слова.
В этом нет ничего плохого, если это «административные подписи» в конце поста.
Я не совсем уверен, что мы говорим об одном и том же.
Также: о каких именно триггерах спама вы здесь говорите? Потому что
«немного отличающиеся» электронные письма отправляются постоянно в реальном
мире.
С уважением,
Кэмерон Симпсон cs@cskk.id.au
Кейн говорит об этой опции:
Пользователи могут выбрать получение предыдущих ответов с высокой степенью детализации, добавляемых в конец писем.
Я готов пока рассматривать это как фоновый шум и относиться к этому так же, как мы относимся к уникальным ссылкам для отписки.
Я точно не хочу блокировать дальнейший прогресс здесь, теперь, когда у нас есть консенсус.
(что касается того, как это выглядит, на мой взгляд, это довольно запутанно, но некоторым пользователям это нравится)
От Сэма Саффрона через Discourse Meta, 02 августа 2022 г., 05:29:
[quote=“Кэмерон Симпсон, пост:51, тема:233499,
username:cameron-simpson”]
Не могли бы вы немного подробнее об этом рассказать? Как выглядит письмо в этом
случае? Есть пример?
[/quote]Кейн говорит об этой опции:
Пользователи могут выбрать получение предыдущих ответов с высокой степенью детализации,
добавляемых в конец писем.
А, спасибо.
Я готов пока считать это фоновым шумом и относиться к этому так же, как к уникальным ссылкам для отписки.
Я тоже склоняюсь к такому подходу. На мой взгляд, это соответствует цели «первоначальный замысел автора/публикатора» из RFC. Это сопутствующий багаж, но не иное основное сообщение.
С уважением,
Кэмерон Симпсон cs@cskk.id.au
Согласен, давайте продолжим по плану. Я начал изучать изменения вчера, начав с нашего почтового приёмника.
@cameron-simpson, просто к сведению: я интегрирую это в свои текущие обязанности. На следующей неделе я буду в отпуске, а затем ещё в первые две недели сентября, поэтому реальный прогресс может занять некоторое время. Пожалуйста, знайте, что я держу это в приоритете, и я обязательно буду регулярно обновлять информацию здесь. Большое спасибо за ваше участие и вклад на данный момент!
От Мартина Бреннана через Discourse Meta, 02.08.2022 07:06:
@cameron-simpson, просто для информации: я совмещаю эту работу с другими
обязанностями, которые у меня есть в настоящее время. На следующей неделе
я буду в отпуске, а затем ещё в первые две недели сентября, поэтому
реальный прогресс здесь может занять некоторое время. Будьте уверены,
что я держу это в фокусе своего внимания, и я обязательно буду регулярно
публиковать здесь обновления. Большое спасибо за ваше участие и вклад
до сих пор!
С уважением,
Cameron Simpson cs@cskk.id.au
@cameron-simpson Я снова взялся за эту работу после возвращения из поездки и хотел бы уточнить некоторые моменты, касающиеся различных сценариев использования полей References и In-Reply-To.
Сценарий 1: При создании поста в Discourse, который не является прямым ответом на другой пост, следует ли нам просто использовать Message-ID оригинального поста (OP) темы, который мы сохраняем в новом столбце outbound_message_id, для обоих полей References и In-Reply-To?
Сценарий 2: Когда пост отвечает сразу на несколько других постов (что может произойти при использовании цитат), какой пост следует использовать для In-Reply-To? И нужно ли использовать все они для References, или только тот, который выбран для In-Reply-To? Следует ли включать Message-ID оригинального поста (OP) в References вообще?
Сценарий 3: Аналогично предыдущему, но ограничимся одним постом, на который мы отвечаем. Если мы отвечаем на пост B, который, в свою очередь, является ответом на пост A, указывает ли In-Reply-To просто на пост B, а References должны идти в порядке пост A, пост B (конечно, всегда ссылаясь на Message-ID через outbound_message_id поста)? Нужно ли продолжать подниматься по цепочке ответов или остановиться на первом родительском посте для References?
В основном это сводится к тому, как мы интерпретируем эту цитату из RFC, и в первую очередь влияет на References — ограничиваются ли они только прямыми ответами через цитирование или иным образом, или же они также всегда включают оригинальный пост (OP).
Примечание: Некоторые реализации анализируют поле “References:”, чтобы отобразить “цепочку обсуждения”. Эти реализации предполагают, что каждое новое сообщение является ответом на одного родителя, и поэтому они могут двигаться назад по полю “References:”, чтобы найти родителя каждого сообщения, указанного там. Следовательно, попытка сформировать поле “References:” для ответа, имеющего нескольких родителей, не рекомендуется; способ сделать это в данном документе не определен.
Спасибо, Кэмерон. Тем временем я продолжу работу, руководствуясь тем, что, как мне кажется, является правильным, и внесу корректировки после вашего ответа.
От Мартина Бреннана через Discourse Meta, 19 августа 2022 г., 03:48:
@cameron-simpson Я снова взялся за эту работу после возвращения
из поездки и хотел бы получить дополнительные разъяснения по поводу
различных сценариев использования полейReferencesиIn-Reply-To.Сценарий 1: При создании сообщения в Discourse, которое не является прямым ответом на другое сообщение, используем ли мы просто
Message-IDпервого сообщения темы (OP), который мы храним в новом столбцеoutbound_message_id, для обоих полейReferencesиIn-Reply-To?
Возможно, здесь у меня проблемы с терминологией. Для первого сообщения (OP) новой темы я не ожидаю наличия полей References или In-Reply-To, так как это OP.
Для сообщения в существующей теме, которое не ссылается на конкретное предыдущее сообщение (что, как я полагаю, вы и описываете), достаточно Message-ID OP в каждом из полей References и In-Reply-To, в точности так, как вы описали.
Сценарий 2: Когда сообщение является ответом на несколько других сообщений одновременно (что может происходить через цитирование), какое сообщение использовать для
In-Reply-To?
[Перечитываю RFC 5322 заново…]
In-Reply-Toдолжен содержатьMessage-IDкаждого сообщения, на которое дается ответ.Referencesдолжен содержатьReferencesродительского (*) сообщения с добавлениемMessage-IDродителя.
Таким образом, In-Reply-To указывает только на одно предыдущее сообщение в цепочке. Наличие нескольких родительских сообщений означает несколько идентификаторов сообщений, но они должны быть просто идентификаторами непосредственных родительских сообщений.
References предназначен для отслеживания всей цепочки ответов от OP до родительского (*) сообщения текущего поста. Поэтому он вычисляется как цепочка до родителя плюс Message-ID родителя.
(*) Когда есть более одного родителя: RFC гласит, что поскольку клиенты (почтовые клиенты) часто ожидают, что References будут отслеживать единственную цепочку ответов от OP до сообщения, RFC явно не рекомендует объединять References всех родителей. Вместо этого следует выбрать только один. Лично я склоняюсь к выбору первого упомянутого родительского сообщения, но это, безусловно, вопрос политики: выберите тот вариант, который, по вашему мнению, будет наиболее полезным.
Сценарий 3: Аналогично предыдущему, но ограничимся одним сообщением, на которое мы отвечаем. Если мы отвечаем на сообщение B, которое, в свою очередь, является ответом на сообщение A, указывает ли
In-Reply-Toпросто на сообщение B, аReferencesдолжны идти в порядкесообщение A, сообщение B(разумеется, всегда ссылаясь наMessage-IDчерезoutbound_message_idв сообщении)? Должны ли мы продолжать подниматься по цепочке ответов или остановиться на первом родителе дляReferences?
In-Reply-To указывает ровно на один уровень назад. Таким образом, в этом сценарии он содержит только Message-ID родительского сообщения.
References — это цепочка от OP до текущего сообщения.
Это в основном сводится к тому, как мы интерпретируем эту цитату из RFC, и в основном влияет на
References— ограничиваются ли они только прямыми ответами через цитирование или иным образом, или же они всегда включают OP.
Они всегда должны начинаться с OP. Если все предыдущие сообщения делали это, вы можете просто добавить Message-ID родителя к References родителя и получить всю цепочку бесплатно.
Если вы имеете дело с «устаревшим» сообщением, вы можете пройти вверх по дереву. Или вы можете решить делать это каждый раз. Или вы можете сказать, что с этого момента всё в порядке, и мы просто будем брать References у родителя, если они там есть. Думаю, это зависит от того, что вы решили хранить в своей базе данных.
Я считаю, что если вы стремитесь к тому, чтобы In-Reply-To указывал на непосредственного родителя, а References — на цепочку обратно к OP, у вас всё будет хорошо.
С уважением,
Кэмерон Симпсон cs@cskk.id.au
Да, именно это я и описывал, спасибо.
Спасибо. По сути, ответ таков: выберите одно сообщение, на которое была дана цитата, и используйте его как родителя (независимо от того, было ли оно первым упомянутым или созданным последним — важно выбрать только один), используйте его для In-Reply-To, а для References используйте его и всех его родителей вплоть до ОП.
Понял, логично.
Кажется, это проясняет всё, и ваши ответы соответствовали моим ожиданиям. Я просто хотел перепроверить перед началом ручного тестирования. Спасибо за быстрый ответ ![]()
@cameron-simpson Я думаю, что у меня всё работает, как описано. Mutt настроен, и цепочка писем формируется корректно (хотя я не понимаю, почему в цепочке отсутствует строка темы, а также не знаю, как настроить отображение моих собственных отправленных ответов внутри цепочки):
А вот как ту же цепочку отображает Thunderbird (на самом деле я понял, что Thunderbird тоже не показывает мои ответы внутри цепочки):
Вот как это выглядит в Gmail:
Ниже приведены заголовки. ID постов начинаются с 91, то есть пост 1 соответствует ID письма 91.
Пост/Письмо 1
(Нет полей References или In-Reply-To, так как это первое письмо)
From: Martin Brennan via The Email Threading Sandbox <notifications@cdckmartintesting.discoursemail.com>
Reply-To: The Email Threading Sandbox <incoming+3706c086cd36c6e37550c24f4e25c9b8@cdckmartintesting.discoursemail.com>
To: imaptest2@discourse.org
Message-ID: <discourse/post/91@discoursehosted.martin-brennan.com>
Subject: [The Email Threading Sandbox] [Royal Court] Threading topic 1 for
Пост/Письмо 2
From: Bizarro Martin via The Email Threading Sandbox <notifications@cdckmartintesting.discoursemail.com>
Reply-To: The Email Threading Sandbox <incoming+9ea955b74a04dc85f5504ad245636824@cdckmartintesting.discoursemail.com>
To: imaptest2@discourse.org
Message-ID: <discourse/post/92@discoursehosted.martin-brennan.com>
In-Reply-To: <discourse/post/91@discoursehosted.martin-brennan.com>
References: <discourse/post/91@discoursehosted.martin-brennan.com>
Subject: [The Email Threading Sandbox] [Royal Court] Threading topic 1 for
Пост/Письмо 3
From: Martin Brennan via The Email Threading Sandbox <notifications@cdckmartintesting.discoursemail.com>
Reply-To: The Email Threading Sandbox <incoming+410877b7f868b59945f3e3ea16570fc4@cdckmartintesting.discoursemail.com>
To: imaptest2@discourse.org
Message-ID: <discourse/post/93@discoursehosted.martin-brennan.com>
In-Reply-To: <discourse/post/91@discoursehosted.martin-brennan.com>
References: <discourse/post/91@discoursehosted.martin-brennan.com>
Пост/Письмо 4
Ответ на Пост 2 и Пост 3, но в качестве родителя для цепочки References мы используем Пост 3, так как нужно выбрать только один.
Date: Mon, 22 Aug 2022 04:05:45 +0000
From: Bizarro Martin via The Email Threading Sandbox <notifications@cdckmartintesting.discoursemail.com>
Reply-To: The Email Threading Sandbox <incoming+0a63eba3765f58e709a2ca538ca2b926@cdckmartintesting.discoursemail.com>
To: imaptest2@discourse.org
Message-ID: <discourse/post/94@discoursehosted.martin-brennan.com>
In-Reply-To: <discourse/post/93@discoursehosted.martin-brennan.com>
References: <discourse/post/91@discoursehosted.martin-brennan.com>
<discourse/post/93@discoursehosted.martin-brennan.com>
Subject: [The Email Threading Sandbox] [Royal Court] Threading topic 1 for
Пост/Письмо 5
Этот ответ напрямую Посту 4, который, в свою очередь, напрямую отвечает Посту 3.
Date: Mon, 22 Aug 2022 05:05:06 +0000
From: Martin Brennan via The Email Threading Sandbox <notifications@cdckmartintesting.discoursemail.com>
Reply-To: The Email Threading Sandbox <incoming+d66f675a0ce64fcaa2ba6b91e3112b05@cdckmartintesting.discoursemail.com>
To: imaptest2@discourse.org
Message-ID: <discourse/post/95@discoursehosted.martin-brennan.com>
In-Reply-To: <discourse/post/94@discoursehosted.martin-brennan.com>
References: <discourse/post/91@discoursehosted.martin-brennan.com>
<discourse/post/93@discoursehosted.martin-brennan.com>
<discourse/post/94@discoursehosted.martin-brennan.com>
Subject: [The Email Threading Sandbox] [Royal Court] Threading topic 1 for
Пост/Письмо 6
Ответ на ответ, который я отправил по электронной почте. Обратите внимание, что я сохранил (странный) Message-ID, сгенерированный Thunderbird: 12d1ec8f-859c-2339-2c7d-9cb3310756a2@discourse.org.
Date: Mon, 22 Aug 2022 05:16:31 +0000
From: Martin Brennan via The Email Threading Sandbox <notifications@cdckmartintesting.discoursemail.com>
Reply-To: The Email Threading Sandbox <incoming+fb424977c7bd0c8146bdd7302dc35933@cdckmartintesting.discoursemail.com>
To: imaptest2@discourse.org
Message-ID: <discourse/post/97@discoursehosted.martin-brennan.com>
In-Reply-To: <12d1ec8f-859c-2339-2c7d-9cb3310756a2@discourse.org>
References: <discourse/post/91@discoursehosted.martin-brennan.com>
<discourse/post/93@discoursehosted.martin-brennan.com>
<discourse/post/94@discoursehosted.martin-brennan.com>
<discourse/post/95@discoursehosted.martin-brennan.com>
<12d1ec8f-859c-2339-2c7d-9cb3310756a2@discourse.org>
Subject: [The Email Threading Sandbox] [Royal Court] Threading topic 1 for
2022-08-22
Могу ли я сейчас отправить тебе личное сообщение, чтобы настроить для тебя учётную запись на моём тестовом сайте, и мы сможем переписываться, чтобы проверить, соответствует ли это твоим ожиданиям?
От Мартина Бреннана через Discourse Meta, 22 августа 2022 г., 05:36:
@cameron-simpson, думаю, я добился работы так, как описано. У меня настроен mutt, и всё, кажется, правильно группируется в потоки (хотя я не понимаю, почему в потоке отсутствует строка темы, а также не знаю, как настроить отображение моих собственных отправленных ответов внутри потока):
На мой взгляд, выглядит хорошо.
Строка темы в ответах опускается (если она не меняется), что упрощает определение начала нового потока. При желании вы можете сворачивать потоки.
Чтобы видеть свои собственные ответы, необходимо иметь копию ответа в той же папке. За это отвечает настройка $record.
А вот как тот же поток отображается в Thunderbird (на самом деле я заметил, что Thunderbird тоже не показывает мои ответы внутри потока):
Тоже выглядит хорошо.
Вот как это выглядит в Gmail:
Это… довольно громоздко ![]()
Заголовки приведены ниже; ID постов начинаются с
91, то есть пост 1 соответствует ID поста 91.
[…]
Судя по вашему описанию взаимосвязей сообщений, все эти заголовки выглядят корректно.
Я заметил, что Discourse использует заголовок Reply-To с уникальным идентификатором, вероятно, для объединения ответов по электронной почте на основе целевого адреса. Очевидно, это работает. Если бы Discourse формировал его на основе заголовка In-Reply-To ответа, можно было бы использовать более стабильный адрес ![]()
Могу ли я сейчас отправить вам личное сообщение, чтобы настроить для вас учётную запись на моём тестовом сайте, и мы сможем переписываться и отвечать друг другу, чтобы проверить, соответствует ли это вашим ожиданиям?
Конечно!
С наилучшими пожеланиями,
Кэмерон Симпсон cs@cskk.id.au
На самом деле это используется для определения, отправляем ли мы сообщение в Категорию или в Тему, и применяется не так часто, как Message-ID и другие заголовки для In-Reply-To и References.
Спасибо, я отправлю ЛС и приглашение по электронной почте с моего сайта.
Мы уже довольно долго обсуждали этот вопрос, и, похоже, всё работает как ожидалось. Вот пример потока в Thunderbird:
@cameron-simpson, не возражаешь, если я перейду к интеграции этого в ядро Discourse? Ещё раз спасибо за тестирование.
Думаю, мне стоит внимательнее просмотреть References — мне показалось, что в одном из сообщений есть странности, и я отправил несколько ответов по электронной почте, но они, похоже, не были распознаны как таковые? Постараюсь посмотреть сегодня вечером.
Ах, да, я теперь вижу ваш последний пост. Что вы ожидаете в Discourse, когда отвечаете на два сообщения? Не уверен, что мы поддерживаем разбор цитат и их привязку к нескольким сообщениям как ответам, пришедшим по электронной почте. Спасибо за дополнительное изучение References. Если у вас есть собственный экземпляр Discourse и вы хотите протестировать это или просто интересуетесь логикой, код находится в ветке feature/the-phantom-email-thread: https://github.com/discourse/discourse/pull/17996. Его ещё нужно немного доработать.
Редактирование: Нашёл проблему с ответом, отвечаю на тестовом форуме.
От Мартина Бреннана через Discourse Meta, 23 августа 2022 г., 06:16:
Ах да, я вижу ваш последний пост. Чего вы ожидаете в Discourse, когда отвечаете на два сообщения? Не уверен, что мы поддерживаем извлечение цитат и их привязку к нескольким сообщениям в качестве ответов на входящие письма.
Я не ожидал этого. Я ожидал, что Discourse будет смотреть на идентификаторы сообщений в заголовке In-Reply-To, связывать их с соответствующими сообщениями и на основе этого формировать «множественный ответ».
Тем не менее, я даже не знаю, как сделать множественный ответ через веб-интерфейс (в электронной почте это довольно просто, по крайней мере в mutt). Также я не знаю, как вы представляете родительские сообщения в своей базе данных. Вы surely не анализируете сам текст сообщения?
Спасибо за дополнительное рассмотрение заголовка
References. Если у вас есть собственный экземпляр Discourse и вы хотите протестировать это или просто интересуетесь логикой, код находится в веткеfeature/the-phantom-email-thread, см. https://github.com/discourse/discourse/pull/17996. Это всё ещё требует небольшой доработки.
Спасибо, я посмотрю. Мне нужно сесть и нарисовать схему нашего тестового обсуждения, а затем проверить различные заголовки на её соответствие; сегодня я был слишком рассеян.
С уважением,
Кэмерон Симпсон cs@cskk.id.au
Я добавил несколько комментариев, но мой мозг уже отключается. В частности, комментарии к add_identification_field_headers, вероятно, не совсем верны — это резервный/исходный код для случая, когда этот новый экспериментальный режим не включён? Комментарии к add_experimental_identification_field_headers более актуальны.




