Дорогі читачі блогу, давно я не писала нових статей, але це є Об'єктивні причини. Дуже рада, що ви продовжуєте коментувати мої попередні статті та залишатись читачами нашого блогу. Постараюся найближчим часом надолужити втрачене і порадувати вас масою цікавих і корисних статей. Сьогоднішня стаття буде присвячена SMTP серверам, які є незамінними в розсилках email повідомлень.

SMTP – це протокол, який відповідає за прийом повідомлень, що надходять від користувача, та передачу їх конкретному одержувачу. Повідомлення завжди проходять через кілька серверів, щоб досягти пункту призначення, і SMTP полегшує цю процедуру.

Припустимо, ви надсилаєте повідомлення конкретному одержувачу. Ваш e-mail ID, наприклад, «user» і у вас зареєстрований обліковий запис на «mail.ru» – « [email protected]». Адреса одержувача - " [email protected]».

Коли ви створили обліковий запис на поштовому сервісі «mail.ru», ваш поштовий клієнт (наприклад, Microsoft Outlook) автоматично зберіг налаштування облікового запису. Що відбувається далі:

1. Поштовий клієнт зв'язується з вашим поштовим сервером "Mail.ru" через порт 25.
2. Поштовий клієнт зв'язується з SMTP сервером поштового сервера, повідомляючи адреси відправника і одержувача, і текст повідомлення.
3. SMTP сервер розбиває адресу одержувача на дві частини: ім'я/логін одержувача (recipient) та доменне ім'я (gmail.com).
4. SMTP сервер «спілкується» з сервером DNS(Domain Name Server) та отримує інформацію про IP адресу SMTP сервера одержувача gmail.com. DNS у відповідь надсилає одну або кілька IP-адрес SMTP серверів, які використовує gmail.com.
5. SMTP сервер на mail.ru зв'язується із SMTP сервером gmail.com через порт 25. І передає на нього повідомлення. SMTP сервер gmail.com визначає, що доменне ім'я для «recipient» існує на gmail.com, і передає повідомлення POP3 серверу gmail.com, який поміщає повідомлення до поштової скриньки одержувача.
6. Якщо з будь-яких причин, SMTP сервер mail.ru не може зв'язатися з SMTP сервером gmail.com, тоді повідомлення ставиться в чергу надсилання. SMTP сервери часто використовують програми надсилання повідомлень для повторного надсилання листів, які стоять у черзі. Програма надсилання повідомлень буде періодично пробувати надіслати повідомлення, яке стоїть у черзі. Спроби повторюватимуться через певні проміжки часу (наприклад, 15 хвилин). Після чотирьох годин очікування та спроб відправлення, програма зазвичай надсилає відправнику листа, в якому йдеться про помилки відправки. Після п'яти днів більшість програм відправлення припиняють спроби і повертають листа відправнику як ненаправлений.

Якщо вихідний SMTP сервер (mail.ru) не може поспілкуватися безпосередньо з SMTP сервером gmail.com, він передає повідомлення через один і більше проміжних релей SMTP серверів. У свою чергу сервер ретрансляції (релей) отримує вихідне повідомлення і потім відправляє його до сервера призначення, або перенаправляє на інший сервер ретрансляції. Процес повторюється, доки повідомлення не буде доставлено, або поки не пройде вказаний час та кількість повторів для очікування відповіді сервера.

SMTP сервер розуміє прості текстові команди. Стандартними є:

HELO – початок сесії

EHLO – початок сесії та запит на розширений режим – ESMTP (Якщо сервер не підтримує розширень, то він відповість на EHLO помилкою, у цьому випадку клієнт повинен надіслати команду HELO і не використовувати розширення протоколу.)

MAIL FROM: - адреса відправника

RCPT TO: - адреса одержувача

DATA – передача даних (листа). Поля «Кому», «Від кого» та «Тема» мають займати перші три рядки

RSET – скидання сесії

QUIT – розрив з'єднання

HELP – допомога (додаткова інформація)

VRFY – перевірка адреси його існування

EXPN – розширена адреса

Протягом кількох десятків років користувачі Інтернету використовують електронну пошту, щоб обмінюватися повідомленнями та листами. До початку 90-х років минулого століття електронними повідомленнями користувалися, як правило, співробітники великих організацій. З великою комп'ютеризацією та поширенням всесвітньої павутини, електронні листи міцно увійшли до життя звичайних користувачів.

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

Він не обмежений будь-якими конкретними підсистемами передачі. Його робота потребує лише надійного каналу потоку їх передачі із збереженням порядку.

SMTP використовується в основному для надсилання листів та звернень користувачів на сервер, після чого відбувається надсилання пошти одержувачам. Для того, щоб отримати листи, потрібно щоб поштовий клієнт працював на протоколі IMAP або POP3.

Навіщо використовується?

На сьогоднішній день це типовий поштовий протокол. Його використовують усі поштові програмита сервери.

Віртуальний хостинг сайтів для популярних CMS:

Принцип роботи протоколу.

SMTP - текстовий протокол, його принцип роботи вимагає з'єднання, яким користувач, відправляє електронний лист, пов'язується з його одержувачем використовуючи певний командний рядок. А отримання даних відбувається за допомогою надійного каналу зв'язку. Як правило, цим каналом зв'язку є з'єднання TCP.

Робоча сесія протоколу складається з mail - клієнтом SMTPряду команд та відповідей на них сервера. При робочої сесіїі клієнт і сервер обмінюються необхідними параметрами.

