локальная часть email что это

Я знал, как валидировать email-адрес. Пока не прочитал RFC

От переводчика: прочитав статью, начал было отвечать в комментариях, но решил, что текст, на которую я собирался ссылаться, достоин отдельной публикации. Встречайте!

Если вы знаете, как валидировать email-адрес, поднимите руку. Те из вас, кто поднял руку — опустите её немедленно, пока вас кто-нибудь не увидел: это достаточно глупо — сидеть в одиночестве за клавиатурой с поднятой рукой; я говорил в переносном смысле.

До вчерашнего дня я бы тоже поднял руку (в переносном смысле). Мне нужно было проверить валидность email-адреса на сервере. Я это уже делал несколько сот тысяч раз (не шучу — я считал) при помощи классного регулярного выражения из моей личной библиотеки.

В этот раз меня почему-то потянуло ещё раз осмыслить мои предположения. Я никогда не читал (и даже не пролистывал) RFC по email-адресам. Я попросту основывал мою реализацию на основе того, что я подразумевал под корректным email-адресом. Ну, вы в курсе, что обычно говорят о том, кто подразумевает. [прим. перев. Автор имеет в виду игру слов: «when you assume, you make an ass of you and me» — «когда вы (что-то) подразумеваете, вы делаете /./удака из себя и из меня»]

И обнаружил кое-что занимательное: почти все регулярные выражения, представлены в интернете как «проверяющие корректность email-адреса», излишне строги.

Оказывается, что локальная часть email-адреса — то, что перед знаком «@» — допускает гораздо более широкое разнообразие символов, чем вы думаете. Согласно разделу 2.3.10 RFC 2821, который определяет SMTP, часть перед знаком «@» называется локальной частью (часть после знака — это домен получателя) и предназначена для интерпретации исключительно сервером получателя.

Следовательно — и благодаря длинной череде проблем, вызванных промежуточными хостами, пытавшимися оптимизировать передачу путём изменения их [адресов — перев.], локальная часть ДОЛЖНА быть интерпретирована (и ей должен быть назначен семантический смысл) исключительно сервером, указанным в доменной части адреса.

Адресная спецификация представляет собой определённый идентификатор в сети Internet, содержащий локально интерпретируемую строку, за которой следует знак «эт» («@», ASCII-код 64), за которым, в свою очередь, следует домен сети Internet. Локально интерпретируемая строка представляет собой либо обрамлённую кавычками строку, либо точечный атом.

Точечный атом — это набор атомов, разделённых точками. В свою очередь, атом определён в разделе 3.2.4 как набор алфавитно-цифровых символов и может включать в себя любые из нижеследующих символов (знаете, те самые, которыми обычно заменяют мат)…

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

RFC 3696, Application Techniques for Checking and Transformation of Names, был написан автором протокола SMTP (RFC 2821) как человекочитаемое руководство по эксплуатации SMTP. В третьем разделе он приводит примеры корректных email-адресов.

Это таки корректные email-адреса!

Ну-ка, прогоните их через ваш любимый валидатор. Ну как, много прошло?

По приколу я решил попробовать написать регулярное выражение (спасибо, мне уже доложили, теперь у меня две проблемы), через которое они все прошли бы. Вот оно.

Учтите, что это выражение подразумевает, что чувствительность к регистру выключена (RegexOptions.IgnoreCase в .NET). Согласен, весьма уродливое выражение.

Я написал юнит-тест, чтобы продемонстрировать все случаи, которые оно покрывает. Каждая строка содержит email-адрес и флаг — является он корректным или нет.

Прежде, чем вы назовёте меня жутким занудой и педантом (может, вы и правы, но всё равно погодите), я не думаю, что настолько глубокая проверка email-адресов абсолютно необходима. Большинство email-провайдеров имеют более строгие требования к email-адесам. Например, Yahoo требует, чтобы адрес начинался с буквы. Похоже, что имеется стандартизированный более строгий набор правил, которому следует большинство email-провайдеров, но насколько мне известно, он нигде не задокументирован.

Думаю, я создам email-адрес типа phil.h\@\@ck@haacked.com и начну жаловаться в техподдержку на сайтах, которые требуют ввода email-адреса, но не позволяют мне создать учётную запись с этим адресом. Люблю шалить!

Мораль заключается в том, что полезно время от времени бросать вызов предрассудкам и предположениям, а также никогда не подпускать меня к RFC.

Источник

Никогда не проверяйте e-mail адреса по стандартам RFC

