os/doc
3
0
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity

- Whitespace-only changes

Browse source 
Approved by: maxim (implicit)
This commit is contained in:
Taras Korenko 2010-07-15 06:22:07 +00:00
parent ff1ce5ca52
commit 2bf950ea53
Notes: svn2git 2020-12-08 03:00:23 +00:00 
svn path=/head/; revision=36012
1 changed files with 40 additions and 42 deletions

82
ru_RU.KOI8-R/articles/relaydelay/article.sgml
View file

@ -23,7 +23,7 @@
<surname>Родес</surname>
<affiliation>
<address><email>trhodes@FreeBSD.org</email></address>
<address><email>trhodes@FreeBSD.org</email></address>
</affiliation>
</author>
@ -35,31 +35,31 @@
<abstract>
<para>Эта статья создана исключительно для описания технологии задержки
передачи сообщений на почтовом сервере &os;. Сервер с технологией
задержки передачи (relaydelay) или попаданием в серый список
(greylisting) снижает уровень спама просто за счёт выдачи
диагностического сообщения <errorname>TEMPFAIL</errorname> на каждое
входящее почтовое сообщение. Смысл этой технологии заключается в том,
что большинство спамеров для выполнения своей работы используют
собственные персональные компьютеры и специализированное программное
обеспечение. Настоящий почтовый сервер должен помещать сообщения в
очередь и пытаться доставить его позже. Таким образом, скорее всего,
спамер перейдёт к следующему хосту вместо того, чтобы попытаться снова
послать электронное послание. Это прекрасная идея; по крайней мере,
до тех пор, пока спамеры не начнут использовать программное
обеспечение, которое будет обеспечивать повтор передачи. Но как именно
это работает? Итак, в процессе приёма сообщения электронной почты
<acronym>ID</acronym> сообщения сохраняется в базе данных, а в качестве
результата возвращается <errorname>TEMPFAIL</errorname> вместе с
электронной почтой. Если сообщение электронной почты посылается
повторно, то <acronym>ID</acronym> сообщения будет сверяться с
<acronym>ID</acronym> сообщений, сохранёнными в базе данных. Если в
базе данных оно существует, то посланию электронной почты разрешается
доставка по назначению. В противном случае <acronym>ID</acronym>
сохраняется, а в качестве результата возвратится
<errorname>TEMPFAIL</errorname>. Этот цикл будет повторяться для
каждого сообщения, поступающего на сервер. По моему личному опыту,
это действительно отсекает 90% спама.</para>
передачи сообщений на почтовом сервере &os;. Сервер с технологией
задержки передачи (relaydelay) или попаданием в серый список
(greylisting) снижает уровень спама просто за счёт выдачи
диагностического сообщения <errorname>TEMPFAIL</errorname> на каждое
входящее почтовое сообщение. Смысл этой технологии заключается в том,
что большинство спамеров для выполнения своей работы используют
собственные персональные компьютеры и специализированное программное
обеспечение. Настоящий почтовый сервер должен помещать сообщения в
очередь и пытаться доставить его позже. Таким образом, скорее всего,
спамер перейдёт к следующему хосту вместо того, чтобы попытаться снова
послать электронное послание. Это прекрасная идея; по крайней мере,
до тех пор, пока спамеры не начнут использовать программное
обеспечение, которое будет обеспечивать повтор передачи. Но как именно
это работает? Итак, в процессе приёма сообщения электронной почты
<acronym>ID</acronym> сообщения сохраняется в базе данных, а в качестве
результата возвращается <errorname>TEMPFAIL</errorname> вместе с
электронной почтой. Если сообщение электронной почты посылается
повторно, то <acronym>ID</acronym> сообщения будет сверяться с
<acronym>ID</acronym> сообщений, сохранёнными в базе данных. Если в
базе данных оно существует, то посланию электронной почты разрешается
доставка по назначению. В противном случае <acronym>ID</acronym>
сохраняется, а в качестве результата возвратится
<errorname>TEMPFAIL</errorname>. Этот цикл будет повторяться для
каждого сообщения, поступающего на сервер. По моему личному опыту,
это действительно отсекает 90% спама.</para>
</abstract>
</articleinfo>
@ -74,18 +74,18 @@
<note>
<para>При этом потребуется, чтобы все порты, которым нужен
<command>perl</command>, были перестроены и переустановлены;
<command>perl</command>, были перестроены и переустановлены;
<filename role="package">ports-mgmt/portupgrade</filename> хорошо для
этого подходит. По крайней мере, он укажет, какие порты были удалены и
какие необходимо переустановить.</para>
этого подходит. По крайней мере, он укажет, какие порты были удалены и
какие необходимо переустановить.</para>
</note>
<para>Теперь что касается сервера базы данных;
<application>MySQL</application> прекрасно подходит для такого типа
работы. Установите <filename
role="package">databases/mysql40-server</filename> вместе с <filename
role="package">databases/p5-DBD-mysql40</filename>. Предыдущий порт должен
подразумевать установку <filename
role="package">databases/p5-DBD-mysql40</filename>. Предыдущий порт
должен подразумевать установку <filename
role="package">databases/p5-DBI-137</filename>, так что один шаг будет
пропущен.</para>
@ -118,8 +118,8 @@
&prompt.root; <userinput>fetch http://lists.puremagic.com/pipermail/greylist-users/attachments/20030904/b8dafed9/relaydelay-0.04.bin</userinput></screen>
<!-- ЗАМЕЧАНИЕ ДЛЯ ТОМА РОДЕСА: РАЗМЕЩАТЬ ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ ЗДЕСЬ
ЯВЛЯЕТСЯ ПЛОХОЙ ИДЕЕЙ НА ТОТ СЛУЧАЙ, ЕСЛИ КАКОЙ-НИБУДЬ МУДАК ЗАМЕНИТ
ЕГО. НАВЕРНОЕ, Я ДОЛЖЕН ЗААРХИВИРОВАТЬ СКРИПТЫ И ОСТАЛЬНУЮ ШНЯГУ. -->
ЯВЛЯЕТСЯ ПЛОХОЙ ИДЕЕЙ НА ТОТ СЛУЧАЙ, ЕСЛИ КАКОЙ-НИБУДЬ МУДАК ЗАМЕНИТ
ЕГО. НАВЕРНОЕ, Я ДОЛЖЕН ЗААРХИВИРОВАТЬ СКРИПТЫ И ОСТАЛЬНУЮ ШНЯГУ. -->
<para>Теперь необходимо распаковать исходный код:</para>
@ -138,7 +138,7 @@
<para>Отредактируйте файлы <filename>relaydelay.conf</filename> и
<filename>db_maintenance.pl</filename>, добавив в них корректное имя
пользователя и пароль для СУБД <application>MySQL</application>. Если
пользователя и пароль для СУБД <application>MySQL</application>. Если
СУБД была построена и установлена так, как описано выше, то в ней
отсутствуют пользователи и пароли. Эта ситуация должна быть исправлена
до перевода системы в промышленную эксплуатацию, что описано в
@ -163,7 +163,7 @@
<note>
<para>Этот файл не будет существовать, если предыдущие команды &man.mv.1;
не были выполнены.</para>
не были выполнены.</para>
</note>
<para>Если всё отработало корректно, то в каталоге <filename
@ -194,9 +194,7 @@ Starting Sendmail::Milter 0.18 engine.</programlisting>
<maketarget>restart</maketarget> должна сделать всё необходимое.</para>
<para>Сгрузите скрипт на языке <command>perl</command>, размещённый по
адресу <ulink
url="http://lists.puremagic.com/pipermail/greylist-users/2003-November/000327.html">
http://lists.puremagic.com/pipermail/greylist-users/2003-November/000327.html</ulink>
адресу <ulink url="http://lists.puremagic.com/pipermail/greylist-users/2003-November/000327.html">http://lists.puremagic.com/pipermail/greylist-users/2003-November/000327.html</ulink>
и сохраните его в каталог <filename
class="directory">relaydelay-0.04</filename>. В следующем примере этот
скрипт обозначается как <filename>addlist.pl</filename>.</para>
@ -257,11 +255,11 @@ Passed Recipient: &lt;local_user@pittgoth.com&gt;
<!-- XXX К какому тексту относится это замечание? -->
<note>
<para>В какой-то момент появлялась ошибка о неполном определении
переменных <command>perl</command> в файле
переменных <command>perl</command> в файле
<filename>/etc/mail/relaydelay.conf</filename>. Если те две переменные
раскомментированы, то конфигурационный файл может быть обработан
нормально. Просто не забудьте убрать их из комментариев до того, как
начать работу с технологией <command>relaydelay</command>.</para>
раскомментированы, то конфигурационный файл может быть обработан
нормально. Просто не забудьте убрать их из комментариев до того, как
начать работу с технологией <command>relaydelay</command>.</para>
</note>
</sect1>
</article>