Итак, друзья, мы продолжаем цикл наших статей, посвященных пояснению принципов работы почтовых сервисов и служб.
Помните, в прошлой статье мы говорили о курьерах, секретарях, роботе-ханурике?:) Сегодня мы хотим поговорить о дороге, по которой бегают курьеры, а именно о SMTP-протоколе.
SMTP протокол — простой протокол передачи почты.
Что вообще такое “протокол”? В Интернете это слово встречается на каждом шагу: HTTP-протокол, ICMP-протокол, BGP-протокол и т.д., и т.п.
Давайте начнем с самого начала. Итак, Библиотека телефонных номеров в общем понимании, протокол – это соглашение. Просто соглашение. О чем-то. Между кем-то. Вот и все! В техническом же понимании, протокол – это набор правил, по которым осуществляются какие-либо действия. К примеру, HTTP-протокол – расшифровывается как HyperText Transfer Protocol — «протокол передачи гипертекста». Хочу всегда во “Входящие” Это стандарт, по которому взаимодействуют между собой Интернет-браузеры и Web-сервера. Как вы думаете, когда был предложен и разработан этот протокол? Пять лет назад? Десять? А вот и нет! Первая версия была предложена в 1982 году! Епрст! Да из нашей команды никто тогда даже не родился еще, а протокол уже был! Ладно, к делу.
SMTP (Simple Mail Transfer Protocol) — простой протокол передачи почты
Вот именно! ПРОСТОЙ протокол передачи почты! Ха! Если есть простой, то есть сложный? (Черт, его! Тут бы в этом “простом” до конца разобраться!:)) Суть его заключается в том, что два почтовых сервера (наши курьеры из прошлой статьи) передают друг другу команды и получают ответы. Происходит это через 25-й порт (если вас интересует, что такое понятие порта – маякните нам, обязательно поясним).
Набор команд очень ограничен на самом деле, их очень и очень немного. Мы не будем приводить здесь таблицу, а лучше покажем на примере.
Итак, два наших курьера: сервер estismail.com и мифический rogaikopita.com. Письмо идет от Estisa к Рогам-и-копытам.
Пример общения двух серверов
Estismail (E) подключается на 25-й порт Рогов-и-копытов (R) и начинает общение. Как истинный джентльмен, сервер обязан представиться. Это команда HELO (HELLO). В переводе с английского – Привет!:) (В расширениях протокола еще может использоваться команда EHLO – но то уже потом как нить… додумались же разработчики)
E: HELO estismail.com – наш сервер подключился и представился. Вы видите, что бы он хоть что-то еще сказал на первом этапе? Нет! И не увидите. Никаких паролей, никаких ключей, никакой мегасекретности.
R: 220 – Service is ready – И вот теперь подробнее. Вы видите, что ответ – это три цифры сначала, а потом какой то текст. Откроем вам тайну, цифры обязательны, текст может быть произвольным. Т.е. наш протокол описывает такие правила, что сервера должны отвечать цифровыми кодами успешности или неуспешности действий, а уже текст могут потом какой хотят писать. Текст уже зависит от программного обеспечения, его версии, чувства юмора администратора сервера и т.д.
220 – обозначает, что сервер R готов принять нашу почту.
Что же произошло между нашим приветствием и ответом о готовности?
В принципе, что угодно. Сервер R мог проверить наши домен и адрес в своем “черном” или “белом” списке, мог запросить антиспам сервисы на предмет того, рассылал ли наш сервер спам, а может он просто никому еще вообще не известен (в общем, это тема для отдельной статьи попозже). Если бы мы попали в “черный” список или бы были в каком-нибудь спам-листе, то R мог ответить: 421 – Сервис не доступен. Закрываем соединение.
Некоторые почтовые службы, если к ним стучится незнакомый сервер для начала его “отшивают” и требуют, чтобы с ними связалась техническая поддержка и подтвердили свои чистые и непорочные намерения обмена почтой. А другие заносят сервер в список подозрительных и более пристально за ним наблюдают. В общем, каждый как хочет, так и выстраивает свою политику.
Проверка существования адреса
Но продолжим. “R” готов с нами работать.
В далеком прошлом разработчики были идеалистами. Они верили в чистое будущее Интернет-технологий. Поэтому при разработке SMTP-протокола они даже предположили, что сервера перед отправкой почты будут удостоверяться, что адрес, на который они отправляют, вообще существует, и в случае его отсутствия даже не будут передавать почту. Для этого существует команда VRFY (verify – проверить). Итак, мы пробуем удостовериться, что адрес существует:
Отметьте, друзья, эти коды 550 – ящик не существует, и 250 – ок. Мы к ним еще вернемся. 250 – это вообще положительный ответ на практически все команды. Следует отметить, что далеко не все сервера поддерживают эту команду VRFY и отвечают на нее. Поэтому чаще всего она не используется.
Но давайте доберемся уже до отправки собственно письма!:)
E: MAIL FROM: [email protected] – наш курьер говорит, что сейчас будет передавать почту от имени [email protected].
Как вы думаете, какой может быть ответ? Ха! А как вы думаете, могли наш курьер сказать, что почта от [email protected]? Да легко! Вот тут и кроется очень большое количество заморочек и всяких проверок, связанных с фишингом, о которых (опять же) немного позднее.
R: 250 – ok – Допустим, Данные по Вьетнаму что наш адрес отправителя понравился 🙂
E: RCPT TO: <[email protected]> – Ну в общем, почта для директора.
Какой может быть ответ? Эх… 550 – пользователя нет (как и в случае VRFY), 450 – почтовый ящик занят, 251 – это пользователь не наш мы перенаправим вашу почту, 551 – пользователь не наш, поэтому идите туда-то, 552 – места в том почтовом ящике нет, 553 – имя у почтового ящика неправильное… Короче, если не 250 – плохо! Если 250 – можно передавать почту! Кстати, вы можете увидеть все эти ответы в нашей статистике, когда отправляете почту.
Ответ о состоянии дают не сразу
Друзья, сделаем небольшое отступление. Дело в том, что между приемом команды и ответом на нее должно проходить минимальное количество времени. Представьте, сколько проверок должен сделать принимающий сервер за милисекунды, чтобы исключить возможность приема почты для некорректного адреса. А если этот сервер обрабатывает сотни тысяч или миллионы писем в час? Многие почтовые сервисы, чтобы избавиться от подобной проблемы для начала принимают почту для ЛЮБОГО АДРЕСА в своем домене. Т.е. ваш курьер всегда получит ответ 250! А вот дальше, сервер неторопливо все проверит, и если какая-либо проблема, то ответит обратным письмом! Поняли, не? Т.е. не сразу даст ответ в протокол, а ПОЗЖЕ, когда сам решит! И письмом! Чаще всего письмо будет подобной темы: “Mailer daemon on rogaikopita.com: Address unknown” или нечто в таком роде в зависимости от найденной неувязки. Об этом позднее опять таки.
R: 250 – ok – комментарии излишни
E: DATA – мы говорим что начинаем передавать текст письма
E: Bu-ga-ga-ga! Your soul is mine! – мы передали текст письма
R: 250 – ok
А тут опять кроется много и много всего. Мы передали текст письма. Сервер мог его проверить по очень многим параметрам: наличию таких же уже писем, каким-то ключевым словам, наличию подписи и т.д., и т.п. Мог ответить, к примеру, 550 – Spam message rejected – типа спам, отбой. А мог принять, потом обработать и отправить обратно с темой: “SPAM!!! Your message is spam!” и т.д.
E: QUIT – все! Конец связи.
Все предельно просто
Друзья, как видите, Данные по Тайваню сложного особо ничего нет. Но огромное количество заморочек, скрытых истин, подводных камней и исключительных ситуаций.
По сути, на все про все тут едва ли 10 строк общения: