Итак, друзья, мы продолжаем цикл наших статей, посвященных пояснению принципов работы почтовых сервисов и служб.
Помните, в прошлой статье мы говорили о курьерах, секретарях, роботе-ханурике?:) Сегодня мы хотим поговорить о дороге, по которой бегают курьеры, а именно о 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 - проверить). Итак, мы пробуем удостовериться, что адрес существует:
E: VRFY dir@rogaikopita.com - мы спросили, а существует ли такой адрес?
R: 550 - User unknown - нам и ответили, что такого ящика не существует.
E: VRFY director@rogaikopita.com - А вот такой есть?
R: 250 - Ok - А вот этот есть!
Отметьте, друзья, эти коды 550 - ящик не существует, и 250 - ок. Мы к ним еще вернемся. 250 - это вообще положительный ответ на практически все команды. Следует отметить, что далеко не все сервера поддерживают эту команду VRFY и отвечают на нее. Поэтому чаще всего она не используется.
Но давайте доберемся уже до отправки собственно письма!:)
E: MAIL FROM: user@estismail.com - наш курьер говорит, что сейчас будет передавать почту от имени user@estismail.com.
Как вы думаете, какой может быть ответ? Ха! А как вы думаете, могли наш курьер сказать, что почта от obama@whitehouse.gov? Да легко! Вот тут и кроется очень большое количество заморочек и всяких проверок, связанных с фишингом, о которых (опять же) немного позднее.
R: 250 - ok - Допустим, что наш адрес отправителя понравился :)
E: RCPT TO: <director@rogaikopita.com> - Ну в общем, почта для директора.
Какой может быть ответ? Эх... 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 строк общения:
E: HELO estismail.com
R: 220 - Service is ready
E: MAIL FROM: user@estismail.com
R: 250 - ok
E: RCPT TO: <director@rogaikopita.com>
R: 250 - ok
E: DATA
E: Bu-ga-ga-ga! Your soul is mine!
R: 250 - ok
E: QUIT
Но как много сил и нужно, чтобы это все работало, как швейцарские часы...
Мы начинали с фразы, что у нас "простой" протокол передачи почты - да, он то простой, а вот все, что вокруг него - точно не простое:)
Далее будет....
PS: Уважаемые друзья, читатели и коллеги. Мы искренне просим в вас прощения, что практически в каждом абзаце говорим "Об этом позднее" или "Далее будет". К сожалению, физически не получается популярным языком описать все в одном большом тексте. Но мы очень стараемся!
Смотрите, у нас есть намеченный план повествования, но мы бы очень хотели получать от вас фидбек. Если вам интересны наши рассказы, и вам что-то непонятно, или же вы хотите получить больше информации по какому-то отдельному моменту, связывайтесь с нами, говорите нам, мы попробуем!:)
