Электронная почта

Основные понятия

  • MUA
  • MTA
  • SMTP
  • POP/IMAP

MUA

  • Почтовая программа (клиент электронной почты, почтовый клиент, мейл-клиент) — программное обеспечение, устанавливаемое на компьютере пользователя и предназначенное для получения, написания, отправки и хранения сообщений электронной почты одного или нескольких пользователей (в случае, например, нескольких учётных записей на одном компьютере) или нескольких учётных записей одного пользователя.

MTA

  • Почтовый сервер, сервер электронной почты — в системе пересылки электронной почты так обычно называют агент пересылки сообщений (англ. mail transfer agent, MTA). Это  программа, которая передаёт сообщения от одного хоста к другому.

SMTP

  • SMTP (англ. Simple Mail Transfer Protocol) — простой протокол передачи почты) — это широко используемый сетевой протокол, предназначенный для передачи электронной почты в сетях TCP/IP.

POP/IMAP

  • POP (англ. Post Office Protocol Version ) — стандартный Интернет-протокол прикладного уровня, используемый клиентами электронной почты для извлечения электронного сообщения с удаленного сервера по TCP/IP-соединению.
  • IMAP (англ. Internet Message Access Protocol) — протокол прикладного уровня для доступа к электронной почте.Базируется на транспортном протоколе TCP и использует порт 143.

POP

  • POP поддерживает простые требования «загрузи-и-удали» для доступа к удаленным почтовым ящикам. Хотя большая часть POP-клиентов предоставляют возможность оставить почту на сервере после загрузки, использующие POP клиенты обычно соединяются, извлекают все письма, сохраняют их на пользовательском компьютере как новые сообщения, удаляют их с сервера, после чего разъединяются.

IMAP

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

 

                                    Принципиальная схема

Из вне к нам

От MX до POST

От POST к пользователям и от пользователей в мир

Проверка состояния средствами telnet

Состояние POP3

#telnet pop3.telnet.test pop3

telnet: Connected to pop3.telnet.test.
telnet: Escape character is ‘^]’.
server: +OK Dovecot ready.
client: USER MyUsername
server: +OK
client: PASS MyPassword
server: +OK Logged in.
client: LIST
server: +OK 3 messages:
server: 1 114005
server: 2 6663
server: 3 1392651
server: .
client: RETR 1
server: +OK 2287 octets
server:Return-Path: <test3@pop3.telnet.test>
server:X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pop3.telnet.test
server:X-Spam-Level: *
server:.
client: DELE 1
server: +OK Marked to be deleted.
client: quit
server: +OK Logging out, messages deleted.
server: Connection closed by foreign host.

Состояние IMAP
# telnet imap.telnet.test imap

telnet: Connected to imap.telnet.test. 
telnet: Escape character is ‘^]’.
 
server: Connected to localhost.
 
Escape character is ‘^]’.
 
server:* OK Dovecot ready..
 
client: a1 LOGIN MyUsername MyPassword
 
server: a1 OK Logged in
 
client: a2 LIST «» «*»
 
server: * LIST (\HasNoChildren) «.» «Junk»
 
server: * LIST (\HasNoChildren) «.» «Trash»
 
server:* LIST (\HasNoChildren) «.» «Sent»
 
server:* LIST (\HasNoChildren) «.» «Drafts»
 
server:* LIST (\HasNoChildren) «.» «INBOX»
 
server:a2 OK List completed.
 
client: a3 SELECT INBOX
 
server:* OK [CLOSED] Previous mailbox closed.
 
server:* FLAGS (\Answered \Flagged \Deleted \Seen \Draft $MDNSent)
 
server:* OK [PERMANENTFLAGS (\Answered \Flagged \Deleted \Seen \Draft $MDNSent \*)] Flags permitted.
 
server:* 18 EXISTS
 
server:* 0 RECENT
 
server:* OK [UIDVALIDITY 1358519219] UIDs valid
 
server:* OK [UIDNEXT 423] Predicted next UID
 
server:* OK [HIGHESTMODSEQ 960] Highest
 
server:a4 OK [READ-WRITE] Select completed.
 
client: a5 FETCH 1 BODY[]
 
server: * 1 FETCH (BODY[] {405}
 
server: Return-Path: sender@imap.telnet.test
 
server: Received: from imap.telnet.test
 
server: by mx1.imap.telnet.test with ESMTP
 
server: From: sender@imap.telnet.test
 
server: Subject: Test message
 
server: To: recipient@imap.telnet.test
 
server: Message-Id:
 
<20040120203404.CCCC18555.mx1.imap.telnet.test@ient.imap.telnet.test>
 
server:
 
server: This is a test message.
 
server: )
 
