При B2B-регистрации разрешайте ролевые адреса, если ваш продукт не требует, чтобы каждый пользователь указывал индивидуальный адрес. Адрес support@example.com может быть именно тем контактом, который клиент хочет использовать. Если почта нужна для входа или восстановления аккаунта, попросите подтвердить адрес до включения этих функций.
Если для входа нужен индивидуальный адрес сотрудника, объясните это требование. Для общего адреса, на который клиент хочет получать счета или служебные сообщения, предусмотрите отдельное поле. Отказ по правилам вашего продукта не означает, что адрес технически непригоден.
Что имя адреса говорит о его назначении
Имя ролевого email-адреса указывает на функцию или отдел, например поддержку или продажи. В разделе 3 RFC 2142 описаны имена рабочих ящиков INFO, SALES и SUPPORT. Само имя не подтверждает, что организация создала такой ящик.
Организация может направлять письма одному человеку, в общий ящик или в систему обращений. Классификация адреса не показывает, какой вариант используется. Определение и ограничения признака разобраны в глоссарии ролевых адресов.
Emvero сравнивает часть до @ со своим списком ролевых имен. При совпадении сервис устанавливает checks.role_account в true и добавляет ROLE_ACCOUNT в коды причин. Только для этого сравнения сервис игнорирует регистр букв и убирает тег после знака плюс: support+trial@example.com может совпасть с базовым именем support. Сам адрес получателя при этом не меняется. Сохраняйте исходный адрес для подтверждения и последующих писем. В статье об адресах со знаком плюс объясняется, почему удаление тега может изменить получателя.
Ролевой признак не показывает, сколько людей читают ящик. Отсутствие признака тоже не доказывает, что читатель один. По этому признаку нельзя установить личность, наличие согласия на рассылку или факт злоупотребления пробным доступом.
Выберите правило по назначению поля
Поле email-адреса может быть предназначено для входа, отправки счетов или связи с поддержкой. Решите, какие адреса разрешать, исходя из назначения поля. Ниже приведены рекомендации для вашего приложения; Emvero не применяет их автоматически.
| Для чего нужен адрес | Как поступать с ролевым адресом | Что еще нужно проверить |
|---|---|---|
| Счета или служебные уведомления | Принять адрес, который клиент выбрал для этой задачи. | Действительно ли клиент выбрал этот контакт и может ли адрес принимать письма. Подтвердить доступ к ящику, если от него зависит работа с клиентом. |
| Вход в аккаунт, где разрешено использовать общий ящик | Разрешить регистрацию. Подтвердить адрес до включения входа или восстановления через почту. | Может ли кто-то получить письмо и завершить подтверждение. |
| Вход в аккаунт конкретного пользователя | Попросить индивидуальный рабочий адрес и объяснить требование. Общий контакт хранить отдельно. | Личность и полномочия пользователя с помощью предусмотренных в приложении проверок. Имя адреса их не устанавливает. |
| Пробный доступ, где нужно выявлять повторные регистрации | Не отказывать только из-за ролевого имени. | Историю аккаунта и другие значимые свидетельства злоупотребления. Ролевой адрес не доказывает нарушение, а другой адрес не доказывает, что пришел новый человек. |
Например, клиент хочет использовать alex@example.com для входа и billing@example.com для счетов. Храните каждый контакт вместе с его назначением. Ограничение поля для входа не должно удалять адрес для счетов из карточки клиента.
Даже если для входа требуется индивидуальный адрес, сохраняйте проверки личности и полномочий пользователя. Адрес, похожий на имя человека, дает не больше доказательств личности, чем support@.
Читайте ROLE_ACCOUNT вместе с результатом проверки
По текущим правилам Emvero ролевой признак сам по себе не меняет status или action. Ниже приведен сокращенный пример завершенного результата с ролевым признаком. Он составлен для иллюстрации; это не ответ на реальный запрос:
{
"status": "deliverable",
"action": "allow",
"checks": {
"smtp": "accepted",
"role_account": true
},
"reason_codes": ["SMTP_RCPT_ACCEPTED", "ROLE_ACCOUNT"]
}
Действие allow означает, что проверка не выявила технических оснований отклонить адрес. Приложение может дополнительно потребовать подтверждение почты или индивидуальный адрес согласно своим правилам доступа. Сохраняйте полученный результат и отдельно записывайте решение приложения. Не меняйте deliverable на undeliverable, чтобы обозначить ограничение по правилам продукта.
Другие свидетельства могут изменить общий вывод. Например, проверка ролевого ящика может не дать определенного ответа, а его домен может принимать произвольных получателей. Сопоставляйте status, action, checks и reason_codes, как описано в руководстве по чтению результата проверки. В частности, risky не означает одно фиксированное действие.
Отделите подтверждение от правил допуска
Подтверждение адреса показывает, что в тот момент кто-то получил доступ к письму и выполнил шаг подтверждения в вашем приложении. Оно не доказывает, что этот человек единственный, кто имеет доступ к ящику, и не устанавливает личность конкретного сотрудника. При проверке адреса Emvero не отправляет письмо с подтверждением: ваше приложение должно отдельно отправить его и проверить ответ. Что дает каждый из этих этапов, объясняется в сравнении проверки адреса и подтверждения почты.
На сервере отдельно храните результат проверки, решение о допуске и состояние подтверждения. Подтверждение должно относиться к тому адресу, на который было отправлено письмо. Если человек меняет адрес, запрашивайте подтверждение нового адреса.
Если завершенная проверка вернула unknown, свидетельств для определенного вывода об адресе не хватило. Когда нужно установить доступ к ящику, разрешите продолжить регистрацию, но потребуйте подтверждение до предоставления доступа через почту. Именно это рекомендует действие allow_with_email_confirmation; само подтверждение по-прежнему выполняет ваше приложение. Неопределенный результат не означает, что адрес непригоден.
pending означает, что проверка не закончена. Повторно запросите результат через интервал, указанный в ответе API. Заранее ограничьте время ожидания и решите, как приложение продолжит работу, если результат не будет готов к этому сроку. HTTP-ошибка указывает на проблему с запросом или сервисом. Ни ошибка, ни pending не дают оснований считать адрес undeliverable. В руководстве по проверке формы регистрации описаны общий серверный процесс и варианты продолжения при истечении времени ожидания.
Объясните причину отказа и способ исправить адрес
Если для регистрации требуется индивидуальный адрес, объясните это прямо в форме. Например:
Для входа в этот аккаунт нужен ваш индивидуальный рабочий email-адрес. Общий адрес для счетов или поддержки можно добавить после регистрации.
Используйте такой текст, только если в продукте действительно есть отдельное поле контакта. В другом случае укажите доступный способ исправить адрес. Сохраните введенное значение, чтобы человек мог его отредактировать.
Не пишите «Email-адрес невалиден», если единственная причина отказа связана с вашим правилом для ролевых адресов. Клиент, который пользуется этим ящиком каждый день, получит неверное объяснение. Проверяйте допуск на сервере, даже если показываете подсказки в браузере. Учетные данные API должны оставаться на сервере.
Проверьте правило до включения
Проверьте, как приложение принимает решения, на вымышленных адресах и заранее подготовленных результатах проверки. В таблице предполагается, что приложение уже получило указанный результат. Проверять реальные ящики для этих примеров не нужно.
| Случай | Ожидаемое поведение приложения |
|---|---|
Ролевой признак вместе с deliverable и allow; общие контакты разрешены |
Продолжить регистрацию. Потребовать подтверждение почты, если доступ к аккаунту зависит от доступа к ящику. |
| Тот же результат, но для входа нужен индивидуальный адрес | Объяснить правило допуска и попросить другой адрес для входа. Исходный адрес сохранить отдельно, только если клиент выберет его для связи. |
Ролевой признак вместе с unknown |
Сохранить неопределенный результат. Потребовать подтверждение, если нужно установить доступ к ящику. |
Незавершенная проверка с pending |
Сохранить отметку о том, что проверка не завершена. Повторно запросить результат, пока не истек срок ожидания, а затем применить выбранное правило продолжения. |
| Ролевого признака нет | Применить обычные правила доступа и подтверждения; не делать вывод о личности. |
После включения правила посмотрите, на каком этапе люди прекращают регистрацию, исправляют ли адрес и завершают ли подтверждение. Проверьте также, могут ли клиенты по-прежнему использовать выбранные адреса для счетов. По этим наблюдениям решите, помогает ли ограничение соблюдать требование к доступу, ради которого вы его ввели.
Когда определите правило, используйте API проверки email-адресов на сервере для проверки введенных адресов. Отдельно применяйте правила регистрации и подтверждайте доступ к почте.