Фиксация опечаток во вводимых пользователями адресах электронной почты
Я думаю, что это - хорошая идея, как объяснить, что проблема действительно с виртуальными хостами и SSL/TLS.
Когда Вы соединяетесь с апачским сервером по HTTP, Вы отправляете ряд http заголовки вперед. Они похожи на это:
GET /index.html HTTP/1.1
Host: www.nice-puppies.com
Если у Вас будет виртуальный апач хостинга, то посмотрит на поле хостов, то выберет правильный index.html для Вас. Проблема состоит в том, когда Вы добавляете SSL/TLS. Сервер настраивает шифрование, прежде чем Вы когда-либо отправите свой запрос HTTP. Для этого сервер не знает, идете ли Вы в www.nice-puppies.com или www.evil-haxxor.com, пока аутентификация/шифрование не завершается. Сервер не может предположить (поскольку отправка неправильного сертификата дает Вам противное сообщение об ошибке).
Одним решением является Wildcard-сертификат (как упомянуто выше), который допустим для *.nice-puppies.com. Тем путем можно использовать тот же сертификат для нескольких доменов, но у Вас не может быть *.com сертификата (хорошо, Вы можете, но это было бы очень плохо для всех других), так в целом Вы должны будете разделить IP для каждого домена HTTPS.
Самой большой проблемой будут ложные срабатывания - то есть те опечатки, которые вы исправляете не в том домене.
Используя опечатку, которая, вероятно, не произойдет, вы можете получить:
gotmail.com
вы измените это на
hotmail.com
или
gmail.com
Пользователь мог иметь в виду и то, и другое.
Гораздо проще просто вернуть их пользователю с сообщением «домен не распознан» и позволить ему внести исправления.
Я не вижу проблемы, которую вы пытаетесь решить. Вы хотите отправить подтверждения регистрации. Но поскольку вы не можете отправлять подтверждения регистрации на несуществующие домены, регистрация не будет. Все нормально. Отбросьте пользователя, которого не удалось подтвердить, и позвольте ему снова зарегистрироваться. Вот как это бывает. Это называется Double-Opt-In и ОБЯЗАТЕЛЬНО для проверки адресов электронной почты.
Обычно эти письма даже не должны находиться в очереди:
- Если домен не существует, письмо должно немедленно возвратиться (время сбросить пользователь мгновенно).
- Если домен разрешается, но достигает несуществующего пользователя, почта возвращается немедленно (время, чтобы удалить пользователя).
- Если домен разрешается, но сервер временно откладывает почту, вы можете ' t решить, будет ли почта доставлена позже или это недействительный адрес (время ждать варианта 2 или 4)
- Если домен разрешается и пользователь действителен, почта будет доставлена мгновенно (время ждать подтверждения, но письмо отсутствует в очереди)
Я согласен с ChrisF относительно ложных срабатываний. В последнее время я работал с адресами электронной почты, извлеченными из нашей ERP-системы, и столкнулся со многими проблемами. Например, один из наших основных интернет-провайдеров - Optus. Насколько я помню, основываясь только на том, что не было возвращено, их почтовые домены могут быть любыми из
- optusnet.net
- optusnet.com
- optus.com.au
- optus.net.au
- optusnet.net.au
- optusnet.com.au
... и возможные другие, о которых я не знаю.
Если я увижу недействительный, но похоже, что это должен быть адрес Optus, сделайте Я просто догадываюсь, какой из них правильный? В конце концов, это может быть любой из них или ни один из них.
Я понимаю, что вы пытаетесь сделать, но я бы не стал делать это на уровне DNS. Почему бы вам просто не написать скрипт / код в приложении?
Сверьтесь со списком и попросите посетителя подтвердить доменное имя. Это ошибка пользователя, а не проблема сервера.
У нас есть функция проверки электронной почты, которая проверяет, есть ли в доменном имени для адреса электронной почты запись MX. Помогает предотвратить опечатки, а также значительно снижает объем спама.