server: a5 OK Fetch completed.
 
client: a6 LOGOUT
 
server: * BYE Logging out
 
server: a6 OK Logout completed.

Состояние SMTP

# telnet smtp.telnet.test 25

Connected to smtp.telnet.test.
Escape character is ‘^]’.
server:220 smtp.telnet.test ESMTP Postfix
client:HELO smtp.telnet.test
server:250 smtp.telnet.test
client:MAIL FROM: roman@smtp.telnet.test
server:250 2.1.0 Ok
client:RCPT TO: drake@smtp.telnet.test
server:250 2.1.5 Ok
client:DATA
server:server:354 End data with .
client:Subject: Test 
client:
client:hello
client:.

server:250 2.0.0 Ok: queued as B822840153
client:QUIT
server:221 closing connection

Структура SMTP сессии

Перед тем как заняться фильтрацией спама нужно четко представлять себе как происходит взаимодействие почтовых серверов при передаче писем. Когда один почтовый сервер пытается передать другому письмо, то между ними всегда происходит диалог, который можно наглядно продемонстрировать. Для того, чтобы продемонстрировать этот диалог воспользуемся утилитой telnet на  сервере и попробуем при ее помощи отправить почтовое сообщение на ящик rcvuser@examplereceiver.com от имени snduser@examplesender.com:

# telnet examplereceiver.com 25
Connected to examplereceiver.com.
Escape character is ‘^]’.
220 examplereceiver.com ESMTP
helo examplesender.com
250 examplereceiver ready to serve
mail from:snduser@examplesender.com
250 OK
rcpt to:rcvuser@examplereceiver.com
250 OK
data
354 Go ahead
Hello world!
.
250 OK id=1Lu83v-0002nd-Su

Строки выделенные красным – это команды, которые мы посылаем серверу examplereceiver.com, строки выделеныне зеленым – это ответы сервера examplereceiver.com на наши команды. Давайте подробнее разберем что мы передаем и что получаем в ходе SMTP сессии.

helo examplesender.com“. Мы представляемся серверу получателя, посылая ему в качестве приветствия имя нашего сервера. В ответ сервер examplereceiver.com возвращает нам код 250, который означает, что наша команда принята и можно продолжить дальше.

mail from:snduser@examplesender.com“. Мы сообщаем серверу получателя о том, от кого мы передаем письмо, в данном случае это адрес snduser@examplesender.com, получаем ответ с кодом 250, который означает, что наша команда принята и можно продолжить дальше.

rcpt to:rcvuser@examplereceiver.com“. Мы сообщаем серверу получателя кому адресовано письмо (rcvuser@examplereceiver.com), в ответ снова получаем код 250 и продолжаем дальше.

data“. Этой командой мы сообщаем серверу получателя о том, что мы хотим передать непосредственно текст почтового сообщения. В ответ получаем код 354, который означает “начните передачу тела сообщения”. Письмо заканчивается новой строкой и точкой в началае этой строки, что позволяет серверу получателя узнать где заканчивается наше письмо. На стадии data передаются еще служебные заголовки сообщения, такие как “Subject”, “Date”, Content-Type и т.д., но в данном случае мы передали только текст письма (Hello world!) и завершили передачу точкой в начале новой строки. В ответ получив код 250 и id, который присвоил этому письму сервер examplereceiver.com.

Итак, каждая SMTP сессия, состоит из 4 этапов, их последовательность всегда такая:

1.helo
2. mail from
3. rcpt to
4. data

Названия этих 4 этапов и их последовательность нужно выучить наизусть. Это самые базовые элементы, без них никуда. Если Вам что-то непонятно до данного момента, лучше вернитесь назад, перечитайте еще раз, попробуйте своими руками отправить письмо telnet’ом- но структура SMTP сессии и полное понимание того, что делает каждая команда должно быть у Вас на уровне “разбудите в три часа ночи, спросите – я всё расскажу”. Без этого нет смысла продолжать.

Варианты фильтров

Обратная DNS запись (PTR запись). Считается правилом хорошего тона, когда администратор назначает каждому хосту обратную (PTR) запись. Кроме того, считается таким же хорошим тоном, когда обратная запись запись совпадает с прямой (А) записью.

