Зачем добавлять сложную зависимость, когда гораздо проще реализовать и понять режим блокировки по простому адресу электронной почты? К тому же это открывает нам новые возможности для эксплуатации. Нет уж, спасибо!
Учитывая редкость этой жалобы и исключительные обстоятельства вокруг неё, я считаю, что предпочтительнее выбрать простой, но сверхстрогий подход.
Простой путь — запрещать всё, что не соответствует шаблону /a-zA-Z0-9/, — работает, но создаёт серьёзные проблемы с удобством использования: многие пользователи не будут знать, как зарегистрироваться, и нам понадобятся новые сообщения об ошибках. Многие пользователи Gmail не знают, что janedoe@gmail.com является их рабочим адресом электронной почты, так как они всегда считали, что это jane.doe@gmail.com. Такой запрет повлияет на OAuth и приведёт к сбоям входа через Gmail, чтобы всё работало корректно.
Адрес электронной почты:
sam.s@gmail.com
ОШИБКА: символ.не разрешён в адресах электронной почты (новое сообщение)
Нормализация менее враждебна к пользователю и не требует изменений в UX.
Мы могли бы начать с более простого опционального нормализатора (удаление тегов, удаление точек для Gmail).
Тем не менее, чтобы быть на 100% понятным: я не предлагаю здесь использовать зависимость, email_address не работает и не подходит для наших целей.
Внедрение поспешного полумеры лишь создаст настройку сайта «ломать электронную почту на моём сайте», к добавлению которой я не особенно склонен.
Правильно, но его сайт находится под осадой. Тысячи таких дублирующихся аккаунтов регистрируются там ежедневно. Поэтому разумно ввести простой режим полной блокировки для адресов электронной почты, предлагая его сайтам, которые ведут войну с Моссадом и проигрывают её с огромным отставанием.
Война требует жертв. Будут жертвы среди мирного населения. Его сайт уже сломан до невозможности.
В идеале вам нужна таблица с поставщиками электронной почты и инструкциями по «очистке» для каждого из них (именно то, что вы процитировали). Как хорошо объяснил Барт, дело не в том, чтобы запрещать использование адресов с определёнными символами, а в том, чтобы уметь определять, какие адреса на самом деле идентичны.
Конечно, спамеры, которые очень этого хотят, всегда смогут это сделать. Это как с сигнализациями/замками и ворами: цель — усложнить задачу.
Создание x аккаунтов Gmail — это спам в Gmail, и это их проблема (даже если потом эти аккаунты могут быть использованы для спама вам).
Я не понимаю.
Если мы рассматриваем bob.test+100@gmail.com как bobtest@gmail.com внутренне и храним его таким образом (когда переключатель включён), то какая именно жертва здесь приносится?
Ошибка касается конкретно gmail, поэтому мне кажется чрезмерной реакцией запретить все точки повсюду только потому, что Google решил изобрести спецификацию и нормализовать адреса. Логика очистки довольно проста, и это будет опционально, выключено по умолчанию.
@Mevo, чтобы было на 100% ясно: предложение Джеффа здесь состоит в том, чтобы добавить «режим катастрофы». В режиме катастрофы bob.test@gmail.com является недействительным email, который нельзя использовать.
Я бы предложил сравнивать с упрощённой формой, но при этом необходимо быть осторожным и продолжать хранить и пересылать письма на изначально указанный адрес.
У вас нет согласия пользователя на отправку сообщений любой другой вариации, а использование адреса, отличного от указанного им, может привести к тому, что он не получит сообщение.
В качестве примера: у меня есть Gmail-адрес, созданный в первые месяцы существования сервиса. Письма, отправленные на базовый алиас, фактически отбрасываются. Видимыми оказываются только письма, приходящие на конкретные адреса с плюс-адресацией.
Будьте также осторожны с предположениями — многие пользователи Gmail даже не знают, что точки необязательны. Подавляющее большинство никогда не слышали о плюс-адресации. Попытки предотвратить злоупотребление вторым вариантом могут привести к жертвам в первом.
@sam, я прекрасно понял, что имел в виду Джефф, и, как и ты, я против его предложения (без обид, разногласия случаются).
Это, возможно, придирки, но хранение только «очищенного» адреса электронной почты лишит возможности тех легитимных пользователей, которые делают это намеренно. Пример: пользователь, регистрирующийся (абсолютно легитимно и только один раз) с адресом bob+meta@example.com или bob+forums@example.com, потеряет то, чего он пытался добиться. Проблема в том, что он будет получать письма только на bob@example.com, а это не то, что он хотел (например, он мог использовать «тег» для сортировки полученных писем в отдельную папку).
Я полностью понимаю, что учёт этого момента немного усложнит задачу. Вам нужно будет хранить ОБА варианта: тот, который ввёл пользователь (для отправки писем), И очищенный вариант. Очищенный вариант можно использовать так же, как вы сейчас используете адреса электронной почты (для всего, что внутренне связано с пользователем, и для проверки, зарегистрирован ли этот пользователь уже). Кроме того, чтобы избежать описанной проблемы, вам нужно будет дополнительно хранить то, что ввёл пользователь (исключительно для отправки писем). Это будет аналогом адреса «ответить на» в электронной почте.
Надеюсь, я всё понятно объяснил.
РЕДАКТИРОВАНИЕ: Написано одновременно с @Stephen (в целом та же идея)
Это очень важный момент, это действительно немного усложняет реализацию.
Думаю, проверку стоит выполнять только при «создании новой учётной записи»:
Существует ли в системе уже какой-либо адрес электронной почты с этой канонической формой? Если да, извините, новая учётная запись вам не положена.
Есть ещё побочная проблема с Google OAuth (проверит ли он тоже канонический адрес электронной почты) и переход от неканонического к каноническому адресу.
Насколько я знаю, OAuth не работает с плюс-адресацией, так что это, разве не выходит за рамки?
Я имею в виду, что я не могу создать новый аккаунт через Google, указать другой псевдоним и повторить процесс.
Та же проблемная область.
Я регистрируюсь с адресом sam+hi@gmail.com … затем нажимаю кнопку «Войти через Google». Что произойдет?
В настоящее время: создается новая учетная запись.
Предлагаемое решение:
Вариант A: экран ошибки, создание этой учетной записи невозможно.
Вариант B: пользователь входит в систему с адресом sam+hi@gmail.com.
В первоначально предложенном режиме блокировки вход через кнопку «Войти через Google» для адреса sam.test@gmail.com невозможен.
Если вы сможете разработать надежное решение для удаления плюс-адресации и лишних точек, вы сможете просто хранить хэш дедуплицированного адреса электронной почты и сравнивать его с данным при создании учетной записи.
Это вариант B, поэтому «существует побочная проблема с Google OAuth» 
Кроме того, вопрос миграции сложен, но, вероятно, его можно пропустить.
Тем не менее, учитывая масштаб этой проблемы в реальных условиях, я не ожидаю, что мы будем работать над какими-либо изменениями в ближайшие несколько месяцев.
Как уже говорилось выше, разве не решением будет использовать внутри только «каноническую» версию, а дополнительно хранить то, что ввёл пользователь (просто для отправки писем)?
Мы вполне можем решить эту проблему: по моим оценкам, на тестирование и отладку такого нового переключателя потребуется от 2 до 6 дней работы, так как есть множество мелких деталей, которые нужно учесть.
Проблема в том, что @codinghorror не может обосновать выделение такого количества времени на эту функцию.
Мы можем реализовать настройку «сломать кучу email-входов» за один день работы, но я не хочу, чтобы такая настройка была в Discourse.
Так что вы оказались в немного сложной ситуации, @Mevo… Нужно, чтобы больше людей столкнулись с этой проблемой и сообщили о ней, чтобы мы могли обосновать выделение времени на её решение.
@sam, я понимаю.
(кстати, я вижу это впервые. Ваш пост был автоматически отредактирован: " [system] — Автоматически удалена цитата всего предыдущего сообщения". Вау! Это очень удобная функция!)
Вам необходимо быть крайне осторожными и никогда не хранить каноническую версию. Пользователь не давал согласия на её предоставление, и в случае компрометации ваших таблиц с данными пользователей они не смогут легко определить, какой сервис скомпрометировал их данные.
Facebook неоднократно попадал в серьёзные неприятности из-за хранения PII, связанной с пользователями, которые не предоставляли эти данные и не давали согласия на их привязку к своим аккаунтам.
Лично я не вижу в этом настройке никаких проблем, я просто не хочу этого делать из-за того, что «у одного парня когда-то была проблема».
Да, это ужасная идея предложить добавить это в Discourse. Я бы яростно выступил против её добавления. К тому же адресация — это функция, она всегда была функцией, и она удобна для пользователя.
Если на вас нападает Моссад.. включите режим атаки Моссада. Нам просто нужно, чтобы Моссад атаковал больше людей, я полагаю? 
Я категорически против добавления этой настройки в Discourse. Я совершенно не против, если кто-то создаст для этого плагин — это всего лишь несколько строк кода в плагине. Если вам обязательно нужна эта настройка, я могу взять перерыв и создать плагин сегодня, просто дайте знать.
В принципе, создавать его бессмысленно, так как единственный человек, у которого возникла проблема, уже заявил, что не будет её использовать.
Настройка с названием «сломать мой Discourse» фундаментально плоха и, на мой взгляд, не должна входить в продукт.
Я думаю, что если бы проблема возникала у большего числа людей, режим блокировки по электронной почте был бы более обоснованным. Но сейчас это касается лишь одного человека на одном сайте.
Так что остаётся ждать и смотреть…
Один парень, на одном сайте, который не стал бы использовать эту функцию
…это было бы точнее…