Множество сайтов требуют от пользователя ввода адреса электронной почты, и мы, как крутые и щепетильные разработчики, всегда стремимся проверять формат введенных адресов строго по стандартам RFC. Благодаря этому наши приложения и сайты проверяют формат e-mail корректно и не имеют проблем с юзабилити, а мы сладко спим, потому что уверены, что все работает как надо.
Ага, как бы не так!
Приведенные выше аргументы звучат круто и железобетонно, но проблема здесь заключается в том, что в адресе почты могут находиться совершенно бессмысленные вещи, и, на деле, проверка адресов по стандартам RFC может, наоборот, все жутко запутать.
Почему так? Существует множество способов сформировать адрес почты, который будет одновременно и корректным и бредовым. Отчасти это происходит из-за того, что некоторые почтовые службы в целях обратной совместимости позволяют представлять адреса в форматах, которые давно устарели. Например это электронная почта существовавшая до появления DNS и до появления современного формата user@domain.tld: тогда использовались UUCP ”bang path” — адреса, которые представляли собой список всех узлов по маршруту ответственных за доставку.

Внутренности адреса почты

Адрес e-mail выглядит так:

Тут mailbox может быть локальным аккаунтом пользователя, аккаунтом роли или маршрутизатором автоматизированной системы такой, например, как список рассылки, а в качестве hostname может быть использован любой узел, если о нем известно DNS-серверу, к которому обращается почтовик при доставке.
Кроме того, некоторые системы позволяют добавлять теги к адресу. Обычно это происходит в формате:

где тег и разделитель (обычно это «+», но qmail использует «-» по-умолчанию, хотя может быть сконфигурирован и иначе) игнорируются при доставке. Обычно это используется для фильтрации почты по папкам и автоматизации, но может быть использовано и для разделения введенных адресов по получателям и выявления злоупотреблений персональными данными.
Итак, в адресе в формате «mailbox@hostname», «mailbox» является пользовательским аккаунтом, приложением или аккаунтом системной роли, но может содержать и такие экстравагантные вещи, как информацию для дальнейшей маршрутизации или идентификаторы используемые для сортировки, автоматизации или отслеживания, а «hostname» — обычно доменное имя, но может являться и субдоменом, сервером, сервисом, ip-адресом или просто именем хоста.

Корректные имена ящика с точки зрения RFC

Специцификация одобряет довольно странные адреса, и было бы накладно поддерживать их все потому, что некоторые слишком сложны, и не слишком много людей обладают достаточными знаниями чтобы выделывать такие пируэты в нейминге. Поддержка таких адресов затруднит поддержку таких аккаунтов вашими сотрудниками, к тому же они почти никогда не используются в быту.
Ящик может содержать пробелы. Насколько я помню, доинтернетовский AOL разрешал пробелы в «Imya Polzovatelya», которые использовались еще и как почтовые ящики с вырезанными оттуда пробелами: «imyapolzovatelya@aol.com», однако ж согласно RFC вы можете использовать двойные кавычки вокруг ящиков содержащих пробелы:

Кстати говоря, по этой логике, ящик содержащий всего лишь пробел корректен:

А вот еще один корректный адрес, он создан из допустимых для адреса символов:

Кстати, проверяйте апострофы, апострофы должны поддерживаться:

Апострофы не должны закавычиваться или эскейпиться, но когда вы сохраняете такие адреса в базу или передаете еще куда-то, убедитесь, что всё чики-пуки.
В Википедии есть еще куча примеров.
Нужна ли полная совместимость с RFC? Вам выбирать, но я не советую — пробелы и нестандартные символы в адресе довольно необычная штука и чаще всего являются просто опечаткой. Крупные e-mail провайдеры не разрешают использовать это примерно по тем же причинам; таким образом обычно достаточно дозволять буквы, цифры, точки, подчеркивания, дефисы, апострофы и плюсы.

Регистрозависимые адреса

Согласно RFC уникальность адреса определяется его регистрозависимой уникальностью, однако 99,9% провайдеров считают иначе и не позволяют регистрировать VasyaPetrov@example.com, если vasyapetrov@example.com уже зарегистрирован. Считайте, что имя почтового ящика регистронезависимо:

