Библиотека для канонизации (нормализации, а не просто очистки) адресов электронной почты

Question

Существует несколько способов создания адресов электронной почты. Строки, которые отличаются при прямом сравнении строк (см. Ниже), но логически эквивалентны (т. Е. Почта, отправляемая обоим, отправляется в один и тот же почтовый ящик).Это часто позволяет пользователям давать, казалось бы, уникальные адреса электронной почты, даже если строгое равенство было запрещено.

Я надеялся найти библиотеку, которая попыталась бы выполнить нормализацию, чтобы можно было найти некоторые дубликаты из больших наборов электронной почты.адреса.Цель состоит в том, чтобы найти как можно больше дубликатов.Учитывая, насколько это полезно для нескольких целей (в моем случае это простое обнаружение злоупотреблений, поскольку учетные записи злоупотреблений имеют тенденцию (пытаться) просто повторно использовать определенные учетные записи), я думаю, что могут существовать решения.

Так чтотакие вещи могут отличаться?Я знаю, по крайней мере, такие вещи, как:

• часть имени домена не чувствительна к регистру (согласно DNS);но локальная часть может или не может быть, это зависит от почтового провайдера (например, Gmail считает, что регистр не учитывается)
• многие домены имеют псевдонимы (googlemail.com эквивалентен gmail.com)
• некоторые провайдеры электронной почты допускают другие варианты, которые они игнорируют (например, gmail игнорирует любые точки в адресе электронной почты!)

В идеале это будет в Java, хотя языки сценариев также будут работать (команда-инструмент линии)

Answer 1

Я мог бы найти несколько битов кода в Google , выполнив поиск " нормализовать адрес электронной почты ", но ничего достаточно подробного.Боюсь, вам придется написать свой собственный инструмент.Если бы я написал такой инструмент, я бы применил несколько правил:

Сначала инструмент уменьшит регистр доменного имени (после @).Это не должно быть слишком сложно, если только вы не хотите обрабатывать электронные письма с международными доменными именами .Например, JoE@caFÉ.fR (обратите внимание на акцент на E) должен сначала пройти алгоритм Nameprep .Это приводит к JoE@xn--caf-dma.fr.Я никогда не видел никого с таким международным адресом электронной почты, но я подозреваю, что вы можете найти его в Китае или Японии, например.

RFC 5322 утверждает, что local-partэлектронной почты (до @) чувствителен к регистру , но стандарт de facto практически для всех провайдеров заключается в игнорировании регистра (я никогда не видел адрес электронной почты, чувствительный к регистру, который фактически используется человекомДа, но я предполагаю, что есть еще некоторые системные администраторы, которые используют свои учетные записи электронной почты Un * x, где дело имеет значение).Я думаю, что инструмент должен иметь опцию , чтобы игнорировать регистр для списка доменных имен (или наоборот, чтобы быть чувствительным к регистру только для списка доменных имен).Поэтому на данный момент адрес электронной почты JoE@caFÉ.fR теперь нормализован до joe@xn--caf-dma.fr.

Еще раз, возникает вопрос о международных (иначе говоря, не ASCII) электронных адресахвверх. Что, если локальная часть не-ASCII? Например, что-то вроде 甲 斐 @ 黒 川. 日本 (заявление об отказе: я не говорю по-японски).RFC 5322 запрещает это, но более поздние RFC поддерживают это (см. эту статью в Википедии ).Многие языки не имеют понятия о нижнем или верхнем регистре.Когда они это делают, если вы хотите перейти на строчную форму, убедитесь, что вы используете соответствующие строчные алгоритмы Unicode, это не всегда тривиально.Например, в немецком языке нижний регистр слова «Großes» может быть «grosses» или «großes» (заявление об отказе: я тоже не говорю по-немецки).Таким образом, на данный момент адрес электронной почты «Großes@caFÉ.Fr» должен был быть нормализован до «grosses@xn--caf-dma.fr».

Я не читал подробно RFC 5322, но яЯ думаю, что есть также возможность иметь комментариев на адрес электронной почты , либо в начале, либо в конце локальной части, например (sir)john.lennon@beatles.com или john.lennon (ono).) @ beatles.com.Эти комментарии должны быть удалены (это приведет к john.lennon@beatles.com. Удаление комментариев не совсем тривиально, потому что я не знаю, что делать с вложенными комментариями, а также комментарии, заключенные в двойные кавычки, должны не быть удалено, согласно RFC (если я не ошибаюсь). Например, комментарий в следующем адресе электронной почты не должен быть удален, согласно RFC: "john.(ono).lennon"@beatles.com.

Как только электронная почта, таким образом, нормализуется, я бы применил предложенные вами «специфичные для провайдера» правила . Например, удаление точек в адресах GMail и смешивание эквивалентных доменных имен (googlemail.com == gmail.com, например). Думаю, я бы хотел отделить это от предыдущих шагов нормализации.

Обратите внимание, что Gmail также игнорирует знак плюс (+) и все после него, например, смит+hello_world@gmail.com эквивалентно smith@gmail.com.

Я не знаю других правил провайдера. Дело в том, что этиИмена могут измениться в любое время, вам придется отслеживать их все.

Я думаю, это все.Если вы придумали какой-нибудь рабочий код, мне было бы очень интересно его увидеть.

Ура!

Answer 2

Я использую Apache James Mime4J для анализа адресов электронной почты.

1. Он обрабатывает (комментарии) правильно и удаляет их из localPart и domainPart

2. Правильно обрабатывает «разделенные и заключенные в кавычки» и + помеченные тегом localParts.

3. Имеет методы getLocalPart () и getDomainPart ().

4. Не нормализует локальные части gmail.