Операція протоколу включає комбінацію, що складається з наступних послідовностей команд і відповідей:

• Команда MAIL FROM - позначає зворотну електронну адресу;
• Команда RCPT TO – визначає одержувача конкретного листа;
• DATA – це команда, яка відповідає за надсилання тексту електронного повідомлення. Це тіло листа, яке включає в себе заголовок і текст листи, розділених між собою порожнім рядком.

Початковим SMTP-клієнтом цілком може бути поштовий клієнт одержувача, або агент пересилання кореспонденції на сервері.

Як працюють інші поштові протоколи

SMTP є лише протоколом доставки кореспонденції до мережі. Він не може по команді взяти електронне повідомлення з віддаленого сервераабо якось керувати e-mail скринькою.

Існують інші протоколи, наприклад IMAP і POP. Їх використання краще при тимчасовому підключенні до мережі або коли ПК включається періодично.

POP.

Post Office Protocol – це простий мережевий протокол, Що включає три різновиди: POP, POP2 і POP3. Розроблені вони для того, щоб доставляти кореспонденцію користувачеві з центрального поштового сервера, видалення пошти з сервера та ідентифікації користувача. Для ідентифікації використовується поєднання логіну та пароля. Варто зазначити, що всі три протоколи не взаємозамінні.

Протокол включає SMTP, що використовується для надсилання вихідної пошти.

Відповідно до POP3, листи, що надходять на певний e-mail, зберігаються на сервері до завантаження їх на ПК під час чергового сеансу. Коли завантаження відбулося, можна прочитати повідомлення, відключившись від мережі. Вважається, що POP3 – найшвидший поштовий протокол.

IMAP.

З допомогою Internet Message Access Protocolстає можливим зберігання повідомлень у директоріях файлів на сервері і здійснювати пошук будь-яких рядків повідомлень прямо там.

Цей протоколпідходить тим користувачам, комп'ютери яких використовують безперервне підключення до Інтернету. Його відмінність від POP у тому, що під час перевірки нових листів завантажуються лише їх заголовки.

4085/2, Сорокін Д. С. Поштові протоколи.Методи боротьби зі спамом

SMTP

SMTP (англ. Simple Mail) Transfer Protocol- простий протокол передачі пошти) - це широко використовуваний мережевий протокол, призначений передачі електронної поштиу мережах TCP/IP.

SMTP-транзакції

SMTP - текстовий протокол, що вимагає з'єднання, за яким відправник повідомлення зв'язується з одержувачем за допомогою видачі командних рядківта отримання необхідних даних через надійний канал, у ролі якого зазвичай виступає TCP-з'єднання (Transmission Control Protocol - протокол керування передачею). SMTP-сесія складається з команд, що посилаються SMTP-клієнтом, та відповідних відповідей SMTP-сервера. Коли сесія відкрита, сервер та клієнт обмінюються її параметрами. Сесія може включати нуль та більше SMTP-операцій (транзакцій).

SMTP команди

SMTP-операція складається з трьох послідовностей команда/відповідь:

MAIL FROM - встановлює зворотний адресу (тобто. Return-Path, 53121.From, mfrom). Це адреса для повернутих листів.

RCPT TO - встановлює одержувача цього повідомлення. Ця команда може бути дана кілька разів по одному на кожного одержувача. Ці адреси є частиною оболонки.

DATA – для надсилання тексту повідомлення. Це самий вміст листа, на противагу його оболонці. Він складається з заголовка повідомлення та тіла повідомлення, розділених порожнім рядком. DATA, по суті, є групою команд, а сервер відповідає двічі: перший раз на саму команду DATA, для повідомлення про

готовність прийняти текст; і вдруге після кінця послідовності даних, щоб прийняти чи відхилити весь лист.

Крім проміжних відповідей для DATA-команди, кожна відповідь сервера може бути позитивною (код відповіді 2хх) або негативною. Останній, своєю чергою, то, можливо постійним (код 5хх) чи тимчасовим (код 4хх). Відмова SMTP-сервера у передачі повідомлення - постійна помилка; у цьому випадку клієнт повинен надіслати повернутий лист. Після скидання - позитивної відповіді, повідомлення швидше за все буде відкинуто. Також сервер може повідомити, що очікуються додаткові дані від клієнта (код 3xx).

Спочатку хост (SMTP-клієнт) може бути як поштовий клієнт кінцевого користувача (функціонально визначається як поштовий агент- MUA), і агент пересилання повідомлень (MTA) на сервері, тобто. сервер діє як клієнт у відповідній сесії для ретрансляції повідомлення. Повністю функціональні сервери підтримують черги повідомлень для повторного надсилання повідомлення у разі помилок.

MUA знає SMTP-сервер для вихідної пошти зі своїх налаштувань. SMTP-сервер, що діє як клієнт, тобто пересилає повідомлення, визначає, до якого сервера підключитися, переглядом ресурсу записів MX (Mail eXchange) DNS для домену кожного одержувача. У випадку, якщо запис MX не знайдено, сумісні MTA (не всі) повертаються до простого запису. Пересилаючі сервери також можуть бути налаштовані на використання Smart host.

SMTP-сервер, що діє як клієнт, встановлює TCP-з'єднання з сервером за розробленим для SMTP порту 25. MUA повинен використовувати порт 587 для підключення до

агенту надання повідомлень (MSA). Основна відмінність між MTA та MSA полягає в тому, що SMTP-автентифікація є обов'язковою лише для останнього.