Небольшая кучка систем использует полную проверку регистра, позволяя лишь адрес Allen@example.com и отбрасывая входящую корреспондецию всех остальных АлЛеНоВ, однако это не работает на практике, поскольку пользователь не привык различать регистр в адресах почты.
Должны ли вы тут сохранять совместимость с RFC? Конвертируя адреса в нижний регистр перед сохранением вы можете доставить проблем небольшому количеству пользователей (вы не сможете посылать им письма), но отослав миллионы e-mail я столкнулся с этим всего несколько раз.
Конвертация в адреса в нижний регистр является неплохой идеей в плане нормализации данных, так как домен всегда регистронезависим и должен быть в нижнем регистре. Если же вы решите сохранять адрес так, как он введен, добавьте поле, в котором будет хранить каноническую версию.

Нестандартные символы

Gmail тут отличился: в то время как стандарт включает в себя точку как стандартный символ, Gmail не делает различий между адресами ящиков с точками и без. Эти адреса указывают на один и тот же почтовый ящик:

Обратите внимание, что Google Apps позволяет использовать Gmail на любом домене.
Основная проблема здесь заключается в поиске адреса в базе в том виде, в котором он был изначально введен, что может доставить немало геморроя как пользователю, так и службе поддержки, а также и программистам с тестировщиками. Тут то вам и пригодится вторая, канонiческая форма адреса, но об этом позже.

Расширенная форма названия ящиков с использованием тегов.

Но нужно ли вычищать теги из адреса ящика?
НЕТ! Будьте дружелюбны к своим пользователям, и пользователи проникнутся верой, что вы не осуществите хищение и сбыт их персональных данных с целью наживы. Даже если вы пытаетесь запретить регистрацию дополнительных аккаунтов с существующим ящиком, представьте себе, насколько просто в наше время тупо зарегистрировать еще один ящик чтобы снова зарегистрироваться у вас — не сложнее создания алиаса или папки(но об алиасах, папках и тегах, наоборот, мало кто знает).
Итак, еще раз. Создание второй, канонической, формы сохранения адреса в базе может неплохо прикрыть вашу за вас в случае неприятностей. Убедитесь, что вы ликвидировали из нее все теги, точки и т. д. и можете сравнивать с ней свежевведенные адреса.

Юникод и интернационализированные имена ящиков

Доменные имена

У почтовых доменов те же самые ограничения как и в HTTP: они регистронезависимые, так что их следует нормализовывать в нижний регистр.

Поддомены

Некоторые адреса содержат ненужные поддомены: например, «email.msn.com» и «msn.com» являются одним и тем же почтовым доменом, кроме того, такие истории часто случаются в корпоративной среде (и это еще один хороший кандидат для каноникализации).

Интернационализированные домены (IDN )

IDN были созданы для того чтобы использовать местные символы Юникода в названиях доменов, кроме того, возможно создать домен и со специальными символами:

этот классно описывает круговорот воды в природе.
Как и HTTP, SMTP поддерживает лишь 7-битную кодировку, и для того чтобы справиться с этим несчастьем IDN конвертируются в Punycode, что позволяет имени домена конвертироваться в представление Юникод и обратно:

Очень жаль, но существует возможность фишинга при использовании IDN. Юникод содержит несколько разных экземпляров некоторых символов ASCII. Это позволяет злоумышленнику создать сайт, название которого выглядит точно также как и оригинал из-за того, что некоторые символы в названии совпадают внешне, но не внутренне.
Это порождает несколько вопросов на которые следует ответить:
Должны ли мы дозволять IDN-адреса? Можем ли мы обеспечить саппорт пользователей службой поддержки (откуда у саппорта, например, клавиатуры с китайскими иероглифами?) Должны ли мы сохранять их в Юникоде или Punycode? Если мы сохраняем каноничные адреса, то в какой кодировке это делать? Поддерживает ли вообще наш почтовик (MTA) IDN, и в какой форме он ждет адреса при отправке писем?

IP Address syntax

Использование IP-адресов допустимо:

Однако такие адреса выглядят подозрительно, и вряд ли им стоит доверять.

Временные почтовые адреса

Существует множество сервисов, которые предоставляют пользователям временные почтовые адреса. Обычно это используется для анонимности или для того чтобы регистрироваться на недоверенных сайтах.
Даже такие сервисы как Hotmail и Yahoo предоставляют алиасы, которые могут быть использованы примерно тем же способом, то есть уничтожены через некоторое время. Не существует единой техники выявления таких адресов — в конце концов именно для этого они и предназначены. Они используют большущий набор доменных имен с постоянной ротацией для того чтобы быть на шаг впереди тех, кто пытается пресечь их деятельность.

Источник

email

Формат адреса электронной почты следующий:

