Info
Content

Общее

MUA - Mail User Agent (thunderbird, outlook, the bat, etc)

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

Следующие заголовки считаются обязательными:

  • From - адрес и, возможно, полное имя отправителя
  • To - адрес и, возможно, полное имя того, кому адресовано письмо (адресатов может быть несколько)
  • Subject - тема письма
  • Date - локальные дата и время отправления письма

Другими часто используемыми заголовками являются:

  • Сс (carbon copy) - кому отправить копию письма (адресатов может быть несколько), при этом и основному адресату, и дополнительным, будет об этом известно
  • Received - путь прохождения письма
  • Content-Type - информация о том, каким образом письмо должно быть отображено

Также есть Bcc - скрытая копия (blind carbon copy), получатели из to и cc не увидят получателей из bcc, а получатели из bcc увидят получателей из to и cc, но не увидят других получателей из bcc

Имена заголовков могут содержать только 7-битные ASCII-символы. Значения заголовков не ограничены символами ASCII, но при наличии не ASCII-символов они должны использовать MIME-кодирование в форме «=?charset?encoding?encoded text?=»

Есть разные типы кодирования для заголовков:

  • 7bit - default
  • quoted-printable - используется для us-ascii, но также содержит и другие символы
  • base64 - для бинарных данных

Кодировка и тип кодирования тела письма указывается в заголовках Content-Type и Content-Transfer-Encoding
Используются те же кодировки

Тело сообщения может состоять из нескольких частей, каждая часть имеет собственные заголовки кодирования (разные части используются для передачи вложений):

Message-ID: <436F2097.5060703@mail.domain1.com>
Date: Mon, 07 Nov 2005 12:38:31 +0300
From: User 1 <user1@domain1.com>
User-Agent: Mozilla Thunderbird 0.6 (X11/20040511)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To:  user2@domain2.com
Subject: =?KOI8-R?Q?=F4=C5=D3=D4?=
Content-Type: multipart/mixed;
 boundary="------------070102080309020306010600"

This is a multi-part message in MIME format.
--------------070102080309020306010600
Content-Type: text/plain; charset=KOI8-R; format=flowed
Content-Transfer-Encoding: 8bit

Привет!


--------------070102080309020306010600
Content-Type: text/plain;
 name="file.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="file.txt"

Text file content

--------------070102080309020306010600--

MSA - Mail Submission Agent, принимает письмо от MUA проверяет письмо на соответствие стандартам, проверяет не спам ли это, проводит авторизацию и передает его в MTA

MTA - Mail Transfer Agent - занимается доставкой письма адресату

На практике отдельных реализаций MSA не существует, а большинство реализаций MTA способны также выполнять функции MSA. Более того, для MSA практически никогда не конфигурируется порт 678, а все почтовые сообщения от MUA принимаются непосредственно на порт 25

MTA вообще не берет на себя ответственность за пересылку письма, а просто отдает ее вышестоящему MTA, который для него является релеем (relay - MTA, через который производится пересылка). Релей может определить список сетей/хостов и/или список логинов/паролей, которым разрешено пересылать через него свои почтовые сообщения

Релеи бывают открытые и закрытые, открытый это тот у которого не ограничен список отправителей, и как правило открытыми релеями начинают пользоваться спамеры, потом этот релей попадает в ЧС и другие релеи начинают его игнорировать

МТА, принимающий на себя ответственность за пересылку, сначала проверяет, обслуживает ли он домен адресата. В случае отрицательного решения MTA предпринимает попытку найти другой MTA, обслуживающий этот домен. Для этого он с помощью DNS-запроса получает список MX-записей домена, каждая из которых содержит приоритет в виде целого числа - чем оно меньше, тем MTA «главнее». В первую очередь предпринимается попытка отправить почтовое сообщение на главный MTA домена, а в случае его недоступности - по очереди на следующие за ним по приоритету (резервные) до тех пор, пока сообщение не будет отправлено. Резервные MTA могут передать сообщения на главный после восстановления его работоспособности, а могут выполнить доставку сообщения в почтовый ящик адресата самостоятельно

Протокол SMTP не позволяет однозначно идентифицировать отправителя сообщения, однако существует возможность потребовать от отправителя авторизоваться - для этого служит расширение AUTH. Для реализации этого расширения MTA используют механизм SASL, который позволяет использовать различные способы передачи и хранения логина и пароля, в том числе и те, которые используют не сам пароль, а его хэш

Существует также возможность шифровать SMTP-трафик с помощью технологий TLS/SSL (Transport Security Layer / Secure Socket Layer), для чего могут использоваться 2 механизма:

  • Устаревший протокол SMTPS - фактически это тот же самый SMTP, но шифруется весь трафик, начиная от начального приветствия MTA, при этом используется порт 465
  • Расширение STARTTLS - при этом используется порт 25 - тот же самый, что и для обмена незашифрованными сообщениями

Кроме использования протокола SMTP существует более простой способ отправить почтовое сообщение - это так называемая локальная отправка, поддерживаемая почти всеми MTA. Общепринятым способом локальной отправки является использование pipe-интерфейса программы sendmail, существуют MUA, которые поддерживают этот способ отправки (KMail, mutt, pine), а mailx вообще никаких других способов, кроме этого, не поддерживает. Простейший shell-скрипт, выполняющий локальную отправку, выглядит так:

