Частично утратило актуальность, но: а) речь идёт не только об адресации с плюсом, как я указывал в первом сообщении; б) дело не только в добавлении алиаса, а в том, что поле From становится непригодным для использования, как я писал в пятом сообщении; в) мы говорим не только о Gmail, как я отмечал во втором и последних сообщениях. В любом случае, я считаю, что довольно быстро ориентируюсь в интерфейсе Gmail, но мне было бы трудно добавить и подтвердить новый алиас за десять секунд.
Менее утратило актуальность: есть ли какие-то перспективы у идеи с токеном, о которой я упоминал много раз, но которую игнорировали в пользу нападок на ленивых пользователей Gmail?
Когда речь идёт о псевдонимах Gmail с точкой или знаком «плюс», подтверждение не требуется. Я только что проверил — всё заняло всего 12 секунд.
Да, существуют и другие необычные схемы доставки. Разработчики уже заявляли, что в будущем сделают процесс добавления дополнительных адресов электронной почты для пользователей проще как для администраторов, так и, возможно, для самих пользователей. Однако я не считаю, что им следует прилагать дополнительные усилия для чего-то большего. Если пользователи хотят отвечать на письма, полученные по адресу, с которого они не могут отправлять сообщения, они должны сами нести ответственность за настройку своей почты.
Как опция, которую администраторы могли бы включить, идея с токеном могла бы сработать. Мы уже доверяем пользователям, которые пересылают свои письма с форума другим лицам, возможность отписываться по ссылкам внутри этих писем. Конечно, публикация сообщений потенциально более разрушительна, чем отписка.
В качестве запроса на новую функцию разработчики часто упоминают «правило трёх»: если три человека запросят одну и ту же функцию, они начнут серьёзнее её рассматривать. Или если вы являетесь платным клиентом.
Извините. Я чересчур ленив и не очень талантливый программист Rails, поэтому всегда ищу решения, не требующие изменения Discourse. (Нет, это не сарказм. Недавно я начал обсуждение, чтобы написать плагин за 1000 долларов, и убедил потенциального клиента принять решение, используя только существующие функции.)
Не заглядывая в код, я думаю, что возможно удалить или ослабить проверку адреса отправителя в поле From:, поскольку, как вы предполагаете, токен уникален. И если вас не беспокоит, что кто-то может получить этот токен иным способом (например, через пересланное сообщение?), то вы можете переопределить метод process_destination в плагине и разрешить доставку таких ответов, понимая, что это представляет определённый риск для безопасности. Я думаю, вам нужно просто изменить вот это:
на что-то, что либо разрешает ответ с любого адреса, либо реализует какую-то логику «достаточно ли это похоже», как именно её придумать, я сейчас не вижу (хотя это, конечно, возможно).
Спасибо за это. Очень интересно. Если, как было сказано, уже существуют проблемы безопасности с токенизированными ссылками для отписки (и эти риски считаются приемлемыми), то это звучит многообещающе.
Это кажется довольно очевидным, поэтому я предположил, что, раз никто раньше не запрашивал это, есть какие-то последствия, которые я упустил. Но если это не так, то такой подход выглядит гораздо лучшим способом учесть интересы таких людей, как я, и одновременно удовлетворить скептиков.
Не знаю, кого ещё отметить, чтобы получить их мнение или критику, но что вы думаете об этом, @codinghorror?
Если бы были включены промежуточные пользователи, это позволило бы просто отвечать на письма с любого адреса? Не знаю, я не пробовал такую систему (у меня промежуточные пользователи используются только для обработки писем поддержки).