где локальная часть(local-part) может быть до 64 символов, а доменное имя(domain) может содержать не более 253 символов. Максимальная длина всего(вместе с символом @) адреса электронной почты(email) = 256 символов.

В локальной части адреса электронной почты можно использовать любой из следующих символов ASCII:

1. Строчные и прописные английские буквы (a–z, A–Z) (ASCII: 65-90, 97-122)

2. Цифры от 0 до 9 (ASCII: 48-57)

(ASCII: 33, 35-39, 42, 43, 45, 47, 61, 63, 94-96, 123-126)

5. Специальные символы разрешены с ограничениями, в том числе:
Пробел и «(),:;<>@[\] (ASCII: 32, 34, 40, 41, 44, 58, 59, 60, 62, 64, 91-93)

Ограничения для специальных символов заключается в том, что они должны содержаться в кавычках и что перед специальными символами (пробел, обратная косая черта \ и кавычка » (ASCII: 32, 92, 34) должна предшествовать обратная косая черта \ (например, «\»\\\ «).

Строка в кавычках может существовать если она отделена точками или содержит всю локальную часть (например,
abc.»defghi».xyz@example.com или «abcdefghixyz»@example.com допускается.
abc»defghi»xyz@example.com и abc\»def\»ghi@example.com не допускается).

Многие организации ограничивают допустимые символы.

Доменная часть состоит либо из адреса сайта, либо ip буквально, заключеный в квадратные скобки, например, mach@[192.168.2.1], хотя это большая редкость за исключением спама Ж:-)

Источник

Что такое «валидный формат email-адреса»

Самое главное правило в имейл-маркетинге гласит: отправляйте письма только по валидным адресам электронной почты. Но как понять, что адрес валидный? Давайте для начала разберемся с форматом валидного адреса электронной почты.

Адрес электронной почты — это уникальный идентификатор почтового ящика, который используется для отправки и получения писем, известных как имейлы. Есть два вида адресов — личные и корпоративные.

Личные адреса — это email-аккаунты, созданные на различных mail-серверах. Самые популярные из них это Gmail, Outlook, Yahoo! Mail, и др.

Корпоративные адреса — это адреса электронной почты, созданные на особом домене, предварительно выкупленном компанией. Как правило, такие адреса включают брендовое имя.

Обычно корпоративные имейлы предоставляются всем сотрудникам компании для прямой коммуникации с клиентами и любыми другими людьми по бизнес-вопросам. Такие адреса содержат имя человека или отдел (напр., name@company.com, support@company.com, и т.д.).

С 1980-ых годов существуют определенные правила создания адреса электронной почты. Они регламентированы Инженерным советом Интернета.Чтобы определить, что формат вашего адреса валиден, убедитесь, что у него:

1. Корректная структура адреса

Любой адрес электронной почты состоит из трех элементов: локальная и доменная части и @ (“собака”). Локальная часть находится перед символом @, а доменная — после него. Например, в адресе ivan.ivanov@company.com “ivan.ivanov” — это локальная часть, а “company.com” — доменная. Если хотя бы одна из этих частей отсутствует, имейл адрес автоматически считается невалидным.

Локальная часть — это уникальное имя пользователя, которое идентифицирует почтовый ящик.

Символ «@» («собака») связывает домен и человека, который владеет адресом. Он также указывает на то, что уникальное имя пользователя и доменное имя в одной связке является адресом электронной почты.

Доменное имя указывает на название организации и ведет на ее веб-сайт.

При отправке письма отправляющий mail-сервер проверяет соответствует ли другой mail-сервер доменному имени адреса получателя. Если, скажем, кто-то отправляет сообщение пользователю на домен company.com, почтовый сервер сначала проверяет, отвечает ли почтовый сервер company.com. Если да, он свяжется с почтовым сервером, чтобы узнать, валидно ли имя пользователя. Если же пользователь реален и валиден, письмо будет доставлено.

2. Правильно составленная локальная часть адреса

Локальная часть (имя пользователя) может быть не более 64 символов и содержать:

Обратите внимание: точка (.) может быть использована в локальной части адреса только при условии, что она не находится в начале или в конце адреса. Кроме того, нельзя использовать две точки подряд (например, адрес ivan..ivanov@company.com является невалидным).

Наиболее часто используемыми специальными символами являются точка (.), нижнее подчеркивание (_), дефис (-) и плюс (+).

