=?iso-8859-1?q?=5Bmdk-re=5D_SMTP_server_=28Was=3A_=CE=C5=CB=D5=CC=D8=D4?= =?iso-8859-1?q?=D5=D2=CE=D9=C5_=C1=C4=CD=C9=CE=D9=29?=
Yuri Ryazantsev
=?iso-8859-1?q?yuri_=CE=C1_unix=2Eru?=
Ср Сен 26 17:37:00 MSD 2001
On Wed, Sep 26, 2001 at 03:04:06PM +0400, Peter V. Saveliev wrote:
> > Извечный вопрос - как с водой не выплеснуть ребенка. О неправильной
> > настройке мейл-серверов недавно обсуждалось в antispam на ofisp.org. Краткое
> > резюме в моем пересказе и моем понимании: Пользователей, настроившем свой
> > компьютер для према и отправки почты, минуя провайдерский мейл-сервер -
> > стало много. После этого каждый второй считает себя админом (иногда это
> > мнение еще и навязывается должностью). Это ситуация наводит на грустные
> > размышления, но она есть и ее надо принимать как существующий факт. Бороться
> > с неграмотными админами в Инете надо силами провайдеров (которые правда тоже
> > сидят между двух огней - стандартами и деньгами клиентов). И по возможности
> > всем разъяснять как правильно делать.
>
> Не могли бы Вы провести небольшой ликбез на эту тему? Дело в том, что мне, возможно,
> придется в этой каше поучаствовать, как бы не лопухнуться по незнанию... Обычаев, что
> ли, ибо документация по настройке sendmail не объясняет, что такое спам.
Вообще-то я не считаю себя гуру в этом вопросе, лучше все что я вам тут
наплету проверить по документациям. Рассматриваю только SMTP сервер, т.к.
все остальное почтовое - это ваши внутренние дела. И второе - я не дам вам
рекомендаций по конкретной настройке того или иного SMTP сервера, т.к. это
всегда можно посмотреть в документации, а изменения происходят очень часто.
Правильная насторйка SMTP сервера в моем понимании:
Самое главное - следование стандартам, принятым в сети (RFC и draft я тоже
туда отношу). А значит, если у вас возникли сомнения, по какому-нибудь
вопросу, то идем на http://www.imc.org/ и читаем.
Правильная настройка - она не только техническая, но и организационная. А
значит надо также прочитать и стараться следовать
http://www.ofisp.org/documents/ofisp-005.html и http://www.mail-abuse.org/
Ну а дальше техническая часть:
Определяемся какая или какие машины у нас принимают почту и правильно
настраиваем DNS. Это подразумевает, что по каждому домену или хосту,
принимающему почту, должна существовать MX запись, которая указывает на
существующий хост (для которого есть действующая A запись) и IP адрес на
который все это показывет имеет PTR запись, указывающую на на хост с тем же
IP адресом. Если это я слишком закрутил, то поясню на примере:
Домен example.ru
Хочу, чтобы всю почту принимала машина mail.example.ru
DNS должен содержать следующие записи:
$ORIGIN example.ru.
@ IN MX 10 mail.example.ru.
mail IN A 192.168.10.1
gate IN A 192.168.10.1
$ORIGIN 10.168.192.in-addrp.arpa.
1 IN PTR gate.example.ru.
Далее собственно SMTP сервер. Все настройки его могут выбиратся по
соображениям безопасности и реальности (дело вкуса; главное отдавать себе
отчет в том, что ты делаешь и нести ответственность за последствия). Что и
когда настраивать лучше рассматривать на примере SMTP минимальной сессии:
Машина 10.0.0.1 хочет отправить вам письмо (в начале строки > - то что к
вам пришло, < то что вы выдаете):
1 > connect to mail.example.ru на порт 25
2 < 220 mail.example.ru ESMTP
3 > HELO qqq.yahoo.com
4 < 250 mail.exapmle.ru Hello qqq.yahoo.com [10.0.0.1]
5 > MAIL FROM: badmen на yahoo.com
6 < 250 <badmen на yahoo.com> OK
7 > RCPT TO: root на example.ru
8 < 250 <root на example.ru> OK
9 > DATA
10 < 354 Enter message, ending with "." on a line by itself
Далее передается само письмо
11 > .
12 < 250 OK
13 > QUIT
14 < 221 mail.example.ru closing connection
Далее по этапам:
1. Это проблема firewall - пропускать или нет. Я это часто использую для
хостов зараженных вирусами и слишком много коннектов открывающих на меня.
Также на этом этапе можно проверить и решить пускать или не пускать машину,
по следующим критериям:
loadavg - большая загрузка системы. Довольно частая диагностика на mail.ru
max connect - количество одновременных коннектов с одного хоста
2. Что выдавать в этой строке решает сам администратор. У меня правило - чем
меньше информации, тем лучше. Обязательным является - 220 (код возврата) и
протокол ESMTP (если ваша система поддерживает ESMTP протокол) или SMTP. Во
всех конфигах есть возможность изменять эту строку. Лучше не показывать имя
программы и версию, которые вы используете, т.к. это дополнительная
информация для взлома через известные дырки, которые вы не успели залатать.
3. Наименее информативная строка во всем протоколе на сегодняшний день, но
после нее есть возможность принять массу решений. Информативность ее низка
т.к. qqq.yahoo.com может быть любой строкой и действительности не
соответствовать. Во многих MTA есть возможность проверять разные
соответствия, но по реальности эти проверки ничего не стоят. Единственное,
что можно проверить, это по IP адресу открытого сокета, что этот хост не
находится в блоклистах (местных и общих). По остальным проверкам:
- единственное, что вы имеете - это IP адрес открытого соединения.
По ДНС проверять бессмысленно, т.к. не все его настраивают. По
обратному соединению тоже, т.к. машина может (а чаще так и есть)
стоять за firewall и не принимать входные соединения вообще (часто
провайдеров - входные и выходные мейл-сервера могут быть разными).
4. Если это не проштрафившийся по отношению к вам хост, то вы принимаете его
соединение. О чем вы ему и сообщаете 250 кодом возврата.
5-8. Наиболее интересный момент настройки. Вы должны определится, кто
является своим (внутренним) клиентом, а кто чужим (внешним). Так вот, ваша
почтовая машина должна принимать почту либо для своего клиента, либо от
своего. Почта от чужого к чужому называется relay и должна reject'иться. В
противном случае вы попадете в RBL (relay blocking list) и вас будут
отбрасывать на 4 этапе (см. выше). При этом необходимо учитывать, что адреса
могут быть простыми (root на example.com), так и более сложными, например:
another%yahoo.com на example.ru. Последний представляет из себя адрес с
редиректом: отправить письмо на another на yahoo.com из домена example.ru. В
SOHO (small office, home office) системах такие адреса можно спокойно не
принимать.
Итак на этих этапах вы принимаете решение принимать почту или нет (о чем
сообщаете в кодах возврата) на основании следующего:
- синтаксическая проверка адресов получателя и отправителя;
- проверка существования доменов получателя и отправителя;
- отсутствие relay;
- отсутствие получателя и отправителя в блок-листах;
- проверка существования получателя и отправителя обратным SMTP
соединением. Эта проверка имеет обратную сторону медали для редко
достижимых хостов. Вы от своего клиента не принимаете почту из-за
недоступности мейл-сервера получателя. Зато не болтается в очереди
лишнего :-)
- проверка того, что тот кто является своим имеет возможность
получать/отправлять почту (например квоты). Если у пользователя
переполнен почтовый ящик, то я ему и отправлять не разрешаю, т.к.
непонятно куда потом деть письмо об ошибке.
- можно добавить еще по вкусу. Но необходимо помнить, что любые преграды
еще и уменьшают производительность системы. Иногда нужна золотая
середина.
9-11. Далее вы приняли письмо и положили его в очередь на обработку. Здесь
проверки наиболее простые:
- соответствие письма формату RFC2822;
- отсутствие вирусов и других недопустимых вложений;
- другие фильтры по содержимому (допустим вы не хотите, чтобы ваш
сын получал письма со словами drug, sex, adult ...)
Что делать с письмом на этом этапе: по протоколу лучше всего в любом случае
сказать 250 OK, т.к. его та машина заново будет опять вам посылать. А вы его
в /dev/null, а автору некий возврат, зависящий от вашей фантазии.
Дополнение:
- команды VRFY и EXPN лучше запретить.
- ТРЕБОВАНИЕ RFC - в каждом почтовом домене должен быть ЧЕЛОВЕК (а
не автомат), получающий почту по адресу postmaster@
- желательно, чтобы существовали адреса:
abuse
admin
answer
hostmaster
info
mailer-daemon
noc
operator
security
остальное (типа webmaster, manager, ...) - по вкусу
Ну вот вкратце вроде как и все. Если что сумбурно - прошу прощения, писал в
рабочее время в перерывах. Если есть вопросы или замечания - считаю
обсуждение полезно для всех.
with best wishes,
Yuri.
Подробная информация о списке рассылки community