Дело в том, что принудительное использование канонических адресов электронной почты по сути то же самое, но гораздо менее враждебно по отношению к пользователям.
Например, Sam.sam@gmail.com не разрешён, а Sa.msam+123@gmail.com уже зарегистрирован.
В любом случае, мы можем добавить поддержку регулярных выражений в следующем выпуске.
Да, но на практике это бесполезно, поэтому мы и ведём этот разговор: как только у них появится ядерное оружие, у вас тоже должны быть ядерные боеголовки.Понятие «враждебный пользователю» теряет смысл, как только ваша аудитория обладает ядерным оружием и готова его применить.
Я не согласен с этим: решение отлично сработало для @markersocial, а затем я откатил изменение, так как у меня не было выбора.
В реализации канонизации, которую я внедрил и затем откатил, не обнаружено никаких известных уязвимостей; она на 100% решает описанную выше проблему с Gmail.
Что ж, я не согласен, потому что это возлагает бремя написания кода и усилий на нашу сторону, а не на их. «Нормализация» адресов электронной почты довольно сложна, варьируется в зависимости от провайдера, и я не хочу заниматься этим.
Другими словами, пусть они сами создают и обслуживают ядерные устройства; нам не нужно поставлять протоядерные боеголовки в каждую страну и в каждую установку Discourse «на всякий случай».
(Кроме того, возможность блокировать адреса электронной почты с помощью регулярных выражений очень мощная, особенно поскольку в Discourse электронная почта = личность.)
Мы могли бы позволить им нормализовать данные по своим собственным правилам регулярных выражений в качестве некоего компромисса, тогда нам не придётся заниматься нормализацией.
Тем не менее, да, блокировка с помощью регулярных выражений или, по крайней мере, блокировка с использованием подстановочных знаков будет реализована в следующем выпуске.
Я могу подтвердить, что предыдущая реализация работала безупречно и полностью решила проблему с Gmail. Списки разрешённых и запрещённых доменов электронной почты являются весьма эффективными инструментами. Однако блокировка Gmail просто нецелесообразна.
@codinghorror Я понимаю точку зрения против нормализации для различных провайдеров электронной почты. Но, на мой взгляд, было бы разумно иметь возможность покрывать хотя бы Gmail (по данным 2020 года, около 43% всех адресов электронной почты, а в США — 53%) неразрушающим способом. Это можно сравнить с поддержкой OAuth от крупных провайдеров из коробки.
@sam ^ Это отличная идея для альтернативы. 
Возможно, такой подход, с примером для сопоставления gmail/googlemail, оказался бы весьма удобным для пользователя и мощным инструментом.
Сейчас у нас есть пользователь, который создал несколько тысяч аккаунтов, используя один и тот же адрес Gmail (с точками), и спамит, рекламируя свой конкурентный сайт, чтобы переманить пользователей. Как только выйдет обновление 2.8, мы сразу же заблокируем все адреса электронной почты, содержащие точку или символ «плюс». Жаль, что предыдущая реализация недоступна, но мы ценим, что проблема решается и скоро появится решение. Это внесёт огромные изменения, спасибо
Я немного подумал над этим и придумал решение, которое, возможно, имеет смысл.
Можно добавить опцию для администратора: обрабатывать и хранить нормализованную версию email-адреса (обрабатывая только часть до имени пользователя, т. е. часть до символа @).
Но применять это только для доменов, указанных администратором.
То есть список, похожий на списки разрешённых/запрещённых доменов для email, с двумя флажками для каждого домена:
Затем использовать эти записи как справочник для запрета дополнительной регистрации с альтернативными версиями этого email-адреса (не затрагивая основную запись email, которая может по-прежнему содержать «+» и точки).
Таким образом, бремя выбора доменов, для которых нужно хранить нормализованную запись, и выбора способа нормализации ложится только на администратора, позволяя ему оперативно реагировать на проблемные домены по мере их появления.
В любом случае, просто оставляю это здесь, чтобы это можно было рассмотреть в будущем.
С уважением.
Я объединил PR:
Он добавляет новый параметр сайта «нормализация email», который удаляет точки и часть после знака «+» в адресе электронной почты, а затем проверяет его уникальность. Например, если уже существует пользователь с адресом test+1@gmail.com, а test+2@gmail.com пытается зарегистрироваться, то при включённом параметре сайта регистрация не будет разрешена.
Отлично, я думаю, это на 100% решает проблему @markersocial и является отличным параметром для включения, если вы станете целью этой конкретной атаки.
Дайте нам знать, как у вас получится, @markersocial
Большое спасибо за реализацию этой функции — это огромный успех, я очень рад, что это было добавлено. Я запустил её вчера и сейчас наблюдаю за работой.
Пока что всё работает на 100% как задумано и полностью решает эту проблему. Люди всё ещё могут регистрироваться с точками в адресах электронной почты (и, вероятно, с символом «+», хотя таких регистраций в последнее время не наблюдалось). Но больше нельзя создавать несколько аккаунтов с вариациями одного и того же Gmail-адреса. Из обсуждения на GitHub стало ясно, что сохранение исходного адреса электронной почты без изменений — это лучшее решение.
Исходя из этого, я хочу оставить несколько предложений, которые, на мой взгляд, помогут улучшить эту функцию, не усложняя её чрезмерно:
Вместо чекбокса для включения/выключения функции «нормализация адресов электронной почты» лучше сделать два списка, аналогичных стилю списка блокируемых доменов электронной почты:
Например:
Администратор добавляет gmail.com в оба списка нормализации доменов.
e.mai.l+123@gmail.com → email@gmail.com
Пользователь добавляет outlook.com только в список нормализации символа «+»:
us.er+123@outlook.com → us.er@outlook.com
То, что адреса us.er@email.com и user@email.com считаются одним и тем же аккаунтом, характерно лишь для нескольких провайдеров и не является стандартом. В то же время использование символа «+» — это стандарт (для любых провайдеров, которые его поддерживают).
Такой подход позволит администраторам точечно применять эти правила к проблемным доменам по мере их появления, вместо того чтобы применять нормализацию (обоих типов) ко всем доменам электронной почты.
Не жду, что мои предложения будут реализованы, просто оставляю их на случай, если они окажутся полезными.
В любом случае, ещё раз спасибо, я действительно очень признателен за то, что эта функция была реализована. Это настоящий прорыв.
Хотя мне интересно, является ли это теоретической или реальной проблемой. Я понимаю стремление к точности, но хотел бы услышать о нескольких конкретных случаях, когда это вызывает проблемы.
Проблема внедрения такой настройки заключается в необходимости повторно применять правила нормализации при изменении списка разрешённых сайтов; это сделало бы изменение очень сложным.
Сейчас мы нормализуем безусловно (независимо от настройки сайта), поэтому включение этой функции происходит мгновенно и применяется ко всей истории.
Отлично 
Всё благодаря @nbianca
Отлично! Я не осознавал, что это будет применяться ретроспективно. Я думал, что нормализованный адрес сохраняется только для новых регистраций.
Да, основная вероятность возникновения проблемы — это случаи с адресами электронной почты, которые поддерживают псевдонимы с символом «+», но не считают точки в разных позициях одинаковыми.
Все случаи использования символа «+» в адресах электронной почты можно обрабатывать одинаково без каких-либо проблем, поскольку, насколько мне известно, все провайдеры, поддерживающие эту функцию, делают это одинаково. Точки — это единственный случай, когда существуют различия между провайдерами.
Если я правильно помню, корпоративная почта Google (с использованием пользовательских доменов), Yandex и Outlook считают адреса с разным расположением точек разными, но при этом псевдонимы с символом «+» всё ещё можно использовать.
Таким образом, единственные случаи будут похожи на ситуацию, когда существование адреса theirs@email.com блокирует регистрацию адреса the.irs@email.com (хотя согласно этому домену или провайдеру электронной почты это фактически два уникальных аккаунта/адреса). В реальном мире это должно происходить очень редко. 
Эта тема была автоматически закрыта через 16 часов. Новые ответы больше не принимаются.