Локальная часть адреса электронной почты может содержать имя и фамилию человека (например, ivan.ivanov@company.com) или первую букву имени и фамилию (например, I.ivanov@company.com). Имена могут быть написаны с использованием верхнего или нижнего регистра, но оба варианта соответствуют одному email-адресу. Например, если адрес, по которому вы отправляете письмо, это Ivan.Ivanov@company.com, а вы отправляете письмо по адресу ivan.ivanov@company.com, будьте уверены, что оно будет доставлено все тому же Ивану.

3. Корректный формат доменной части адреса электронной почты

Доменное имя состоит из двух частей разделенных точкой (.), например, example.com. Каждая часть должна быть не длиннее 63 символов и может содержать:

Как проверить корректный формат email-адреса?

Невалидные адреса всегда негативно влияют на доставляемость писем и рассылок, а также могут навредить репутации вашего аккаунта.

Источник

Как создать рассылку с использованием сегментации

В статье изучим, что такое сегментация, зачем ее использовать, а также рассмотрим основные примеры реализации рассылки на сегмент контактов.

Содержание

Что такое сегментация в email маркетинге и каковы ее результаты

Сегментация в email маркетинге — это метод разделения базы подписчиков на группы по полу, интересам, потребительским запросам, действиям и другим критериям для повышения открываемости, кликабельности и общей конверсии. Результаты маркетинговых исследований подтверждают, что сегментация работает:

Главные сведения, необходимые для разделения аудитории, собираются прямо в форме подписки и становятся основой для сегментации. Как правило выделяют такие виды сегментации.

Перед тем как сегментировать, у вас уже должна быть создана адресная книга, в которую попадают данные из формы подписки на сайте. Чем больше информации о клиенте вы соберете, тем детальнее можете сегментировать список адресов, что благотворно отразится на релевантности рассылки. На примере ниже Nike выделяет сегменты по возрасту и полу.

Как отправить рассылку по сегменту

Начните создавать новую рассылку. Выберите адресную книгу. Обратите внимание, что сегментация доступна только при выборе одной адресной книги.

В выпадающем списке, которые появится после выбора опции «Сегментировать список», выберите готовый сегмент или создайте новый.

Завершите создание рассылки и отправьте ее. Рассылка будет отправлена на email адреса из выбранного сегмента.

Примеры сегментов

Сегментация по условию «Email: доменная часть»

Email: доменная часть → содержит → gmail

Сегментация по условию «Email: локальная часть»

Часть электронного адреса до @ называется локальной. Часто по локальной части электронного адреса можно определить в каком отделе работает подписчик.

Sales — скорее всего отдел продаж, marketing — соответственно маркетинг, а ceo наверняка принадлежит главному исполнительному директору. Исходя из этого можно отфильтровать нужный сегмент и сформировать уникальное предложение в email рассылке. Для сегментирования задаем следующее условие:

Email: локальная часть → содержит → sales

Сегментация по условию «Email: дата добавления»

Выборка подписчиков по дате добавления/регистрации дает возможность формировать программы лояльности чтобы мотивировать подписчиков в зависимости от того, как долго они с вами. Например, вы хотите подарить скидку по поводу годовщины подписки. Для выделения сегмента по дате добавления задайте такое условие:

Email: дата добавления → равно → укажите желаемую дату

Также данная переменная будет полезна для работы с новыми подписчиками, которые всегда более активно открывают и кликают письма, чем остальные адресаты

Сегментация по условию «Не открывал рассылок»

Вы можете выделить сегмент подписчиков, которые не открыли вашу рассылку. Возможно, им не интересна тема, пробуйте тестировать время отправки и подход к созданию темы рассылки и прехедера.

Для создания такого сегмента создайте условие:

«Не открывал рассылок» → выберите из выпадающего списка нужную рассылку

Сегментация по условию «Email: в списке уникальных»

Вы можете выделить сегмент контактов, которым вы уже отправляли рассылки в этом тарифном периоде и которые числятся в вашем списке уникальных. Для создания такого сегмента выберите условие:

Email: в списке уникальных → равно → в списке уникальных

При сегментации списка рассылки вы уменьшаете аудиторию вашей рассылки, но в этом и цель. Выделив несколько таких сегментов, вы сможете точнее подобрать контент. Вариантов для сегментации множество, главное собрать нужную информацию о подписчиках в форме подписки, а статистику по действиям соберет SendPulse.

Больше возможных вариантов сегментов читайте в статье Как создавать и использовать сегменты контактов.

Оценка: 4 / 5 (18)

Источник