#!/bin/sh

/usr/sbin/sendmail -t << EOF
From: user1@domain1.com
To: user2@domain2.com
Subject: Test Message
Hello!
EOF 

Существует множество разных MTA, например:

  • sendmail - самый старый, имеет гибкую настройку, но он большой, монолитный, и в нем часто находят уязвимости, поэтому он не рекомендуется
  • qmail - защищенная, модульная альтернатива сендмейлу, но из-за своей лицензии не получила распрастранения
  • postfix - как qmail, но с более легкой лицензией (by default in linux)
  • exim - монолитный подобно sendmail'у, но безопасный, функциональный и логично конфигурируется

Кол-во MTA через которые пройдет письмо пока не попадет в ящик получателя - неограничено
Но обычно их два, а то и один

Задача MTA - после получения письма для своего домена - положить письмо в хранилище, откуда его прочитает получатель через свой MUA
Доставкой письма в это хранилище занимается MDA

MDA - Mail Delivery Agent

Когда-то в процедуре доставки ничего сложного не было. Использовалась исключительно push-технология: MTA посредством собственного локального MDA доставлял почтовые сообщения куда-нибудь в /var/mail или /var/spool/mail, а MUA, появившиеся в те времена (mailx, mutt, pine), читали сообщения непосредственно оттуда - при этом они обязаны были находиться на одной машине с MTA или монтировать свои почтовые ящики, например, по NFS. Затем более популярными стали pop-технологии: /var/mail и /var/spool/mail выродились в специализированные серверные хранилища почты с собственными специализированными средствами доставки почты, появились сервисы, предоставляющие доступ к этим хранилищам по протоколам POP3 и IMAP по запросу самого MUA - причем новые MUA (Mozilla, Outlook, The Bat!) по другому себе жизнь уже не мыслят и о /var/mail и /var/spool/mail ничего не знают

Есть два стандартных формата хранения почты:

  • mbox
  • maildir

Стандартность состоит в том что таким образом может работать много разных MDA

Есть несколько нестандартных (например):

  • cyrus
  • dbmail (mysql, postgresql)

mbox - это целое семейство не очень совместимых форматов, которые используются как на серверах так и локально на MUA
Все эти форматы объединяет то, что все сообщения хранятся в одном файле, начинаются с поля From и отделены друг от друга пустой строкой. В процессе доставки новые сообщения дописываются в конец mbox-файла

Из-за таких недостатков как:

  • сложность и ненадежность ПО с возможностью добавления новых писем и редактирования существующих
  • блокировка файла при параллельной доставке

Появился формат maildir

maildir - это каталог с тремя подкаталогами (tmp, new, cur)
Работает так:

  • письмо кладется в файл в папке tmp, имя файла генерируется на основе разных параметров так чтобы оно было уникальным
  • после того как письмо полностью записано в файл, делается хардлинк в папке new и удаляется хардлинк из tmp, это нужно чтобы в папке new в любой момент времени не было частично записаного файла

Таким же образом оно перемещается из new в cur после прочтения
Это может сделать MUA или MDA (предоставляющий доступ к Maildir по протоколу POP3 или IMAP)

maildir++ - усовершенствованная версия с поддержкой вложенных каталогов IMAP и квот

Все MTA содержат в себе локальные MDA для доставки в mbox/maildir, но обычно используется внешний MDA
Внешние предоставляют доп функционал (переложить в другой ящик, переслать на другой адрес, передать какой-либо программе через pipe для обработки, итд)
Самые распрастраненные:

  • procmail
  • maildrop

pipe это накладно по ресурсам, поэтому существует протокол LMTP (Local Mail Transfer Protocol), он позволяет использовать tcp/ip или unix-сокеты

Кроме фильтрующих MDA общего назначения в процессе доставки сообщения в серверное хранилище также могут использоваться специализированные контент-фильтры. Такие фильтры могут выполнять функцию отсеивания спама и вирусов, в этом качестве часто используются SpamAssassin и SpamOracle в связке с популярными антивирусами. Они могут использовать как pipe-интерфейс, так и интерфейс LMTP. Последний вариант, как правило, является более производительным, но затрудняет использование контент-фильтра в MDA общего назначения - остается использовать MDA из комплекта MTA

Самые популярные MDA предоставляющие доступ к maildir/mbox по pop3/imap:

  • uw imap - самый простой, для логина использует pam
  • courier imap - часть проекта courier (в котором очень много всего)
  • dovecot - относится к uwimap/courierimap как postfix к sendmail
  • cyrus imap - наиболее продвинутый

О протоколах:

  • POP3 подразумевает что пользователи забирают почту с сервера и работают с ней локально
  • IMAP же оставляет письма на сервере после прочтения (просто делает пометку что письмо прочитано), это позволяет работать с одним ящиком с разных устройств одновременно

Также IMAP позволяет: работать с одним каталогом из под разных учеток, искать по каталогу силами сервера, загружать письма партиями а не все сразу
Оба они поддерживают шифрование как и SMTP

No Comments
Back to top