Библиотека для канонизации (нормализации, но не просто очистки) адресов электронной почты
существует несколько способов создания строк адресов электронной почты, которые отличаются от прямого сравнения строк (см. ниже), но логически эквивалентны (т. е. почта, отправленная обоим, отправляется в один и тот же почтовый ящик). Это часто позволяет пользователям давать, казалось бы, уникальные адреса электронной почты, даже если строгое равенство было запрещено.
Я надеялся найти библиотеку, которая попытается сделать нормализацию, чтобы найти некоторые дубликаты из больших наборов адресов электронной почты. Цель здесь-найти как можно больше дубликаты, насколько это возможно. Учитывая, насколько это полезно для нескольких целей (в моем случае это простое обнаружение злоупотреблений, поскольку учетные записи злоупотреблений имеют тенденцию (пытаются) просто повторно использовать определенные учетные записи), я думаю, что могут быть существующие решения.
Итак, какие вещи могут варьироваться? Я знаю по крайней мере такие вещи, как:
- часть доменного имени не учитывает регистр (в соответствии с DNS); но локальная часть может быть или не быть, это зависит от поставщика почты (например, Gmail считает это без учета регистра)
- многие домены имеют псевдонимы (googlemail.com эквивалентно gmail.com)
- некоторые поставщики электронной почты позволяют другие варианты, которые они игнорируют (gmail, например, игнорирует любые точки в адрес электронной почты!)
В идеале это будет на Java, хотя скриптовые языки также будут работать (инструмент командной строки)
2 ответов
Я мог бы найти несколько бит кода на Google ища "нормализовать адрес электронной почты", но не достаточно тщательно. Боюсь, вам придется написать свой собственный инструмент. Если бы я написал такой инструмент, Вот несколько правил, которые я думаю, я бы применил:
первый инструмент Нижний доменное имя (после @). Это не должно быть слишком сложно, если вы не хотите обрабатывать электронные письма с международный домен имена. Например, JoE@caFÉ.fR (обратите внимание на акцент на E) должен сначала пройти через Nameprep. Это приводит к JoE@xn--caf-dma.fr - ... Я никогда не видел никого с таким международным адресом электронной почты, но я подозреваю, что вы можете найти некоторые в Китае или Японии, например.
RFC 5322 указано, что local-часть электронной почты (перед@) чувствительна к регистру, а де-факто стандартные практически для всех провайдеры должны игнорировать case (я никогда не видел чувствительный к регистру адрес электронной почты, фактически используемый человеком, но я полагаю, что все еще есть некоторые системные администраторы, которые используют свои учетные записи электронной почты Un*x, где случай имеет значение). Я думаю, что инструмент должен быть возможность игнорировать case для списка доменных имен (или, наоборот, учитывать регистр только для списка доменных имен). Итак, на данный момент, адрес электронной почты JoE@caFÉ.fR теперь нормализуется до joe@xn--caf-dma.fr.
еще раз, вопрос о международном (ака. non ASCII) всплывают адреса электронной почты. что если местный-часть не-ASCII ? например, что-то вроде 甲斐@黒川.日本 (отказ от ответственности: я не говорю по-японски). RFC 5322 запрещает это, но более поздние RFCs поддерживают это (см. эта статья в Википедии). Многие языки не имеют понятия о нижнем или верхнем регистре. Когда они это сделают, если вы хотите изменить форму нижнего регистра, обязательно используйте соответствующие алгоритмы нижнего регистра Unicode, это не всегда тривиально. Например, в немецком языке нижний регистр слова " Großes "может быть либо" grosses", либо" großes " (отказ от ответственности: я тоже не говорю по-немецки). Так что на данный момент, адрес электронной почты "Großes@caFÉ.Fr" следовало бы нормализовать ... "grosses@xn--caf-dma.fr".
Я не читал RFC 5322 подробно, но я думаю, что есть также возможность иметь комментарии в адрес, либо в начале, либо в конец локальной части, такой как (sir)john.lennon@beatles.com или Джон.Леннон (Оно)@beatles.com - ... Эти комментарии должны быть удалены (это приведет к john.lennon@beatles.com - ... Удаление комментариев не совсем тривиально, потому что я не знаю, что делать с вложенными комментариями, а также комментарии, заключенные в двойные кавычки, должны не быть раздетым, согласно RFC (если я не ошибаюсь). Например, комментарий в следующем адресе электронной почты не должен быть удален, согласно RFC: "Джон.(оно).Леннон"beatles.com.
Как только электронная почта таким образом нормализована, я бы применил "поставщика" правила вы предлагаете. Например, удаление точек в адресах GMail и смешивание эквивалентных доменных имен (googlemail.com == gmail.com например). Я думаю, что я бы держал это действительно отдельно от предыдущих шагов нормализации.
обратите внимание, что Gmail игнорирует знак "плюс" ( + ) и все после него, например s.м. Я. т. h+hello_world@gmail.com эквивалентно smith@gmail.com - ...
Я не знаю других правил поставщика. Дело в том, что эти правила могут измениться в любое время, вам придется отслеживать их все.
Я думаю, что это о нем. Если вы придумаете какой-то рабочий код, мне было бы очень интересно его увидеть.
Ура!
Я использую Apache James Mime4J для анализа адресов электронной почты.
Он правильно обрабатывает (комментарии) и удаляет их из localPart и domainPart
ручки "Spaced и процитировал" и " + " помечены localParts правильно.
Он имеет методы getLocalPart() и getDomainPart ().
не нормализует Gmail localParts, хотя.