SMTPS

SMTPS відноситься до методів захисту SMTP транспортному рівні. Він призначений для забезпечення автентифікації сторін, цілісності та конфіденційності даних. SMTPS не є пропрієтарним протоколом або розширенням SMTP, це лише спосіб убезпечити SMTP на транспортному рівні.

Клієнт та сервер використовують звичайний SMTP на рівні програм, але з'єднання захищене SSL або TLS. Це відбувається після встановлення з'єднання перед надсиланням будь-яких поштових даних.

SMTPS використовує 465 портів.

POP3 (англ. Post Office Protocol Version 3 – протокол) поштового відділення, версія 3) - стандартний Інтернет-протокол прикладного рівня, що використовується клієнтами електронної пошти для отримання електронного повідомлення з віддаленого сервера через TCP/IP-з'єднання. POP та IMAP (Internet Message Access Protocol) - найпоширеніші Інтернет-протоколи для отримання пошти. Практично все сучасні клієнтита сервера електронної пошти підтримують обидва стандарти. Протокол POP був розроблений у кількох версіях, нинішнім стандартом є третя версія (POP3). Більшість постачальників послуг електронної пошти (наприклад, Hotmail, Gmail та Yahoo! Mail) також підтримують IMAP та POP3. Попередні версіїпротоколу (POP, POP2) застаріли.

POP підтримує прості вимоги «завантажити та видалити» для доступу до віддалених поштових скриньок. Хоча більшість POP-клієнтів надають можливість залишити пошту на сервері після завантаження, які використовують POP клієнтизазвичай з'єднуються, виймають усі листи, зберігають їх на комп'ютері як нові повідомлення, видаляють їх з сервера, після чого роз'єднуються.

POP3-сервер прослуховує загальновідомий порт 110. Шифрування зв'язку для POP3 запитується після запуску протоколу, за допомогою команди STLS (якщо вона підтримується), або POP3S, яка з'єднується з сервером використовуючи TLS або SSL по TCP-порту 995.