N.B. При настройке своего почтового сервера потрудитесь, чтобы обратная запись совпадала с прямой. Т.е. если Вы, сделав dig -x (команда для *nix среды), для хоста 256.155.148.244 получили ответ mx.example.com, то и прямая запись mx.example.com должна указывать на 256.155.148.244. В противном случае не удивляйтесь если половина почтовых серверов откажется принимать Ваши письма. PTR запись прописывается у владельца блока IP адресов, скорее всего это Ваш провайдер.

Отсутствие обратной записи у сервера отправителя косвенно указывает на то, что сообщение является спамом. Вы не найдете ни одного сервера gmail, yahoo, mail.ru, yandex.ru и т.д., которые бы не имели обратной записи. И, хотя, теоретически отсутствие обратной записи не может служить критерием для оценки спамности письма, но как показывает практика в 99% случаев обратная запись отсутствует именно у хостов рассылающих спам, поэтому по отсутствию обратной записи у отправителя вполне можно отсеивать спам, а сталкиваясь с оставшимся 1% – заносить их в список исключений. Соответствующие директивы в конфиге postfix: reject_unknown_client.

HELO/EHLO. RFC прямо не обязывает, но рекомендует отправителям начинать SMTP сессию с HELO, в котором указано полноценное доменное имя (fully qualified domain name или сокращенно FQDN, например “smtp.example.com”). И, хотя, нет прямого обязательства это делать, но как и в случае с обратной записью передача в HELO неполноценного доменного имени (например “example”) или передача несуществующего доменного имени де-факто стали косвенными указателями на то, что письмо является спамом. Соответствующие директивы в конфиге postfix: reject_invalid_hostnamereject_non_fqdn_hostnamereject_unknown_hostname.

N.B. При настройке своего почтового сервера потрудитесь, чтобы в HELO Ваш сервер отдавал то, что прописано в PTR записи… Ведь материал выше Вы читали внимательно и PTR запись и А запись у Вас уже совпадают, не так ли? 😉

MAIL FROM. Как мы выяснили, в команде mail from отправитель передаёт получателю имя почтового ящика того, кто отправил письмо. Если в mail from указан почтовый адрес, даже домен которого не существует (напримерuser@sn7y3t5iuhncuhg84dnh4875nf5.com), стоит ли нам принимать такое письмо? Однозначно нет. В ходе SMTP сессии мы можем проверить существование домена и, при его отсутствии, смело отвергнуть сообщение. Кроме того, если окажется что домен существует, мы можем проверить наличие указанного почтового ящика в домене отправителя (практически все MTA это умеют делать, называется “sender verify”). Для этого получатель создает обратную SMTP сессию в сторону отправителя, которая проходит три стадии: helo, mail from, rcpt to и не доходя до data завершается. Представим, что получатель в ходе SMTP сессии получил “mail from:snduser@examplesender.com”. В рамках проверки “sender verify” получатель инициирует SMTP сессию назад в сторону отправителя, где в rcpt to передает “rcpt to:snduser@examplesender.com”. Если он получает ответ 250 (продолжайте), то все ок – отправитель существует. Если же получает “550″ (user unknown), значит отправитель не существует и нам шлют письмо с поддельным адресом отправителя и это письмо можно отвергнуть. Но здесь палка о двух концах: с одной стороны поддельный адрес – это нехорошо, это скорее всего спам. С другой стороны существует немало честных рассылок, правда настроенных непонятно кем, когда рассылка идет с несуществующего адреса. И фильтровать такие рассылки только потому, что они криво настроены тоже не вариант. В общем стоит ли использовать sender verify или нет – мнения разделяются, но я бы рекомендовал все-таки включить sender verify, а сталкиваясь с криво настроенными рассылками – добавлять их в список исключений. Соответствующие директивы в конфиге postfix: reject_non_fqdn_senderreject_unknown_sender_domainreject_unverified_sender.

N.B. Если Вы настраиваете почтовую рассылку, которая не требует ответов, то потрудитесь создать почтовый ящик от имени которого идёт рассылка. Можете не читать его, можете планировщиком (например cron для *nix) удалять из него сообщения каждую ночь, можете что хотите делать с сообщениями в этом ящике, но ящик должен существовать.

