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

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

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

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

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

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

2 10
email normalization email-validation

2 ответа:

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

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

RFC 5322 утверждает, что локальная часть электронной почты (перед @) чувствительна к регистру , но стандарт де-факто практически для всех поставщиков-игнорировать регистр (я никогда не видел чувствительного к регистру письма адрес на самом деле используется человеком, но я предполагаю, что есть еще некоторые сисадмины, которые используют свои учетные записи электронной почты 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 подробно, но я думаю, что есть также возможность иметь комментарии в адресе электронной почты , либо в начале, либо в конце локальной части, например (сэр)john.lennon@beatles.com или Джон Леннон (Оно)@beatles.com эти комментарии должны быть удалены (это было бы привести к john.lennon@beatles.com удаление комментариев не совсем тривиально, потому что я не знаю, что делать с вложенными комментариями, а также комментарии, заключенные в двойные кавычки, должны не быть удалены, согласно RFC (если я не ошибаюсь). Например, комментарий в следующем адресе электронной почты не должен быть лишен, согласно RFC: "john. (ono). lennon" @beatles.com.

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

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

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

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

Ура!

17

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

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

  2. Он обрабатывает" разнесенные и заключенные в кавычки " и +помеченные локальные части правильно.

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

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

4