POP3 команди

		Аргументи	Обмеження	Можливі відповіді
			Її підтримка не є	* +OK maildrop has n message
		[ім'я]		* -ERR password suplied for
			обов'язковою
				[ім'я] is incorrect
				* +OK name is a valid mailbox
				* -ERR never heard of mailbox
				* +OK maildrop locked and
			Працює після успішної передачі
				* -ERR invalid password
			імені поштової скриньки
				* -ERR unable to lock

		[повідомлення]	Доступна після успішної	* +OK message deleted
			ідентифікації	* -ERR no such message
		[повідомлення]	Доступна після успішної	* +OK scan listing follows
			ідентифікації	* -ERR no such message
			Доступна після успішної
			ідентифікації
		[повідомлення]	Доступна після успішної	* +OK message follows
			ідентифікації	* -ERR no such message
			Доступна після успішної
			ідентифікації
			Доступна після успішної
			ідентифікації
		[повідомлення]	Доступна після успішної
		[кількість
			ідентифікації	* -ERR no such message

IMAP

Альтернативним протоколом для збирання повідомлень із поштового сервера є IMAP. IMAP (Internet Message Access Protocol) - протокол прикладного рівня для доступу до електронної пошти.

Базується на транспортному протоколі TCP та використовує порт 143.

POP3 має ряд недоліків, і найсерйозніший з них - відсутність можливостей з управління переміщенням та зберіганням повідомлень на сервері. Повідомлення, як правило, завантажуються з поштового сервера все відразу, після чого вони видаляються з сервера, тобто відсутня можливість вибирати повідомлення для отримання.

Для вирішення проблем, пов'язаних з цією особливістю POP3, у Вашингтонському університеті було розроблено новий протокол, що передбачає можливість отримання користувачами електронної пошти з однієї поштової скриньки з різних місць, при цьому повідомлення не розподіляються між точками отримання. Користувачу надається можливість керувати повідомленнями в його поштовій скриньці та додатковими функціями обслуговування поштових скриньок на сервері.

Переваги IMAP

У разі використання POP3 клієнт підключається до сервера лише на проміжок часу, необхідний для завантаження нових повідомлень. При використанні IMAP з'єднання не розривається, доки користувальницький інтерфейсактивний, а повідомлення завантажуються лише на вимогу клієнта. Це дозволяє зменшити час відгуку для користувачів, в ящиках яких є багато повідомлень великого об'єму.

Протокол POP вимагає, щоб поточний покупець був єдиним підключеним до ящику. IMAP дозволяє одночасний доступкількох клієнтів до скриньки та надає клієнту можливість відстежувати зміни, які вносяться іншими клієнтами, підключеними одночасно з ним.

Завдяки системі прапорів, визначеної в IMAP4, клієнт може відстежувати стан повідомлення (прочитано, надіслано відповідь, видалено тощо); дані про прапори зберігаються на сервері.

Клієнти IMAP4 можуть створювати, перейменовувати та видаляти скриньки та переміщувати повідомлення між скриньками. Крім того, можна використовувати розширення IMAP4 Access Control List (ACL) Extension (RFC 4314) для керування правами доступу до скриньок.

Пошук повідомлень відбувається на стороні сервера. IMAP4 має очевидний механізм розширення.

Методи боротьби зі спамом

Сучасна спам-розсилка поширюється в сотнях тисяч екземплярів лише за кілька десятків хвилин. Найчастіше спам йде через заражені шкідливими програмамикомп'ютери - зомбі-мережі. Що можна протиставити цьому тиску? Сучасна індустрія IT-безпеки пропонує безліч рішень і в арсеналі антиспамерів є різні технології. Однак жодна з існуючих технологій не є магічною «срібною кулею» проти спаму. Універсального рішенняпросто не існує. Більшість сучасних продуктів використовують кілька технологій, інакше ефективність продукту не висока.

DNSBL

DNSBL – DNS blacklist або DNS blocklist – списки хостів, що зберігаються з використанням системи архітектури DNS. Зазвичай використовуються для боротьби зі спамом. Поштовий сервер звертається до DNSBL, і перевіряє наявність IP-адреси клієнта, з якого він приймає повідомлення. При позитивній відповіді вважається, що відбувається спроба прийому спам-повідомлення. Сервер відправника повідомляє помилку 5xx (непереборну помилку) і повідомлення не приймається. Поштовий сервер відправника створює «відмовну квитанцію» відправнику про брак пошти.

Існує 2 методи використання цієї технології.

1. Однозначне блокування - відхилення повідомлень, які прийшли з IP адреси, що знаходиться в DNSBL

2. Виважений підхід. При такому підході повідомлення, що надійшло з IP адреси

що знаходиться в DNSBL, не блокується, але цей факт враховується під час класифікації «спамності» листа.

При використанні першого підходу всі листи з IP адрес, що потрапили до DNSBL, однозначно відхиляються. Незалежно від того чи потрапила IP адреса в чорний список заслужено або помилково (що все частіше і частіше зустрічається на практиці). Використання другого підходу відмінно ілюструється Opensource спам-фільтром spamassassin. Коли для класифікації повідомлення застосовується зважений підхід, тобто аналіз за багатьма критеріями. У такому разі знаходження IP адреси відправника в чорному списку не є єдиним і результуючим фактором, який впливає на рішення про класифікацію повідомлення, що в свою чергу означає зниження кількості помилкових спрацьовувань фільтра в тих випадках, коли IP адреса відправника потрапила в чорний список через безглуздий випадок. .

Контроль за масовістю

Технологія передбачає виявлення у потоці пошти масових повідомленьякі абсолютно ідентичні або розрізняються незначно. Для побудови працездатного «масового» аналізатора потрібні величезні потоки пошти, тому цю технологію пропонують великі виробники, що мають значні обсяги пошти, яку вони можуть піддати аналізу.

Плюси: Якщо технологія спрацювала, вона гарантовано визначила масову розсилку.

Мінуси: По-перше, "велике" розсилання може виявитися не спамом, а цілком легітимною поштою (наприклад, Ozon.ru, Subscribe.ru тисячами розсилають практично однакові повідомлення, але це не спам). По-друге, спамери вміють "пробивати" такий захист за допомогою інтелектуальних технологій. Вони використовують ПЗ, що генерує різний контент – текст, графіку тощо. - у кожному спамерському

Сьогодні ми докладно розповімо про протоколи, що найбільш використовуються в мережі інтернет - POP3, IMAP і SMTP. Кожен із зазначених протоколів має певне призначення та функціональні можливості. Спробуймо розібратися.

Протокол POP3 та його порти

Post Office Protocol 3 (POP3) це стандартний протокол пошти, створений для отримання електронних листів з віддаленого сервера на e-mail клієнт.POP3 дозволяє вам зберегти поштове повідомлення на ваш комп'ютер і навіть прочитати його, якщо ви не в мережі. Важливо, що якщо ви вирішили використовувати POP3 для підключення до облікового запису пошти, листи, які вже завантажені на комп'ютер, буде видалено з поштового сервера. Як приклад, якщо ви використовуєте кілька комп'ютерів для підключення до одного поштового облікового запису, то протокол POP3 може бути не найкращим виборомв даному випадку. З іншого боку, оскільки пошта зберігається локально, на ПК конкретного користувачаЦе дозволяє оптимізувати дисковий простір на стороні поштового сервера.

За промовчанням POP3 використовує такі порти:

• Порт 110 – це порт POP3 за промовчанням. Не є безпечним.
• Порт 995 – цей порт слід використовувати, якщо ви хочете встановити безпечне з'єднання.

Протокол IMAP та порти

Internet Message Access Protocol (IMAP) – це поштовий протокол, створений для доступу до пошти з локального поштового клієнта. IMAP та POP3 – найбільш популярні в мережі інтернет протоколи, що використовуються для отримання e-mail.Обидва ці протоколи підтримуються всіма сучасними поштовими клієнтами (MUA - Mail User Agent) та WEB - серверами.

У той час як POP3 дозволяє доступ до пошти тільки з однієї програми, IMAP дозволяє доступ з багатьох клієнтів. З цієї причини IMAP найбільш адаптивний у тих випадках, коли доступ до одного поштового облікового запису необхідний для декількох користувачів.

За замовчуванням, протокол IMAPвикористовує такі порти:

• Порт 143– порт за замовчуванням. Чи не безпечний.
• Порт 993– порт для безпечного з'єднання.

Протокол SMTP та його порти

Simple Mail Transfer Protocol (SMTP) – це стандартний протокол для відправки поштових повідомлень по мережі Інтернет.

Цей протокол описаний у RFC 821 та RFC 822, вперше опублікованих у серпні 1982 року. В рамках даних RFC, формат адреси має бути у форматі ім'я_користувача@доменне_ім'я. Доставка пошти, аналогічна роботі звичайної поштової служби: наприклад, лист на адресу [email protected], буде інтерпретовано так: ivan_ivanov – адреса, а merionet.ru – поштовий індекс. Якщо доменне ім'я одержувача відрізняється від імені домену відправника, то MSA (Mail Submission Agent) надішле лист через Mail Transfer Agent (MTA). Головна ідея MTA у тому, щоб перенаправляти листи до іншої доменну зону, за аналогією, як традиційна пошта надсилає листи до іншого міста або області. MTA також отримує пошту від інших MTA.

Протокол SMTP використовує такі порти.

Протокол SMTP

O У цьому розділі:

O Основні команди протоколу

O Сервери-ретранслятори

O Безпосереднє пересилання

Для доставки пошти в більшості випадків використовується протокол SMTP ( Simple Mail Transfer Protocol).

При його створенні протоколу SMTP розробниками було допущено грубу помилку, яка зіпсувала чимало крові, як системним адміністраторам, так і простим користувачам. Суть її полягає в тому, що протокол SMTP не вимагає аутентифікації користувача перед відправкою повідомлення, і це дозволяє використовувати чужі сервери для розсилки.

Сучасні SMTP-сервера використовують різні захисні механізми, що перешкоджають надсиланню кореспонденції невідомими користувачами. Докладно про це розповідається у розділі «Поштовий сервер зсередини».

У термінології SMTP-протоколу немає таких понять як «клієнт» та «сервер». Натомість говорять про відправника ( sender) та одержувачі ( receiver). Те, що більшість називають "SMTP-сервером", є одночасно і відправником, і одержувачем. Коли клієнт встановлює з ним з'єднання передачі листа, сервер виступає у ролі одержувача, і коли доставляє повідомлення абоненту, стає відправником.

Кожна поштова скринька є SMTP-одержувачем, зв'язавшись з яким безпосередньо, можна передати повідомлення без посередників. Однак такий спосіб не набув великої популярності. Зв'язок з далекими вузлами може бути повільним і ненадійним, тому місію доставки повідомлення зручно покласти на спеціальний сервер, який часто називають сервером вихідної пошти. Якщо зв'язок із сервером вихідної пошти швидкий і надійний, такий підхід цілком виправданий. Навпаки, розсилати листи через далекі, гальмівні та нестабільно працюючі сервери не мають ніякого змилу. У такому разі краще покласти повідомлення безпосередньо в скриньку одержувача. Проте небагато поштових клієнтів підтримують таку можливість.

Наведений нижче приклад демонструє, як за допомогою протоколу SMTP надіслати абоненту повідомлення. Першим кроком необхідно запустити telnet-клієнта та, встановивши з'єднання з вибраним SMTP-сервером (наприклад, mail.aport.ru) по двадцять п'ятому порту, дочекатися видачі запрошення.

Рисунок 009 Підключення до сервера mail.aport.ru

Перші три символи повернутого сервером рядка є кодом завершення операції. Повний списоккодів всіляких помилок міститься в RFC-821, і тут не наводиться.

Для передачі кореспонденції лише TCP-з'єднання мало, і потрібно встановити ще одне, так зване SMTP-соединение. Це досягається поверненням вітання у відповідь серверу із зазначенням імені вузла клієнта (якщо у нього є ім'я) або IP-адреси (якщо у клієнта немає імені).

Далеко не завжди потрібно вказувати свій точнийадресу. Часто достатньо ввести довільну текстовий рядокнаприклад “ABDCEF”

· HELO ppp-15.krintel.ru

Привітання у відповідь здійснюється командою “HELO

”. Сервер, встановивши з'єднання SMTP, повертає код успішного завершення операції (250) і в більшості випадків визначає IP-адресу клієнта або його доменне ім'я.

Наступним кроком потрібно вказати відправника повідомлення. Для цього необхідно скористатися командою «MAIL FROM» із зазначенням власного поштової адресиза бажання ув'язненого в кутові дужки.

Наприклад:

· HELO ppp-15.krintel.ru

· 250 camel.mail.ru Hello ppp-15.krintel.ru

· MAIL FROM: « [email protected]»

Потім вказується одержувач повідомлення, що передається за допомогою команди “RCPT TO”, приклад використання якої показаний нижче:

· HELO ppp-15.krintel.ru

· 250 camel.mail.ru Hello ppp-15.krintel.ru

· MAIL FROM: « [email protected]»

· 250 « [email protected]» is syntactically correct

· RCPT TO: « [email protected]»

При виникненні потреби у надсиланні того самого повідомлення декільком респондентам, достатньо викликати “RCPT TO” ще один (або більше) раз ( максимальна кількістьодержувачів зазвичай обмежено). Якщо комусь із них сервер не візьметься доставити повідомлення, він поверне помилку, ніяк, проте не позначається на інших одержувачах.

Команда “DATA”, викликана без аргументів, переводить сервер очікування отримання тексту листа.

· 354 Enter message, ending with "." on a line by itself

Послідовність завершення введення є звичайну точку, «окаймленную» з двох сторін переносами рядків. Якщо така послідовність зустрінеться у тексті повідомлення, формування листа буде негайно завершено. Поштові клієнти зазвичай розпізнають таку ситуацію і вдаються до перекодування, але при роботі з telnet-клієнтом ця турбота лягати на користувача.

Приклад використання команди “DATA” наведено нижче:

· HELO ppp-15.krintel.ru

· 250 camel.mail.ru Hello ppp-15.krintel.ru

· MAIL FROM: « [email protected]»

· 250 « [email protected]» is syntactically correct

· RCPT TO: « [email protected]»

· 250 « [email protected]» Verified

· Hello, Sailor!

· 250 ОК id=12ZDEd-000Eks-00

Команда “QUIT” завершує сеанс та закриває з'єднання.

· 221 camel.mail.ru closing connection

Вміст отриманого повідомлення (механізм отримання повідомлень на локальний комп'ютеркористувача розглянуто у розділах «Протокол POP» та «Протокол IMAP4») може виглядати, наприклад, таким чином:

· From [email protected] Sun Mar 26 17:38:03 2000

· Received: from ppp-15.krintel.ru ()

· by camel.mail.ru with smtp (Exim 3.02 #107)

· id 12ZDEd-000Eks-00

· Message-Id: « [email protected]»

· Від: [email protected]

· Hello, Sailor!

Нижче буде показано, яким чином зловмисники знаходять та використовують чужі сервери вихідної пошти. Один із способів пошуку загальнодоступних SMTP-серверів полягає в аналізі заголовків кореспонденції, що надходить. Серед вузлів, які залишили свої адреси в полі “Received”, іноді зустрічаються сервери, які не вимагають автентифікації користувача для надсилання листів.

Наприклад, нижче показано заголовок листа, витягнутого автором цієї книги з його власної поштової скриньки:

· From [email protected] Wed Mar 22 16:57:03 2000

· Received: from gate.chiti.uch.net()

· by msk2.mail.ru with esmtp (Exim 3.02 #116)

· id 12Xld1-0008jx-00

· Received: from 13.chiti.uch.net()

· by gate.chiti.uch.net(8.8.8/8.8.8) with SMTP id PAA29678

· Від: "irt" « [email protected] »

Аналіз заголовка дозволяє встановити, що листа було надіслано з адреси 13.chiti.uch.net через сервер вихідної пошти gate.chiti.uch.net. Якщо спробувати встановити з ним з'єднання, результат може виглядати так:

Щоб перевірити можливість пересилання повідомлення, необхідно надіслати серверу запрошення, а потім ідентифікувати відправника та одержувача листа. Наприклад, це може виглядати так:

· HELO kpnc.krintel.ru

· 250 gate.chiti.uch.net Hello kpnc.krintel.ru , pleased to meet you

· MAIL FROM: « [email protected]»

· 250 « [email protected]»… Sender ok

· RCPT TO: « [email protected]»

· 250 « [email protected]»… Recipient ok

Код успішного завершення операції (250) та терміну "Recipient ok" свідчать про те, що сервер погодився на пересилання. Залишається ввести текст листа і можна надсилати листа. Через деякий час (звичайно не перевищує однієї хвилини) повідомлення має прийти за призначенням. А його заголовок може виглядати, наприклад, так:

· From [email protected] Sun Mar 26 17:28:33 2000

· Received: from gate.chiti.uch.net ()

· by camel.mail.ru with esmtp (Exim 3.02 #107)

· id 12ZD5a-000Dhm-00

· Received: from kpnc.krintel.ru (kpnc.krintel.ru)

· by gate.chiti.uch.net (8.8.8/8.8.8) with SMTP id QAA02468

· (Envelope-from [email protected])

· Від: [email protected]

· Message-Id: « [email protected]»

Жирним шрифтом виділено адресу відправника, показуючи, що він не зміг залишитися анонімним. Якщо це виявляється неприйнятно, серед вхідних листів своєї поштової скриньки можна спробувати відшукати такі, в заголовках яких немає жодних відомостей про відправника, за винятком тієї інформації, яку він побажав повідомити сам.

Один з анонімних серверіврозташований (точніше, колись був розташований на момент написання цього розділу) за адресою dore.on.ru. Однак його використання сторонніми особамизаборонено, що й демонструє такий експеримент:

· HELO kpnc.krintel.ru

· MAIL FROM: « [email protected]»

· 250 « [email protected]» Sender Ok

· RCPT TO: « [email protected]»

· 550 Relaying denied for « [email protected]»

Сервер дійсно не робить жодних видимих ​​спроб визначити адресу клієнта, але в той же час пересилати його кореспонденцію за межі сервера навідріз відмовляється. Причому достовірно відомо, що власники цього сервера використовують його для розсилки повідомлень локальним адресам. Звідси випливає існування механізму, що дозволяє відрізнити своїх від чужих. Права «чужих» обмежуються доставкою листів за локальними адресами, а «своїм» дозволяється надсилати повідомлення за межі сервера. Через відсутність у протоколі SMTP засобів автентифікації користувачів відрізнити одних від інших допомагає IP адреса клієнта. Локальні користувачі, що знаходяться в одній підмережі з сервером, вважаються "своїми", і навпаки.

Але якщо сервер не має функції визначення IP адреси клієнтів, йому не залишається нічого іншого, крім як скористатися інформацією, наданою самим відправником, повіривши тому на слово. Тому, існує можливість повідомлення підроблених даних, і, видачі себе за локального користувача, що має право надсилання повідомлень на будь-яку адресу.

Клієнт двічі вказує свою адресу: вітаючи сервер, командою "HELO" він повідомляє свій домен, а в полі "MAIL FROM" наводить власну зворотну адресу. Деякі сервери перевіряють одне з цих значень, а деякі обидва одночасно.

В експерименті, наведеному нижче, відправник повідомляє не свій власний домен, а домен власника сервера, і як зворотна адреса, використовує одну з адрес локальних користувачівсервера (щоб його дізнатися, необхідно отримати з цього сервера хоча б один лист, або спробувати з'ясувати імена зареєстрованих користувачів методом перебору):

· 220 WITHELD FTGate server ready -Fox Mulder

· HELO dore.on.ru

· MAIL FROM: « [email protected]»

· RCPT TO: « [email protected]»

· 250 Recipient Ok

В результаті такої фальсифікації, сервер виявився введений в оману і погодився доставити лист. Очевидно, що справжній відправник повідомлення не може бути встановлений за заголовком, оскільки в ньому знаходиться лише та інформація, яку відправник побажав залишити самостійно.

Для масового розсилання кращого способуі придумати неможливо, але для звичайного листування така методика не підходить. Адже відповідь на лист повернеться на адресу [email protected]!Цього можна уникнути, якщо додати в заголовок поле "Reply-To", що містить справжню адресу відправника (тою, яку він захотів залишити сам). Це може виглядати, наприклад, таким чином:

· 220 WITHELD FTGate server ready -Fox Mulder

· HELO dore.on.ru

· MAIL FROM: « [email protected]»

· 250 « [email protected]» Sender Ok

· RCPT TO: « [email protected]»

· 250 Recipient Ok

· 354 Start mail input; end with "CRLF". "CRLF"

· Reply-To: « [email protected]»

· 250 Ok Message queued

· 221 dore.on.ru Service closing transmission channel

Заголовок такого листа має виглядати приблизно так:

· Received: from relay1.aha.ru(verified)

· by aha.ru (CommuniGate Pro SMTP 3.1b2)

· Received: from warlock.miem.edu.ru (miem-as.ins.ru)

· by relay1.aha.ru(8.9.3/8.9.3/aha-r/0.04B) with ESMTP id UAA07173

· Received: from dore.miem.edu.ru (rtuis.miem.edu.ru)

· by warlock.miem.edu.ru (8.9.3/8.9.3) with ESMTP id UAA00637

· Received: from fox by dore.on.ru(FTGate 2, 1, 2, 1);

· Message-ID: «000301bec6ff$c87f5220$16fe7dc1@fox»

· Від: « [email protected]»

· To: « [email protected]»

· Subject: TEST

· Reply-To: « [email protected]»

При спробі відповісти відправнику, поштовий клієнт одержувача витягне вміст поля "Reply-To" і надішле лист за вказаною в ньому адресою. Саме цим і користуються спамери для досягнення повної анонімностіз одного боку, та можливості отримання відповідей від зацікавлених осіб- з іншого.

Якщо уважно подивитися на заголовок листа, можна знайти кілька рядків “Received”. Їх залишили транзитні сервери, інакше звані Релеями (від англійської relay).

Будь-який поштовий клієнт може надіслати листа безпосередньо. Однак для цього доведеться власноруч вказати в настойках сервера вихідної пошти адресу одержувача.

Наприклад, щоб надіслати лист для [email protected]за допомогою "OutLock Express" доведеться зайти в « Облікові записи» (меню «Сервіс»), вибрати «Властивості» і перейти до закладки «Сервери», задавши сервер «computerra.ru» для вихідної пошти.

Очевидно, це надто втомливо та непрактично. Доки програмне забезпечення не навчиться виконувати таку операцію автоматично, користувачі будуть змушені користуватися колишніми методами.

Робота типового дрібнокорпоративного сервера вихідної пошти виглядає приблизно так: отримавши у своє розпорядження листа, він відразу встановлює з'єднання з поштовою скринькою одержувача, і відправляє послання. При цьому він стикається з тими ж труднощами, що і звичайний клієнт. Тому широко використовується ретрансляція повідомлень. Якщо лист з якихось причин не може бути передано безпосередньо, він передається ретранслятору.

Ретранслятор - такий самий SMTP-сервер, як і всі інші, що обговорюються в цьому розділі. В залежності від настоянок сервера маршрут пересилання листа може змінюватись. Одне повідомлення може надсилатися безпосередньо, а інше – довго «крутитися» на Релеях. Довіра це чудово, але тільки коли не стосується питань безпеки. Хто ризикне довіряти ретрансляторам невідомого походження? Тим більше, подальший маршрут листа кожним із транзитних серверів визначається самостійно, і немає жодних гарантій, що в цей ланцюжок не вклиниться зловмисник.

Але протокол SMTP дозволяє відправнику самостійно задавати маршрут пересилання повідомлення Параметр команди “RCPT TO” може містити як адресу одержувача, а й шлях ретрансляції!

Формат його наступний:

· RCPT TO: "@s1, @ s2, @ s3, @ sn: name @ host"

де s1,s2,s3,sn - імена (або IP адреси) проміжних хвостів, а name@hostпоштову скриньку одержувача. У першу чергу повідомлення передається вузлу s1 - лівому серверу в ланцюжку. Він модифікує параметр команди RCPT TO, "викушуючи" з неї ім'я свого вузла:

· RCPT TO: "@s2, @ s3, @ sn: name @ host"

Потім витягується адреса наступного одержувача - s2. Якщо сервер s1 не береться за доставку кореспонденції до сервера s2, лист повертається назад відправнику з повідомленням про помилку. В іншому випадку процес повторюється, поки повідомлення не опиниться в поштовій скриньці одержувача.

Недоліком такої схеми є те, що деякі SMTP сервери для пересилання на черговий хвіст можуть вдаватися до послуг своїх власних ретрансляторів. Таким чином, гарантується, що лист за успішної доставки відвідає всі задані вузли у вказаному порядку. Але не завжди виконується пряме пересилання між сусідніми хвостами в ланцюжку.

Тому завдання підбору транзитних серверів ускладнюється. Кожен з них повинен бути не тільки захищений від сторонніх вторгнень, але й не користуватися послугами сторонніх ретрансляторів.

На жаль, більшість поштових клієнтів, перевіряючи коректність введення адреси одержувача, вважають таку операцію синтаксично неправильною та відмовляються надсилати листа. Доводиться вкотре запускати telnet та передавати повідомлення вручну.

Дізнатися які саме команди підтримуються конкретним SMTP-сервером можна за допомогою «HELP», а докладніше про призначення кожної з них “HELP command”.

Для отримання детальної інформаціїпро команди протоколу SMTP можна звернутися до RFC-788, RFC-821, RFC-822, RFC-1341, RFC-1342, RFC-1426, RFC-1521, RFC-1806, RFC-1830, RFC-2045, RFC-2046 , RFC-2047, RFC-2048, RFC-2049, RFC-2076

З книги Техніка мережевих атак автора Касперски Кріс

Протокол SMTP O У цьому розділі:O Основні команди протоколуO Сервери-ретрансляториO Безпосереднє пересиланняO Автоматизація поштового розсиланняі спамO Анонімне розсилання листівДля доставки пошти в більшості випадків використовується протокол SMTP (Simple Mail Transfer Protocol).

автора Реймонд Ерік Стівен

5.3.1. Навчальний приклад: SMTP, простий протокол передачі пошти У прикладі 5.7. ілюструється транзакція SMTP (Simple Mail Transfer Protocol - простий протокол передачі пошти), який описаний у специфікації RFC 2821. даному прикладірядки, що починаються з С:, надсилаються поштовим транспортним

З книги Мистецтво програмування для Unix автора Реймонд Ерік Стівен

5.3.1. Навчальний приклад: SMTP, простий протокол передачі пошти У прикладі 5.7. ілюструється транзакція SMTP (Simple Mail Transfer Protocol - простий протокол передачі пошти), який описаний у специфікації RFC 2821. У цьому прикладі рядки, що починаються з C:, відправляються поштовим транспортним

З книги TCP/IP Архітектура, протоколи, реалізація (включаючи IP версії 6 та IP Security) автора Фейт Сідні М

5.24 Протокол ARP Перед тим, як датаграма буде передана з однієї системи локальної мережіна іншу, вона буде обрамлена заголовком та завершальною частиною кадру. Кадр доставляється на мережевий адаптер, фізична адреса якого збігається з фізичною адресоюпризначення з

З книги Програмування мовою Ruby [Ідеологія мови, теорія та практика застосування] автора Фултон Хел

8.9 Протокол RIP Найбільш широко використовуваним протоколом IGP є RIP, запозичений з протоколу маршрутизації мережевої системикомпанії Xerox (Xerox Network System- XNS). Популярність RIP заснована на його простоті та доступності. RIP був спочатку реалізований в TCP/IP операційній

З книги Мережеві засоби Linux автора Сміт Родерік В.

8.17 Протокол BGP В Інтернеті широко використовується протокол граничного шлюзу (Border Gateway Protocol - BGP). Поточною версієюпротоколу є BGP-4. сучасному Інтернетііснує безліч провайдерів, об'єднаних між собою на кшталт мережі міжз'єднань. При русі до точки

З книги автора

14.6 Протокол FTP З протоколом FTP пов'язані такі понятия:? Команди та їх параметри, що пересилаються по керуючому з'єднанню? Числові коди, повернуті у відповідь команду? Формат даних, що пересилаються Нижче розглянуто набір команд FTP. Вони передаються за керуючим

З книги автора

15.17 Протокол NFS Останньою реалізацією NFS є версія 3, хоча продовжують успішно застосовуватися реалізації версії 2. Програма NFS сервера має номер 100003 і, за згодою, NFS захоплює при ініціалізації порт

З книги автора

16.9 Команди SMTP Сценарій з розділу 16.6.1 містив найчастіше використовувані команди SMTP. Повний набіркоманд SMTP представлений у таблиці 16.1. Таблиця 16.1 Команди SMTP Команда Опис HELO Ідентифікує відправника одержувача. MAIL FROM Початок поштової транзакції та вказівка ​​на

З книги автора

16.12.2 Діалог у покращеній версії SMTP Наведений нижче приклад демонструє, як покращений агент пересилання пошти формує транзакцію для надсилання повідомлення MIME у 8-бітному форматі:? Отримувач оголошує про свої покращені можливості, включаючи 8BITMIME.? Команда MAIL FROM має

Програми, що реалізують сервер SMTPу системі Linux sendmail. У складі системи Linux часто постачається найбільш популярний нині поштовий сервер sendmail. Цей пакет надає великі можливостіі багато програм за замовчуванням вважають, що він встановлений в

З книги автора

З книги автора

Спеціальні функціїсервера SMTP У наступних розділах описуються різні характеристикипоштового сервера, які задаються під час його налаштування. Щоб не описувати ці характеристики для кожного сервера, розглянемо їх