RCPT TO. На стадии rcpt to мы получаем адрес того, кому предназначено письмо. Данные из rcpt to мы можем точно также подвергнуть проверке, как и helo, и mail from. Что же мы можем проверить? Мы можем проверить правильно ли указан адрес получателя, является ли он FQDN адресом. Обслуживаем ли мы домен, на ящик которого нам собираются передать письмо. Существует ли в обслуживаемом нами домене ящик, на который собираются передать письмо. Если почтовый ящик получателя не являет собой FQDN имя (например rcvuser@examplereceiver вместо rcvuser@examplereceiver.com), то такое письмо можно отклонить. Если нам передают письмо для пользователя из домена, который мы не обслуживаем (например someuser@somedomain.com), то его мы тоже отклоняем. Тоже самое с несуществующими пользователями в локальных доменах – отклоняем. Соответствующие директивы в конфиге postfix: reject_non_fqdn_recipientreject_unauth_destinationreject_unlisted_recipient.

DNSBL. Суть работы фильтра DNSBL сводится к тому, принимающая сторона может проверить наличие/отсутствие IP адреса отправляющей стороны в черном списке и принять решения что делать с письмом. При этом, обычно, держателем черных списков выступает третья сторона. Соответствующие директивы в конфиге postfix:reject_rbl_clientВнимание! Никогда не используйте эту опцию! Объяснение ниже.

Greylisting. Серый список. Работа грейлистинга основывается на том, что поведение клиентов рассылающих спам отличается от поведения честных почтовых серверов. В ходе SMTP сессии грейлист отдает клиенту ошибку с кодом (4xx), который означает “временная ошибка, попробуйте повторить позже”. Честный почтовый сервер через время обязательно предпримет попытку повторной доставки, поскольку умеет держать очередь почтовых сообщений. Спамеры же в свою очередь очередей не держат, это продиктовано огромными объемами рассылок, для них держать очередь сообщений просто нецелесообразно. В итоге получается так, что честное письмо немного задерживается (обычно 15-30 мин), затем отправитель заносится в белый список как честный отправитель и в последствии сообщения от него приходят без задержек. Спамеры же отсеиваются, не предпринимая попытки повторной доставки. Соответствующие директивы в конфиге postfix: check_policy_service.

Контент-фильтры. До этого мы рассматривали варианты фильтрации, когда фильтры оперируют данными из начальных стадий SMTP сессии. Контент фильтры же в свою очередь анализируют тело письма. Примеры контент-фильтров: ClamAV, Spamassassin, DSPAM.

Как фильтровать правильно?

Распространенной ошибкой является использование DNSBL, что называется “в лоб”. И, хотя, я уже писал об этом ранее, но нелишним будет повторить еще раз: Почему я не использую DNSBL.

Итак, как же фильтровать спам правильно?

Самое важное – полностью отказаться от DNSBL. В конфигурационном файле postfix’а не должно быть ни единого черного списка. Вместо этого лучше включить проверку PTR записи, фильтры HELO/EHLO, проверку отправителя, greylist. Очень много спама из ботнетов оседает на проверке PTR записи, фильтрах HELO/EHLO и грейлисте.

Перед всеми фильтрами стоит добавить собственный белый список. В этот список Вы будете заносить честные сервера, которые неправильно настроены и из-за этого отфильтровываются. Их будет крайне мало, но они будут.

Вот готовые настройки для postfix:

address_verify_sender = <>
smtpd_helo_required = yes
smtpd_recipient_restrictions =
# whitelists:
permit_mynetworks,
check_client_access hash:/usr/local/etc/postfix/access,

# host check’s:
reject_unknown_client,

# HELO check’s:
reject_invalid_hostname,
reject_non_fqdn_hostname,
reject_unknown_hostname,

# MAIL FROM check’s:
reject_non_fqdn_sender,
reject_unknown_sender_domain,
reject_unverified_sender,

# RCPT TO check’s:
reject_non_fqdn_recipient,
reject_unauth_pipelining,
reject_unauth_destination,
reject_unlisted_recipient,
# Greylist:
check_policy_service inet:127.0.0.1:10023,
permit

 

Пояснение к некоторым опциям:
address_verify_sender – задаем пустой From для обратной проверки адреса отправителя. Иначе будет пинг-понг если вторая сторона тоже захочет верифицировать отправителя.
smtpd_helo_required – требуем от клиентов начинать сессию с приветствия.
reject_unknown_client – не принимаем почту от тех, у кого нет PTR записи
reject_unverified_sender – проверка адреса отправителя на существование
check_policy_service – указываем postfix’у порт где слушает greylist демон.

Этих опций Вам будет вполне достаточно, для спокойной работы. Даже без контент фильтра результат будет в десятки раз лучше, чем от DNSBL. А с контент фильтром и подавно.

Отправить ответ

avatar