[Карта]
[Начало]
[Sendmail-ссылки]
[Синтаксис]
[Типовые задачки]
[Задачки по маршрутизации]
[Задачки по маcкарадингу]
[SendmailACL]
[Spamooborona]
[VadeRetro]
[Regex]
[Тонкости]
[Недок.особен.]
[Несущ.юзеры]
[Прячемся!]
[RFC1893.Цитаты]
[ТП.Эмоции]
[Антиспам&Разум]
[Экзерсисы]
Sendmail. Тонкости.
1. Если соединение с smtp портом идет слишком долго
1.A. Различие в выходных данных tcpdump и iptables
2. Если sendmail слушает только локальный интерфейс 127.0.0.1
3. Немного о классе $=w (sendmail.cw, local-host-names, hosts)
4. Как изменить адрес отправителя при отправке сообщения с linux-хоста, как добавить attachment из командной строки, как отправить html-файл из командной строки.
5. Взаимодействие sendmail и DNS (как отключить обязательное обращение sendmail к DNS за MX-записью, sendmail и nsswitch.conf).
6. В чем различие между /etc/mail/relay-domains и /etc/mail/access?
7. Почему макрос $&{client_addr} иногда бывает равен 0 ?
8. Почему не стоит полагаться на статистику, выдаваемую по команде mailstat
9. Как создать системного пользователя с точкой.
10. Увеличиваем уровень логирования.
11. Сообщение в maillog: Local configurqation error: Mail loops back to me.
12. Немного про aliases.
13. Если почтовый клиент мудрит с почтовым доменом, заданном в виде ip.
14. Как с/п telnet отправить "слепую" копию письма.
15. Почему не следует в комментариях sendmail.mc упоминать MAILER-DAEMON.
16. Почему невозможно проверить заголовок Bcc.
17. Как рассчитать значение Daemon Children?
18. Что означает одновременная запись в лог "ruleset=check_something" и "stat=Sent"
19. Почему иногда discard в /etc/mail/access не срабатывает?
20. Почему иногда под одним процессом пишутся разные сообщения?
21. Немного про опцию define(`confTRY_NULL_MX_LIST',`true')
22. Немного про "правильный" формат msgid & RFC
23.Как увеличить число демонов на одном сервере(как снять ограничение на кол-во DAEMON_OPTIONS)
24.Что означает ошибка "macro/class names too long". А то, что количество макросов ограничено.
25. Sendmail - MS Exchange и CRLFCRLF.
26. Откуда sendmail берет информацию о node name and subdomain name.
27. Как запустить 2 sendmailа на разных портах и с разными конфигами?
28. Встроенные анти-DOS средства sendmail.
29. Как из op.me получить op.txt
30. Почему нельзя сразу отвергнуть письмо, если его размер превышает допустимый
31. Про Delivery Mode & OpMod
32. Почему не всегда можно воспользоваться сохранением заголовка в макросе.
33. Непонятки с пустым макросом $&{To} при заполненном заголовке To:
34. Извещение пользователю, если письмо от него было воспринято удаленной системой как спам.
35. Почему FEATURE(dnsbl, ... ) не блокирует почту с IP-адресов, попавших в данный blacklist?
36. Почему access файл не блокирует почту для локальных адресов
37. Mail.ru говорит "dsn=5.1.1, stat=User unknown", в то время как ящик существует.
38. Как правильно задавать вопросы на sendmail-конфе.
39. Потеря писем.
40. Как определить несколько alias-файлов.
41. Зачем очищать макрос.
42. Строгое соответствие доменного имени в access. FEATURE(relay_hosts_only).
43. Сетки популярных бесплатных почтовых систем для внесения в белые списки.
44. Нужен или нет NDR? Имеем ли мы право отказываться от формирования или получения NDR?
45. Как откладывать отвергнутую почту в отдельный файл?
46. Как из sendmail.cf получить sendmail.mc.
47.
48.
49.
50.
51.
1.
(25.01.2007. В декабре 2006 г. relays.ordb.org прекратил свое существование, обновите конфиги (если вы его использовали). В противном случае вам обеспечена 30-секундная задержка при отправке почты(если не использете тэг CONNECT для локальной сети ),
а также при преме почты от других почтовиков).
31.03.2008. Как оказалось, масса админов так и не удосужилась до сих пор убрать этот "черный список" из своих конфигов,
поэтому и наступила на такие, любезно подкинутые, грабли.
Еще ссылка. [1]
19.06.2008. А вот и еще новость. Известный список блокировки динамических хостов dynablock.wirehub.net стал выдавать положительные ответы на DNS-запросы с любыми префиксами, что может эффективно заблокировать прием всей почты релеями, которые до сих пор не удалили этот DNSBL из своих конфигурационных файлов
Источник - http://www.opennet.ru/opennews/art.shtml?num=16538
10.10.2008. Еще один dnsbl приказал долго жить. "DSBL is GONE and highly unlikely to return. Please remove it from your mail server configuration."
Информация от 09/29/2008.
В мае 2008 на главное странице было опубликовано такое сообщение:
Database lost - list empty
Thu, 06/05/2008 - 21:34 — riel
It looks like the database can not be recovered from the old hard disks - both disks in the RAID1 array are totally broken.
Если соединение с smtp портом идет слишком долго, то причиной этому могут быть несколько факторов.
"Задумчивость" почтовика может появиться после подключения FEATURE(dnsbl).
Дело в том, что в случае падения сети и недоступности Интернета ни одно письмо не сможет быть вами отправлено с локальных ip-адресов
(в том числе и с самого почтовика), потому что dnsbl-сервера будут недоступны.
Вообще говоря, проверка локальных ip-адресов на принадлежность dnsbl-базам излишня, поэтому,
вооружившись следующим из /usr/src/sendmail/cf/README:
'' ...Notice: to avoid checking your own local domains against those blacklists, use the access_db feature and add:
Connect:10.1 OK
Connect:127.0.0.1 RELAY
...''
редактируем файл /etc/mail/access:
CONNECT:127.0.0.1 OK
CONNECT:i.k.l OK
CONNECT:x.y.z.w OK
CONNECT:a.b.c.d OK
Затем makemap hash access < access
Также можно настроить FEATURE(`delay_checks') (см ..sendmailXXX/cf/README)
Еще 3 возможные причины задержки при установлении smtp-соединения - неправильно настроенный Firewall,
некорректный /etc/resolv.conf (перечисленные в нем DNS-сервера должны быть доступны, и вашему почтовику должно быть разрешено делать запросы) и большой timeout параметра IDENT
(если нет особой необходимости, то рекомендуется define(`confTO_IDENT',`0s'))
(man identd, RFC1413, http://docs.netive.ru/Oreilly/ror/fire/ch21_09.htm,
http://icmp.ru/man/howto/security/Security-HOWTO53.html)
cat /etc/services
...
ident 113/tcp auth # Authentication Service
auth 113/udp # Authentication Service
...
)
Можно также включить в iptables (ipchains, etc) полное логирование всех исходящих пакетов и таким образом обнаружить, куда (ip, port) так долго стучится почтовик.
17.02.2009. Неработающие или временно недоступные dnsbl-базы могут повлечь большой timeout и, как следствие, восприятие данного соединения
как "нулевого" ( host.domain.ru [k.n.m.l.] did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA)
и обрыв соединения.
Пример 1. Здесь имели место 2 неработающие dnsbl-базы. Как уже было сказано выше, timeout обращения к каждой из баз
~ 30 секунд. Две неработающие базы вызвали timeout~1минута .
29.05.09. Пример 2. Здесь имело место пропадание связи, количество задействованных
dnsbl неизвестно, но, судя по сообщению о нулевой ошибке, - не меньше двух.
confTO_CONNECT
Timeout.connect [0]
The timeout waiting for an initial
connect() to complete. This can only
shorten connection timeouts; the kernel
silently enforces an absolute maximum
(which varies depending on the system).
confTO_ICONNECT
Timeout.iconnect [undefined]
Like Timeout.connect, but
applies only to the very first attempt
to connect to a host in a message.
This allows a single very fast pass
followed by more careful delivery
attempts in the future.
confTO_ACONNECT
Timeout.aconnect [0]
The overall timeout waiting for
all connection for a single delivery
attempt to succeed. If 0, no overall
limit is applied.
1.A.
Интересное наблюдение:в случае блокировки с помощью iptables определенных портов, tcpdump для обнаружения направления запросов сервера может оказаться бесполезным, потому что он не покажет обращения к закрытым портам в отличие от iptables с включенным логированием.
Например, у меня iptables по умолчанию все запрещает, а потом открывает определенные порты. В конец скрипта, запускающего iptables, я помещаю такие строки:
iptables -A INPUT -j LOG --log-level 6 --log-prefix "ACC_IN: "
iptables -A OUTPUT -j LOG --log-level 6 --log-prefix "ACC_OUT: "
Теперь логируются все отвергнутые запросы. По ним можно обнаружить запросы проблемному порту/хосту.
Как это обнаружилось.
После подключения iptables (разрешены толкь 110 и 25 порты) вдруг появилась 30-ти секундная задержка при приеме почты.
У меня по умолчанию iptables не принимает/не выпускает пакеты с 113/к 113 порту. Поэтому tcpdump запросы к 113 порту клиента не показал.
20:29:51.371548 1.2.3.150.1676 > 1.2.3.152.110: S [tcp sum ok] 3039607354:3039607354(0) win 8192 (DF) (ttl 128, id 33423, len 44)
20:29:51.371736 1.2.3.152.110 > 1.2.3.150.1676: S [tcp sum ok] 1816125651:1816125651(0) ack 3039607355 win 5840 (DF) (ttl 64, id 0, len 44)
20:29:51.371575 1.2.3.150.1676 > 1.2.3.152.110: . [tcp sum ok] ack 1 win 8760 (DF) (ttl 128, id 33679, len 40)
Вот задержка в 30 с:
20:30:21.376684 1.2.3.152.110 > 1.2.3.150.1676: P 1:47(46) ack 1 win 5840 (DF) (ttl 64, id 3813, len 86)
20:30:21.377208 1.2.3.150.1676 > 1.2.3.152.110: P [tcp sum ok] 1:14(13) ack 47 win 8714 (DF) (ttl 128, id 33935, len 53)
20:30:21.377317 1.2.3.152.110 > 1.2.3.150.1676: . [tcp sum ok] ack 14 win 5840 (DF) (ttl 64, id 3815, len 40)
И т.д.
А вот, что показал iptables:
Jun 9 20:38:33 host kernel: ACC_IN: IN=eth0 OUT= MAC= SRC=1.2.3.150 DST=1.2.3.152 LEN=44 TOS=0x00 PREC=0x00 TTL=128 ID=38543 DF PROTO=TCP SPT=1678 DPT=110 WINDOW=8192 RES=0x00 SYN URGP=0
Jun 9 20:38:33 host kernel: ACC_OUT: IN= OUT=eth0 SRC=1.2.3.152 DST=1.2.3.150 LEN=44 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=TCP SPT=110 DPT=1678 WINDOW=5840 RES=0x00 ACK SYN URGP=0
Jun 9 20:38:33 host kernel: ACC_IN: IN=eth0 OUT= MAC= SRC=1.2.3.150 DST=1.2.3.152 LEN=40 TOS=0x00 PREC=0x00 TTL=128 ID=38799 DF PROTO=TCP SPT=1678 DPT=110 WINDOW=8760 RES=0x00 ACK URGP=0
А вот сервер стучится на 113 порт клиента:
Jun 9 20:38:33 host kernel: ACC_OUT: IN= OUT=eth0 SRC=1.2.3.152 DST=1.2.3.150 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=24084 DF PROTO=TCP SPT=1027 DPT=113 WINDOW=5840 RES=0x00 SYN URGP=0
Jun 9 20:38:36 host kernel: ACC_OUT: IN= OUT=eth0 SRC=1.2.3.152 DST=1.2.3.150 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=24086 DF PROTO=TCP SPT=1027 DPT=113 WINDOW=5840 RES=0x00 SYN URGP=0
Jun 9 20:38:42 host kernel: ACC_OUT: IN= OUT=eth0 SRC=1.2.3.152 DST=1.2.3.150 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=24088 DF PROTO=TCP SPT=1027 DPT=113 WINDOW=5840 RES=0x00 SYN URGP=0
Jun 9 20:38:54 host kernel: ACC_OUT: IN= OUT=eth0 SRC=1.2.3.152 DST=1.2.3.150 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=24090 DF PROTO=TCP SPT=1027 DPT=113 WINDOW=5840 RES=0x00 SYN URGP=0
Прошло 30 с - не достучался...
Jun 9 20:39:03 host kernel: ACC_OUT: IN= OUT=eth0 SRC=1.2.3.152 DST=1.2.3.150 LEN=86 TOS=0x00 PREC=0x00 TTL=64 ID=8749 DF PROTO=TCP SPT=110 DPT=1678 WINDOW=5840 RES=0x00 ACK PSH URGP=0
Jun 9 20:39:03 host kernel: ACC_IN: IN=eth0 OUT= MAC= SRC=1.2.3.150 DST=1.2.3.152 LEN=53 TOS=0x00 PREC=0x00 TTL=128 ID=55439 DF PROTO=TCP SPT=1678 DPT=110 WINDOW=8714 RES=0x00 ACK PSH URGP=0
Jun 9 20:39:03 host kernel: ACC_OUT: IN= OUT=eth0 SRC=1.2.3.152 DST=1.2.3.150 LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=8751 DF PROTO=TCP SPT=110 DPT=1678 WINDOW=5840 RES=0x00 ACK URGP=0
И т.д.
2.
Если sendmail слушает только локальный интерфейс 127.0.0.1, то исправить это можно следующим образом.
В /etc/sendmail.cf закомментировать строку с DaemonPortOptions=Port=smtp,Addr=127.0.0.1, Name=MTA
и добавить строку
O DaemonPortOptions=Port=smtp,Addr=0.0.0.0, Name=MTA
после чего перезапустить sendmail
Или в sendmail.mc закомментировать строку
DAEMON_OPTIONS(`Port=smtp,Addr=127.0.0.1, Name=MTA')
и добавить строку (что, в общем-то лишнее, т.к. sendmail по умолчанию и так слушает на внешнем интерфейсе,
подробности см. ниже)
DAEMON_OPTIONS(`Port=smtp,Addr=0.0.0.0, Name=MTA')
после чего пересобрать sendmail.cf и перезапусть sendmail.
Теперь Sendmail будет слушать smtp-порт на всех интерфейсах.
Но если вы используете SUSE, то следует посмотреть и в файл /etc/sysconfig/mail
и исправить в опции SMTPD_LISTEN_REMOTE "no" на "yes". По умолчанию sendmail в SUSE слушает
только локальный интерфейс.
Хотя sendmail, собранный из исходников, по умолчанию слушает внешний порт:
"...
DaemonPortOptions=options
[O] Устанавливает опции сервера SMTP. Каждое вхождение DaemonPortOptions
приводит к дополнительному входящему сокету. Опции - пары ключ=значение.
Известные ключи:
Name Имя демона, определяемое пользователем (по умолчанию - "Daemon#")
Port Имя/номер рабочего порта (по умолчанию "smtp")
Addr Адресная маска (по умолчанию INADDR_ANY)
Family Семейство адресов (по умолчанию INET)
Listen Размер очереди прослушивания (по умолчанию 10)
Modifier Опции (флаги) для демона
..."
/usr/src/senail-XXX/cf/README:
"...
If DAEMON_OPTIONS is not used, then the default is
DAEMON_OPTIONS(`Port=smtp, Name=MTA')
DAEMON_OPTIONS(`Port=587, Name=MSA, M=E')
..."
20.08.08. Ну и владельцам SUSE и некоторых других nix-систем не стоит забывать про прибамбас по умолчанию SMTPD_LISTEN_REMOTE="no" в /etc/sysconfig/mail или в /etc/rc.conf: sendmail_enable="NO"
.
Нужно изменить эту строку на SMTPD_LISTEN_REMOTE="yes" (SUSE) или (sendmail_enable="YES" и sendmail_submit_enable="YES") (FreeBSD) и будет вам счастье. Хотя я бы за такие "прибамбасы" создателей дистрибутивов бы прибивала на месте.
Это издевательство. У sendmail есть свой конфиг и в нем все прописано. Зачем еще огороды городить?
Когда на форумах спрашивают про слушающие только на локальных интерфейсах sendmail'ы, я все время забываю вот про эти извращения, и начинаю советовать то, о чем написано в начале
этого пункта. У человека ничего не получается. Я выхожу из себя. А потом оказывается, что есть еще один конфиг. "Поубывала бы !!!" Тех, кто это придумал.
24.10.2008. Для чего еще можно использовать опцию DAEMON_OPT:
I have run sendmail on 2 ports:
O DaemonPortOptions=Name=MTA #25 (only for local users)
O DaemonPortOptions=Port=587, Name=MSA, M=Ea #587 (for everybody, who know login)
First daemon don't require authentication, second daemon require it.
3. Все возможные имена почтового домена хранятся в файле /etc/sendmail.cw (для старых версий sendmail) и /etc/mail/local-host-names в последних версиях.
Вместе с адресами и именами сетевых интерфейсов, прописанных в /etc/hosts, они составляют все возможные значения встроенного класса $=w.
В различных примерах check_mail, checl_rcpt, check_compat он часто используется для проверки доменной части e-mail-адреса на локальность,
то есть принадлежность данного почтового ящика локальному почтовому серверу.
Посмотреть все значения это класса можно следующим образом:
>sendmail -bt
$=w
Результат будет примерно таким:
mail.yourdomain.ru
yourdomain.ru
localhost.localdomain
localhost
[localhost.localdomain]
[127.0.0.1]
other_name_of_your_domain.ru.ru
[12.34.56.78] - ip-адрес вашего хоста
За выключение дополнительных интерфейсов из содержимого класса $=w отвечает опция DontProbeInterfaces:
define(`confDONT_PROBE_INTERFACES',`True') .
/usr/src/sendmail-XXX/doc/op.me говорит об этом так (перевод из http://www.opennet.ru/docs/RUS/sendmail2/sendmail5.html#toc56):
" ... Sendmail при запуске обычно находит имена для всех активных
(на вашей машине) интерфейсов и добавляет их имена в класс известных псевдонимов
хоста $=w. Если у вас большое количество виртуальных интерфейсов, или если
обратный просмотр вашего DNS медленный, то это может занять некоторое время. Эта
опция отключает такой просмотр. Однако, вы должны быть уверены, что вы включили
все варианты имен в класс $=w с помощью любого другого механизма..."
Этим механизмом может быть включение необходимых псевдонимов и ip-адресов в /etc/mail/local-host-names,
а также использование mailertable.
Все это необходимо для того, чтобы почта на прописанные в /etc/hosts адреса воспринималась верно, а не возвращалась с сообщением "config error: mail loops back to me (MX problem?)".
4.1 Как изменить адрес отправителя при отправке сообщения с linux-хоста.
2)mail -s123 recipient@somedomain.ru -- -fsender_address@domain.ru
1) mail -sТема someuser@somedomain.ru -- -F sender_address@domain.ru
3)/usr/sbin/sendmail -fsender_address@domain.ru someuser@mail.ru
4.2 Добавить attachment из командной строки:
date|mail -s"Please see attachment" terrapin@anrb.ru -a so-admin-guid-2.3.pdf
NB! Ключ -a используется в том mail, который nail.
4.3 Как отправить html-файл из командной строки с помощью nail, mail, sendmail
27.10.2010.
1. apt-cache search nail|grep nail
nail - The /bin/nail program for send and receive MIME conformant mail
Речь о проекте Heirloom mailx. Отвечает разработчик.
Re: Sending HTML mails from command line
"Jean-Francois Bucas" < jfbucas@...> wrote:
> I'm trying to send HTML mails from the command line using nail.
Gunnar Ritter < gunnarr@... > 2008-11-09 22:18:15 GMT
This program doesn't support sending HTML mail.
2. С помощью простого mail.
apt-cache search mail|grep mailx
mailx - The /bin/mail program for sending e-mail messages
uuencode result.html result.html |mailold -s"Full report" someuser
3. С.п. sendmail это делается так.
4. Как приаттачить html-документ (Источник):
#!/bin/sh
# Handlig collected weekly sar data via SarCheck
cat /usr/adm/sa/sar* > /tmp/multisar
(echo "Subject: SarCheck weekly report"
echo "MIME-Version: 1.0"
echo "Content-Type: text/html; charset=\"us-ascii\""
date +'Date: %a, %d %b %T (%Z)%n'
/usr/bin/ulite -html /tmp/multisar) | \
/usr/lib/sendmail root && rm -f /tmp/multisar
главное - добавить в хидер
MIME-Version: 1.0
Content-Type: text/html; charset="us-ascii"
проверил, так работает (bash)
$ (echo -e "Subject: Cool_HTML\nMIME-Version: 1.0\nContent-Type: text/html;
charset=\"koi8-r\""; cat your.html) |\
> /usr/sbin/sendmail @ddress
4.4 Как отправить письмо с.п. скрипта
25.01.2013. Вот так работает - проверено (без sleep - не работает!):
1. #!/bin/bash
{
sleep 5
echo helo lo
sleep 5
echo mail from: diana@anrb.ru
sleep 5
echo rcpt to: diana
sleep 5
echo data
sleep 5
echo test
sleep 5
echo .
sleep 5
} | telnet mail.anrb.ru 25
И вот так получится, проверено (а вот первоисточник):
(echo "EHLO LO";sleep 5;echo "MAIL FROM:gatling@anrb.ru";sleep5;echo "RCPT TO:paradise@anrb.ru";sleep 5;echo "RCPT TO:consiglio@anrb.ru";sleep 5;echo "DATA";sleep 5;echo "Bcc: consiglio@anrb.ru";sleep 5;
echo "To: paradise@anrb.ru";sleep 5;echo "Subject: Test";sleep 5;echo "Test";sleep 5; echo ".";sleep 5) || telnet mail.anrb.ru 25
А вот так - нет: telnet mail.anrb.ru 25 <telnet.script
2. An Email Program for Sending SMTP Mail from a Command Line. [Источник.]
SendEmail is a lightweight, command line SMTP email client. If you have the need to send email from a command line, this free program is perfect: simple to use and feature rich. It was designed to be used in bash scripts, batch files, Perl programs and web sites, but is quite adaptable and will likely meet your requirements. SendEmail is written in Perl and is unique in that it requires NO MODULES. It has an intuitive and flexible set of command-line options, making it very easy to learn and use.
SendEmail is licensed under the GNU GPL, either version 2 of the License or (at your option) any later version.
[Supported Platforms: Linux, BSD, OS X, Windows 98, Windows NT, Windows 2000, & Windows XP]
5. Взаимодействие sendmail и DNS (как отключить обязательное обращение sendmail к DNS за MX-записью, sendmail и nsswitch.conf).
Если на почтовом сервере не установлен DNS, то при отсутствии связи почта, посланная с сервера локальному пользователю будет доставляться с минутной задержкой.
Оказывается, sendmail делает обязательный запрос к dns-серверу на предмет MX-записи почтовик-получателя
вне зависимости от файлов hosts, nsswitch.conf, hosts.conf.
Об этом говорится в /usr/src/sendmail-XXX/doc/op/op.me:
"...Notice: since sendmail must access MX records for correct operation, it will use DNS if it is configured in the ServiceSwitchFile file. Hence an entry like
hosts files dns
will not avoid DNS lookups even if a host can be found in /etc/hosts..."
Per Hedeland по этому поводу пишет:
"...Почтовый стандарт требует, чтобы поиск MX-записи происходил раньше поиска А-записи, и так как MX-запись может быть определена только в DNS, то sendmail обязан
сначала связаться с DNS, если он существует.
Вы можете предотвратить обращение к DNS либо через определение mailertable для определенного хоста/домена (поместив его в квадратные скобки для запрещения поиска MX-записи;
вместо этого должно произойти стандартное обращение к /etc/hosts (standard hostname lookup) ):
domain.com esmtp:[domain.com]
либо определив "0" флаг для SMTP-мэйлера для всех доменов:
MODIFY_MAILER_FLAGS(`SMTP', `+0')
Обращения к DNS в целях канонификации могут сохраниться, но это не должно быть проблемой..."
Claus Assmann помимо использования "0" флага для мэйлера, еще советует
выставить в адресе получателя квадратные скобки вокруг домена.
Можно определить дополнительный mailer с флагом "0", а затем в mailertable указать именно этот mailer,
чтобы не было обращенийк днс за mx-записью.
Интересным оказался вопрос о взаимодействии (вернее об отсутствии оного) между sendmail и nsswitch.conf.
Как известно, этот файл используется Linux (и не только этой ОС ) для определения последовательности, в которой необходимо просматривать источники информации для резолвинга (в некоторых случаях используется /etc/hosts.conf:
это зависит от того, какую версию стандартной библиотеки ( libc или glibc) использует ваш Linux
(оригинал LNUG)).
Так вот, оказывается, sendmail на Linux (а также dig, nslookup - они разрешают имена напрямую) не использует nsswitch.conf.
Для указания порядка просмотров для резолвинга, sendmail на Linux использует файл /etc/mail/service.switch. При этом, если в строке
hosts имеется слово "dns", то обращение к DNS за MX-записью будет обязательно первым вне зависимости от того, в какой последовательности расположены в этой строке элементы:
hosts files dns nis
или
hosts nis files dns.
21.08.2008. Кстати, обратите внимание, что опция FEATURE(nodns) устарела, на сайте есть объяснение тому, как нужно настраивать sendmail в случае отсутствия DNS.
...the problem comes from
your trying to
use a different resolver library than the Solaris standard one with
sendmail. The gethostby*() functions, the nss_* libraries (for the
nsswitch functionality) etc assume the standard OS resolver library, and
a mismatch may cause them to fail, while sendmail's "direct" DNS lookups
work fine.
6. В чем различие между /etc/mail/relay-domains и /etc/mail/access ?
Эта запись из /etcmail/relay-domains
212.193.134.2
и эта из /etc/mail/access
212.193.134.2 RELAY
приведут к одному результату: с ip-адреса 212.193.134.2 разрешается релеить почту.
Спашивается, зачем нужны диблирующие друг друга файлы?
Во-первых, формат файла access более изыскан: он позволяет работать с почтовыми ящиками;
с помощью тэгов "From:/To:" он позволяет отвергать/принимать почту от/к юзер(а/у);
с помощью тэга CONNECT: добавлять список исключений для блокировки проверки в черных списках (FEATURE(dnsbl)) и т.д.
Файл /etcmail/relay-domains выполняет только одну функцию: разрешает релеинг определенному адресу/сетке.
Но в этой простоте кроется большое преимущество перед access:
если вы пишете собственные наборы правил в sendmail.mc, то вам часто приходится делать проверку на принадлежность
ip-адреса источника письма списку разрешенных к релеингу адресов. Если эти адреса прописаны только в relay-domains, то достаточно написать что-то подобное (просто и элегантно:):
R$* $: $&{client_addr}
R$=R $* $@ OK
R$* $# error ...
Если же вы разрешили релеить определенным адресам/сеткам в /etc/mail access, то придется наворотить следующее (безтэговая обработка):
R$* $: $&{client_addr}
R$-.$-.$-.$- $: $(access $1.$2.$3.$4 $: $1.$2.$3 $)
RRELAY $@ OK
R$-.$-.$- $: $(access $1.$2.$3 $: $1.$2 $)
RRELAY $@ OK
R$-.$- $: $(access $1.$2 $)
RRELAY $@ OK
R$* $#error ...
Тэговая обработка:
R$* $: $&{client_addr}
R$-.$-.$-.$- $: $(access CONNECT:$1.$2.$3.$4 $: $1.$2.$3 $)
RRELAY $@ OK
R$-.$-.$- $: $(access CONNECT:$1.$2.$3 $: $1.$2 $)
RRELAY $@ OK
R$-.$- $: $(access CONNECT:$1.$2 $)
RRELAY $@ OK
R$* $# error ...
Как говорится, почувствуйте разницу.
Еще один нюанс, теперь уже в пользу access : relay-domains относится к классу F, считывается единожды при загрузке sendmail,
после изменения relay-domains необходимо рестартовать sendmail, а access относится к BerkleyDB, в случае с ним
достаточно исполнить
makemap hash access < access
Однако лично мне жаль, что разработчики в скором времени собираются расстаться с relay-domains и классом R:
"...The class $=R holds as its list of values the host and domain names that sendmail should allow mail to be relayed to. This $=R class should not be used directly because it could change without notice in future versions of sendmail..."
FEATURE(`confCR_FILE', `/etc/mail/somefile') позволяет в $=R добавить адреса из другого файла, в дополнение к relay-domains.
15.11.2008. И еще один нюанс в пользу access: IP-адреса, которым уже разрешен RELAY или OK,
не будут подвластны FEATURE(Rate/ConnControl).
Ссылки по теме:
SMTP relaying in Sendmail 8.9 and later
access vs relay-domains
access db; /etc/mail/relay-domains
7. Почему макрос $&{client_addr} иногда бывает равен 0 ?
Andrzej (Andrew) A. Filip :
Этот макрос обнуляется сразу после завершения соединения. Поэтому, если письмо поставлено в очередь,
для него этот макрос будет нулевым.
В отличие от него макрос $_ сохраняется и в очереди, поэтому может быть использован вместо $&{client_addr}.
Per Hedeland :
(You might also want to allow "local connections", i.e. basically
someone running 'sendmail -bs' from the commandline - from the
"standard" rules:
# check IP address
R$* $: $&{client_addr}
R$@ $@ RELAYFROM originated locally
R0 $@ RELAYFROM originated locally
)
20.01.2009. При отладке задачек по маршрутизации один раз столкнулась с тем , что IP был вовсе пустой.
Воспроизвести ту ситуацию не могу. Помню лишь, что это было связано с отлупом/DSN сообщением.
17.02.2009. Если запустить sendmail в тестовом режиме, то $&{client_addr} будет пустым:
Feb 16 17:09:14 mail sendmail[32635]: n1GC9EvH032635: syslog:mail:NULL_ADDR:2:<><>relay=.root@localhost
Правила из Local_check_mail sendmail.mc:
R$* $:
< $&{client_addr} >
R<[0]> $:
$(syslog syslog:mail:NULL_ADDR:1: <$&{client_addr}> <$&s> relay= $&_ $)
R<> $:
$(syslog syslog:mail:NULL_ADDR:2: <$&{client_addr}> <$&s> relay= $&_ $)
echo "Local_check_mail terrapin@anrb.ru"|sendmail -bt и дает такой результат.
8. Почему не стоит полагаться на статистику, выдаваемую по команде mailstat ?
Потому, что mailstat подсчитывает и отвергнутую почту, за исключением той, что отвергнута на этапе check_relay, когда информация о размере сообщения недоступна.
9. Как создать системного пользователя с точкой.
Навеяно вот этим обсуждением проблемы с точкой в имени пользователя.
Если в имени пользователя есть точка, то его невозможно назначить владельцем какого-либо файла
из-за синтаксиса команды chown:
chown user.group file
Пользуюсь точкой в именах уже давно, когда-то - на RH5.2 И BC6.2, теперь на Suse.
Не помню, позволяли ли по умолчанию такие имена два предыдущих дистра, но вот на последнем делаю так:
1) создаю пользователя a_ivanov, соответственно система создает домашнюю директорию с правами этого юзера;
2) исправляю в /etc/passwd a_ivanov на a.ivanov;
3) после чего система сама (!!!) автоматически меняет права у домашней директории на a.ivanov
4) при получении почты в /var/spool/mail создается почтовый файл a.ivanov с правами этого же пользователя.
28.04.2008. Как сообщил мне Владимир Васильев, во-первых, "в команде chown можно использовать и : в качестве разделителя."
Во-вторых, "внутри себя linux использует числовые идентификаторы" (комментарий к пункту 3).
10. Увеличиваем уровень логирования.
1. Можно запустить sendmail с ключом -X :
sendmail -bd -q1h -X logfile
X - протоколировать весь трафик, входящий в и выходящий из sendmail в указанный logfile при проблемах отладки почтовых программ. При этом быстро выдается большое количество данных, поэтому эта опция должна использоваться умеренно.
2. Можно пересобрать конфиг с более высоким уровнем логирования:
define(`confLOG_LEVEL',`15')
15 - протоколирование всех входящих и исходящих команд SMTP.
11.Сообщение в maillog: Local configurqation error: Mail loops back to me.
22.11.2007. Определим термины.
Здесь и далее я буду называть основным mx-ом mx с наименьшим весом.
А остальные mx-ы (mx-ы с наибольшим весом) - вторичными.
Пусть в днс имеется
domain.ru MX 5 mail.domain.ru
domain.ru MX 10 mail2.domain.ru.
domain.ru MX 15 mail3.domain.ru.
Тогда mail.domain.ru - основной mx, mail2(mail3).domain.ru - вторичные mx.
Первая причина этого сообщения всем известна и, как правило, это случается у новичков на основном mx-е.
Ваш почтовый домен domain.ru в dns указывает на ваш почтовый сервер mail.domain.ru,
но сам почтовый домен sendmail-у на mail.domain.ru не известен как локальный,
то есть он не прописан в /etc/mail/local-host-names.
Почта, предназначенная вашему домену в соответствии с mx-записью в днс пришла к вам на сервер,
но почтовик не может ее ни принять для себя
(соответствующая запись отсутствует /etc/mail/local-host-names), ни отправить далее
(запись вида domain.ru RELAY в /etc/mail/access отсутствует и в mailertable
cоотв. запись также отсутствует).
Sendmail на такую ситуацию реагирует записью в лог: Local configuration error: Mail loops back to me.
Решение: если почта должна остаться на этом же сервере,
куда она пришла, пропишите свой почтовый домен в /etc/mail/local-host-names.
Если же почта должна пройти транзитом дальше, то надо, во-первых, разрешить
sendmail-у релеить почту дальше, это делается с помощью записи в /etc/access:
domain.ru RELAY
В том случае, когда транзитный почтовик - mx, этого достаточно, если основной сервер работает стабильно и всегда доступен.
Если же он периодически выпадает из сети, то следует обратить внимание на это решение.
Во-вторых, если к тому же нужно изменить маршрут следования транзитной почты, то следует указать, куда именно почту перенаправлять.
Это делается с помощью mailertable.
domain.ru smtp:somehost.somewhere.ru
Вторая причина. Ваш сервер пытается отправить письмо на почтовый домен, mx-запись которого
указывает на loopback-адрес 127.0.0.1
Решение. Блокировать такие домены.
1. Можно использовать
FEATURE(rhsbl,`bogusmx.rfc-ignorant.org',`"550 Mail from domain " $`'&{RHS} " refused. MX of source domain points to 127.0.0.1 - see http://www.rfc-ignorant.org/"')
2. Можно проверять такие домены у себя на сервере.
Третья причина.
Несколько ваших mx-ов и недоступный основной mx.
Если основной mx недоступен, то почта сваливается на второй mx, который, не обнаружив среди
доступных первый mx, попытается доставить почту следующему mx-у, то есть себе же, но поскольку
mx не может принять транзитную почту локально (из-за отсутствия транзитного почтового домена
в /etc/mail/local-host-names),
то это вызовет стандартную ошибку: Local configuration error: Mail loops back to me.
Решение.
Заставить вторичные mx-ы оставлять почту для основного mx-а у себя (то есть в очереди)
до тех пор, пока не поднимется основной mx вместо того, чтобы пытаться доставить письмо mx-у с большим весом.
Добиться этого можно отключением функции поиска mx-записей для данного домена,
для чего достаточно в /etc/mail/mailertable основной сервер поместить в квадратные скобки:
domain.ru smtp:[mail.domain.ru]
Правда, Peter Hedeland предупреждает, что в этом случае нужно постоянно помнить о необходимости
изменения этой записи, ведь mx-записи в днс могут поменяться:
"...it's a Bad Idea - what happens if
domain.com change their MX records, pointing the primary somewhere other
than mail.domain.com? Will the above mailertable entry get updated? Not
automatically, that's for sure..."
Четвертая причина.
CNAME-запись в днс.
Навеяно вот этим
обсуждением.
Как водится автор так и не удосужился сообщить, чем же закончилась эта эпопея.
Но мне стало интересно, что же на самом деле происходит, если письмо высылается на домен,
который является CNAME для некоего почтовика.
Итак, добавляем в файл зоны запись:
deodar CNAME mail
Отправляем письмо: date|mail -sTest paradise@deodar.anrb.ru
При этом имеем в виду, что использование CNAME в качестве почтового домена - нарушение RFC.
Но мне-то, как вы догадываетесь, интересно узнать, а что в этом случае произойдет?
В заголовке полученного письма видим, что домен получателя был изменен на mail.anrb.ru.
Кто же его меняет - отправляющий или принимающий сервер?
Received: from apache.anrb.ru (www.anrb.ru [212.193.134.3])
by mail.anrb.ru (8.14.2/8.14.2) with ESMTP id m1TDCJac021729
for < paradise@mail.anrb.ru >; Fri, 29 Feb 2008 18:12:19 +0500
Received: from smile.anrb.ru (smile.anrb.ru [1.2.3.4])
by apache.anrb.ru (8.14.2/8.14.2) with ESMTP id m1TCj1m2004327
for < paradise@deodar.anrb.ru >; Fri, 29 Feb 2008 17:45:01 +0500
На отправляющем сервере даем команду:
echo "canonify paradise @ deodar.anrb.ru"|/usr/sbin/sendmail -bt
ADDRESS TEST MODE (ruleset 3 NOT automatically invoked)
Enter <ruleset> <address>
> canonify input: paradise @ deodar . anrb . ru
Canonify2 input: paradise < @ deodar . anrb . ru >
Canonify2 returns: paradise < @ mail . anrb . ru . >
canonify returns: paradise < @ mail . anrb . ru . >
>
Значит, домен изменяет отправляющий сервер. А как именно он это делает? Обкладывает правила в canonify & Canonify2
выводом в syslog, и в логе отправляющего сервера видим, что изменение происходит в наборе Canonify2 (syslog:Can2:) между 9-ым и 10-ым выводом:
...
Feb 29 18:15:06 apache sendmail[5952]: m1TDF6Hv005952: syslog:Can:5.paradise<@deodar.anrb.ru>
Feb 29 18:15:06 apache sendmail[5952]: m1TDF6Hv005952: syslog:Can2:00.paradise<@deodar.anrb.ru>
...
Feb 29 18:15:06 apache sendmail[5952]: m1TDF6Hv005952: syslog:Can2:9\233paradise<@deodar.anrb.ru>
Feb 29 18:15:06 apache sendmail[5952]: m1TDF6Hv005952: syslog:Can2:10.paradise<@mail.anrb.ru.>
...
Feb 29 18:15:06 apache sendmail[5952]: m1TDF6Hv005952: from=<root@apache.anrb.ru>, size=459, class=0, nrcpts=1,
msgid=<991776441.20080229182831@anrb.ru>, proto=ESMTP, daemon=MTA, relay=smile.anrb.ru [1.2.3.4]
...
Feb 29 18:15:06 apache sendmail[5954]: m1TDF6Hv005952: to=<paradise@deodar.anrb.ru>, delay=00:00:00,
xdelay=00:00:00, mailer=esmtp, pri=120459, relay=mail.anrb.ru. [212.193.134.2], dsn=2.0.0, stat=Sent (m1TDgOIa000875
Message accepted for delivery)
А правило, которое я обложила этим выводом вот такое:
# pass to name server to make hostname canonical
R$* $| $* < @ $* > $* $: $2 < @ $[ $3 $] > $4
И в ../sendmail/doc/op.me по этому поводу говорится:".. ($[ ... $]) also prefers
A and CNAME over MX ...", даже если mx найдется, то он имеется в виду, но поиск (A, CNAME) продолжается.
Итак, принимающий сервер получает переписанное имя домена и спокойно принимает его.
Можно запретить отправляющему серверу с помощью опции define(`confDONT_EXPAND_CNAMES',`True') изменять CNAME-домен получателя.
Но в этом случае принимающая сторона отругается стандартным
Feb 14 21:58:06 mail sendmail[15441]: m1EGw6VQ015436: SYSERR(root): deodar.anrb.ru. config error: mail loops back to me
(MX problem?)
потому как на принимающем сервере в /etc/mail/local-host-names CNAME deodar.anrb.ru отсутствует.
А вот обсуждение проблемы "CNAME && MX" - здесь.
[2]
Пятая причина.
2 sendmail на одном хосте.
Для чего могут понадобится 2 sendmail'a? Первая причина. Вторая причина.
Ссылки по теме " Local configurqation error: Mail loops back to me.".
- Subject: Q4.5 -- How can I solve "MX list for hostname points back to hostname" and "config error: mail loops back to myself" messages?
- Queueing mail at secondary MX Options
- Hints about sendmail/e-mail: config error: mail loops back to myself
- cf/README for sendmail: Using Mailertables
- Even more hints about sendmail/e-mail: How to queue mail for a domain that is seldom online?
- www.opennet.ru: [6]
- [7]
- Не нужно так делать
- cat /etc/mail/mailertable: . esmtp:mail.MYDOMEN.ua
" ...Ну и на кой, простите, фиг, вам нужна эта строка, "всю почту на куда угодно отправлять через себя самого"? Обычно, такая строка присутствует на внутренних релеях, а ее наличие на внешних релеях - признак существенных (очень) проблем..."
12. Немного про aliases.
В наборе Local_check_rcpt разалиасинг не происходит.
Поэтому адрес обрабатывается "как есть":
список рассылок по своему имени, алиас - по имени алиаса.
В набор check_compat имя получателя приходит после "разалиасинга", поэтому здесь мы увидим уже конечного получателя.
13. Если почтовый клиент мудрит с почтовым доменом, заданном в виде ip.
24.12.2007. Оказывается, некоторые почтовые клиенты видоизменяют адрес получателя, если почтовый домен задан в виде ip-адреса.
При этом в логе вы увидите следующее (письмо отправлено TheBat! v.3.99.24):
Dec 13 16:11:11 apache sendmail[30982]: lBDBBB49030982: syslog:rcpt:0:<paradise@[212.193.134.2]>
Dec 13 16:11:11 apache sendmail[30982]: lBDBBB49030982: from=<gatling@anrb.ru>, size=463, class=0, nrcpts=1,
msgid=<1241343757.20071213162006@anrb.ru>, proto=ESMTP, daemon=MTA, relay=[10.10.10.10]
Dec 13 16:11:11 apache sendmail[30984]: lBDBBB49030982: to=<paradise@[212\\.193\\.134\\.2]>, delay=00:00:00,
xdelay=00:00:00,
mailer=esmtp, pri=120463, relay=[212.\\.193\\.135\\.6], dsn=5.1.2, stat=Host unknown (Name server: [212\\.193\\.134\\.2]:
host not found)
Dec 13 16:11:11 apache sendmail[30984]: lBDBBB49030982: lBDBBB49030984: DSN: Host unknown (Name server:
[212\\.193\\.134\\.2]: host not found)
Dec 13 16:11:12 apache sendmail[30984]: lBDBBB49030984: to=<gatling@anrb.ru>, delay=00:00:01, xdelay=00:00:01,
mailer=smtp, pri=31659, relay=mail.anrb.ru. [212.193.134.2], dsn=2.0.0, stat=Sent (lBDBNJCw019799 Message accepted for
delivery)
По логу почтовика, на котором крутится ДрВеб, видно, что от почтового клиента адрес получателя пришел в виде
paradise@[212\.193\.134\.2], а sendmail, обнаружив \ в адресе, обложил его back slash'ем еще раз.
Dec 13 16:25:02 mail sendmail[21645]: lBDBP2r1021645: from=<gatling@anrb.ru>, size=462, class=0, nrcpts=1,
msgid=<447090006.20071213162149@anrb.ru>, proto=ESMTP, daemon=MTA, relay=[10.10.10.10]
Dec 13 16:25:02 mail drweb-smf[21646]: [lBDBP2r1021645]: scan: the message(drweb.tmp.e1GJQw) sent by gatling@anrb.ru
to paradise@[212\.193\.134\.2] is passed
Dec 13 16:25:02 mail drweb-smf[21646]: [lBDBP2r1021645]: processing message from gatling@anrb.ru is over
Dec 13 16:25:02 mail sendmail[21645]: lBDBP2r1021645: Milter add: header: X-Antivirus: Dr.Web (R) for Mail Servers on
mail host
Dec 13 16:25:02 mail sendmail[21645]: lBDBP2r1021645: Milter add: header: X-Antivirus-Code: 100000
Dec 13 16:25:02 mail sendmail[21645]: lBDBP2r1021645: Milter add: header: X-Spam-Flag: SKIP
Dec 13 16:25:02 mail sendmail[21645]: lBDBP2r1021645: Milter add: header: X-Spam-Yversion: Spamooborona 1.7.0
Dec 13 16:25:05 mail sendmail[21694]: lBDBP2r1021645: to=<paradise@[212\\.193\\.134\\.2]>,
ctladdr=<gatling@anrb.ru> delay=00:00:03, xdelay=00:00:03, mailer=esmtp, pri=120462, relay=[212\\.193\\.135\\.6],
dsn=5.1.2, stat=Host unknown (Name server: [212\\.193\\.134\\.2]: host not found)
Dec 13 16:25:05 mail sendmail[21694]: lBDBP2r1021645: lBDBP5r1021694: DSN: Host unknown (Name server:
[212\\.193\\.134\\.2]: host not found)
Dec 13 16:25:06 mail sendmail[21694]: lBDBP5r1021694: to=postmaster, delay=00:00:01, xdelay=00:00:01, mailer=local,
pri=31785, dsn=2.0.0, stat=Sent
Вместе с тем с почтового сервера такая почта ходит нормально:
Dec 13 16:09:10 apache sendmail[30880]: lBDB9AfP030880: from=gatling, size=281, class=0, nrcpts=1,
msgid=<476112D6.mailNTR1QQFP9@apache.anrb.ru>, relay=root@localhost
Dec 13 16:09:10 apache sendmail[30881]: lBDB9Aij030881: syslog:rcpt:0:<paradise@anrb.ru>
Dec 13 16:09:10 apache sendmail[30880]: lBDB9AfP030880: from=gatling, size=281, class=0, nrcpts=1,
msgid=<476112D6.mailNTR1QQFP9@apache.anrb.ru>, relay=root@localhost
Dec 13 16:09:10 apache sendmail[30880]: lBDB9AfP030880: to=paradise@[212.193.134.2], ctladdr=root (0/0), delay=00:00:00,
xdelay=00:00:00, mailer=relay, pri=30281, relay=[127.0.0.1] [127.0.0.1], dsn=2.0.0, stat=Sent (lBDB9Aij030881 Message
accepted for delivery)
Dec 13 16:09:10 apache sendmail[30882]: lBDB9Aij030881: to=<paradise@apache.anrb.ru>, ctladdr= (0/0),
delay=00:00:00, xdelay=00:00:00, mailer=local, pri=30664, dsn=2.0.0, stat=Sent
Отправляем письмо telnet'ом - тоже все ок:
Dec 14 15:37:29 mail sendmail[14668]: lBEAaU8l014668: syslog:rcpt:0.paradise@[212.193.134.2]
Dec 14 15:37:33 mail sendmail[14668]: lBEAaU8l014668: from=gatling@anrb.ru, size=2, class=0, nrcpts=1,
msgid=<200712141037.lBEAaU8l014668@mail.anrb.ru>, proto=SMTP, daemon=MTA, relay=[10.10.10.10]
Dec 14 15:37:33 mail drweb-smf[14669]: [lBEAaU8l014668]: scan: the message(drweb.tmp.mOGD3Z) sent by gatling@anrb.ru
to paradise@[212.193.134.2] is passed
Dec 14 15:37:33 mail sendmail[14668]: lBEAaU8l014668: Milter add: header: X-Antivirus: Dr.Web (R) for Mail Servers on
mail host
Dec 14 15:37:33 mail sendmail[14668]: lBEAaU8l014668: Milter add: header: X-Antivirus-Code: 100000
Dec 14 15:37:33 mail drweb-smf[14669]: [lBEAaU8l014668]: processing message from gatling@anrb.ru is over
Dec 14 15:37:33 mail sendmail[14668]: lBEAaU8l014668: Milter add: header: X-Spam-Flag: SKIP
Dec 14 15:37:33 mail sendmail[14668]: lBEAaU8l014668: Milter add: header: X-Spam-Yversion: Spamooborona 1.7.0
Dec 14 15:37:33 mail sendmail[15766]: lBEAaU8l014668: to=paradise@[212.193.134.2], delay=00:00:04, xdelay=00:00:00,
mailer=local, pri=30427, dsn=2.0.0, stat=Sent
Можно также проверить вывод такой команды, чтобы убедиться что у sendmail нет проблем с правильным восприятием такого эл. адреса:
/usr/sbin/sendmail -bv 'paradise@[212.193.135.6]'
paradise@[212.193.135.6]... deliverable: mailer local, user paradise
Или так:
/usr/sbin/sendmail -bt
ADDRESS TEST MODE (ruleset 3 NOT automatically invoked)
Enter <ruleset> <address:>
Набираем команду
Local_check_rcpt <gatling@[212.193.135.6]>
< Local_check_rcpt input: gatling < @ [ 212 . 193 . 135 . 6 ] >
canonify input: gatling < @ [ 212 . 193 . 135 . 6 ] >
Canonify2 input: gatling < @ [ 212 . 193 . 135 . 6 ] >
Canonify2 returns: gatling < @ [ 212 . 193 . 135 . 6 ] >
canonify returns: gatling < @ [ 212 . 193 . 135 . 6 ] >
Local_check_rcpt returns: OK
Per Hederland на это говорит: "Some broken software trying to be "helpful"...
Помнится мне, что Netscape Messenger воспринимал цифровой домен нормально, и
проверено на днях, что Outlook Express тоже не занимается самодеятельностью.
Jan 1 18:52:00 mail sendmail[21308]: m01Dpvau021308: from=<gatling@anrb.ru>, size=438, class=0, nrcpts=1,
msgid=<008601c84c7c$a8fcbad0$14e3fea9@al>, proto=ESMTP, daemon=MTA, relay=[1.2.3.4]
Jan 1 18:52:00 mail drweb-smf[21309]: [m01Dpvau021308]: scan: the message(drweb.tmp.mrd5tR) sent by gatling@anrb.ru to
paradise@[212.193.134.2] is passed
Jan 1 18:52:00 mail sendmail[21308]: m01Dpvau021308: Milter add: header: X-Antivirus: Dr.Web (R) for Mail Servers on
mail host
Jan 1 18:52:00 mail sendmail[21308]: m01Dpvau021308: Milter add: header: X-Antivirus-Code: 100000
Jan 1 18:52:00 mail drweb-smf[21309]: [m01Dpvau021308]: processing message from gatling@anrb.ru is over
Jan 1 18:52:00 mail sp-milter[21310]: For message from 1.2.3.4 will return ACCEPT, mailfrom:
<gatling@anrb.ru>, rcpto: <paradise@[212.193.134.2]>
Jan 1 18:52:00 mail sendmail[21312]: m01Dpvau021308: to=<paradise@[212.193.134.2]>, ctladdr=<gatling@anrb.ru> (1121/45),
delay=00:00:01, xdelay=00:00:00, mailer=local, pri=30710, dsn=2.0.0, stat=Sent
Вы меня спросите, зачем столько выдержек из лога?
Дело в том, что мне хотелось убедиться напрямую в том, что это, действительно, "самодеятельность" TheBat!,
и я задала вопрос на форуме сайта www.nobat.ru.
Но явного подтверждения не получила.
Поэтому сделала все возможные проверки.
Единственное, что меня все еще смущает, это то, что, если добавить вывод в лог текущего состояния
поданного на вход в Local_check_rcpt адреса получателя, то в лог он пишется в нормальном виде.
Но тут, я подозреваю, "заслуга" самого sendmail.
Потому что давно есть ощущение, что он на разных этапах обработки письма воспринимает спец. символы по разному.
И, возможно, в Local_check_rcpt \., полученный от TheBat!, он воспринимает как отмену значения точки как разделителя,
то есть как просто точку, и как просто точку пишет в лог.
А вот по мере дальнейшей обработки письма sendmail начинает воспринимать \ как самостоятельный символ,
поэтому добавляет к одному слэшу второй,
чтобы отменить спец. назначение слэша как символа, отменяющего разделительные свойства
последующей точки, в итоге получается на выходе \\.
Вы чего-нибудь поняли? :)
Я тоже не совсем. В общем, это "сюжет для небольшого" вопроса на sendmail-конфе.
14. Как с/п telnet отправить "слепую" копию письма.
26.12.2007.
Bcc: нужно указать на этапе DATA, но обязательно предварительно указать bcc-получателя в поле конвертного получателя, то есть в RCPT TO:
http://www.faqs.org/rfcs/rfc2821.html:
Each recipient address from a TO, CC, or BCC header field SHOULD
be copied to a RCPT command (generating multiple message copies if
that is required for queuing or delivery). This includes any
addresses listed in a RFC 822 "group". Any BCC fields SHOULD then
be removed from the headers. Once this process is completed, the
remaining headers SHOULD be checked to verify that at least one
To:, Cc:, or Bcc: header remains. If none do, then a bcc: header
with no additional information SHOULD be inserted as specified in
[32].
Пример. Пусть consiglio@anrb.ru должен получить blind carbon copy, то есть получатель paradise@anrb.ru
не должен знать, что это письмо отправлено еще и consiglio@anrb.ru.
telnet mail.anrb.ru 25
EHLO LO
MAIL FROM:gatling@anrb.ru
RCPT TO:paradise@anrb.ru
RCPT TO:consiglio@anrb.ru
DATA
Bcc: consiglio@anrb.ru
To: paradise@anrb.ru
Subject: Test
Test
.
Оба получателя получат письма с таким заголовком:
Return-Path:
Received: from lo ([1.2.3.4])
by mail.anrb.ru (8.14.1/8.14.1) with ESMTP id lBQD5tb1006998;
Wed, 26 Dec 2007 18:06:15 +0500
Date: Wed, 26 Dec 2007 18:05:55 +0500
From: gatling@anrb.ru
Message-Id: <200712261306.lBQD5tb1006998@mail.anrb.ru>
To: paradise@anrb.ru
Subject: Test
X-Antivirus: Dr.Web (R) for Mail Servers on mail host
X-Antivirus-Code: 100000
Status:
Test
Замечание: если после DATA указать только Bcc:, опустив To:, то в заголовке письма будет присутствовать
пустое поле Bcc:
15. Почему не следует в комментариях sendmail.mc упоминать MAILER-DAEMON.
28.12.2007.
Потому что сборка sendmail.cf (m4 sendmail.mc >sendmail.cf) вызовет ошибку:
Configuring sendmail.cf from sendmail.mc ...
m4: sendmail.mc: 302: Cannot open /usr/src/sendmail/cf/mailer/.m4: No such file or directory
При этом строка из sendmail.mc
#MAILER-DAEMON
преобразуется в
#-DAEMON
в sendmail.cf
То есть слово MAILER в комменте будет распознано как вызов файла /usr/src/sendmail/cf/mailer/MAILER.m4.
А этот файл отсутствует.
16. Почему невозможно проверить заголовок Bcc.
28.12.2007.
Per Hedeland:
The latter doesn't follow from the former - there is
absolutely no way you can detect that Bcc: was used, only that the
(final) recipient address isn't present in To:/Cc: - there are countless
ways to send email without the recipient ever being present in any
header. The obvious case is mailing lists (which will also be "hit" by
any rule like this) - they surely don't stuff a gazillion recipient
addresses into a Bcc: header.
Если отправитель указал получателя в Bcc и отправил письмо через какой-либо почтовый клиент
(MUA),
то эта почтовая программа должна будет размножить письмо в соответствии со списками получателей
в To:(если они указаны) & Bcc:,
указав в поле получатель получателя из To: (если он был) или вообще опустив это поле
(если в To: не был указан никто) и безусловно убрав подзаголовок Bcc:, а затем отправит
на почтовый сервер.
Если отправитель использует для отправки telnet, то sendmail сам сформирует заголовок письма
вышеописанным способом, и отправит письмо.
То есть в любом случае Bcc будет отсутствовать, и стало быть проверить его будет невозможно.
Еще ссылки:
Empty To:
Поле BCC "обрабатывает" почтовый клиент, который отправляет сообщение. Почтовый клиент соединяется с SMTP-сервером и с помощью команды RCPT TO сообщает об адресатах, которым будет отправлено письмо. При этом в заголовках письма поле "To:" может не совпадать с адресом, заявленным в RCPT TO. Этим механизмом пользуются как спамеры, так и рассылки/пересылки.
17. Как рассчитать значение Daemon Children?
Per Hedeland:"...
If you receive (for example) 100 connections per minute, and if it
takes an average of 2 seconds to receive one message, then you will
need 200 process-seconds. Divide that by 60 seconds per minute, and
you will see that you would need more than 3 daemon children to
handle that load. Realistically, you would need more to handle the
burstiness of traffic.
If you allow too few children for the current email rate, some will
get "connection refused". Presumably they will try later. So you
don't have to allow enough processes to handle the heaviest burst..."
Ссылки по теме:
[1]
[2]
[3]
[3]
18. Что означает одновременная запись в лог "ruleset=check_something" и "stat=Sent"
Пока кратенько, т.к. нет времени.
Есть у меня в конфиге вот такие правила, которые позволяют "выцеплять" среди почты письма, в заголовке которых
упоминаются некоторые "нехорошие" домены.
Производится эта проверка на этапе CheckReceived.
И вот заметила я в логе такую вещь: проверка срабатывает (ruleset=CheckReceived и reject в логе наблюдаются),
но письмо все равно доставляется получателю (stat=Sent).
KCH1 regex -a@YES
outblaze|check1check|mindspring|bigfoot|funnymail|bellsouth.net|tiscali.(it|nl|fr)|
wanadoo.(it|nl|fr)|nic.*olastse.(com|net)|videotron.ca|blueyonder|mailcity[.]|mexico|
comcast.net|earthlink.com|libertysurf.net|mozartmail.com|telepac.pt|edomex.com|
quintanaroo.com|telia.com|hideakifan.com|icq.com|delphi.com|optonline.net|interbusiness.it
[skip]
KChHeader sequence CH1 CH2 CH3 CH4 CH5 CH6
HReceived: $ >+CheckReceived
# Record the presence of the header Received
SCheckReceived
R$* $: $(storage {RecCheck} $@ $1 $)
#Return to WL_mail_from
R$* $: $&{WL_mail_from}
R1 $@ OK
#Return to ReceivedCheck
R$* $: $&{RecCheck}
# Clear the macros for the next message
R$* $: $(storage {RecCheck} $) $1
R$* $: $(ChHeader $1 $)
R@YES $#error $: "553 There is spam domain in the header."
-------
Jan 16 18:29:35 mail sendmail[16777]: m0GDTVAR016777: from=< >, size=3420, class=0, nrcpts=1, msgid=<
20080116132132.BD722578F5@an.ru >, proto=ESMTP, daemon=MTA, relay=relay.an.ru [213.142.209.142]
Jan 16 18:29:35 mail drweb-smf[16782]: [m0GDTVAR016777]: scan: the message(drweb.tmp.gYnh0y) sent by < > to
consiglio@anrb.ru is passed
Jan 16 18:29:35 mail drweb-smf[16782]: [m0GDTVAR016777]: processing message from < > is over
Jan 16 18:29:35 mail sendmail[16777]: m0GDTVAR016777: Milter add: header: X-Antivirus: Dr.Web (R) for Mail Servers on
mail host
Jan 16 18:29:35 mail sendmail[16777]: m0GDTVAR016777: Milter add: header: X-Antivirus-Code: 100000
Jan 16 18:29:36 mail sendmail[16777]: m0GDTVAR016777: Milter add: header: X-Spam-Ystatus: hits=-7.50
Jan 16 18:29:36 mail sendmail[16777]: m0GDTVAR016777: Milter add: header: X-Spam-Flag: NO
Jan 16 18:29:36 mail sendmail[16777]: m0GDTVAR016777: Milter add: header: X-Spam-Yversion: Spamooborona-2.1.0
Jan 16 18:29:36 mail sendmail[16796]: m0GDTVAR016777: ruleset=CheckReceived, arg1= from h195n2fls301o260.telia.com
(81.230.233.195) by pne-smtpout2-sn1.fre.skanova.net (7.3.129)\n id 478E02C700000E83 for ipnfifnu@olcon.murmansk.ru; Wed,
16 Jan 2008 14:21:05 +0100, relay=relay.an.ru [213.142.209.142], reject=553 5.0.0 < consiglio@anrb.ru >... There is spam
domain in the header."
Jan 16 18:29:36 mail sendmail[16796]: m0GDTVAR016777: to=< consiglio@anrb.ru >, delay=00:00:01, xdelay=00:00:00,
mailer=local, pri=33750, dsn=2.0.0, stat=Sent
-------
Теперь посмотрим на заголовок письма.
Мы видим, что в нем нет telia.com, на который и среагировал мой фильтр.
Но если посмотреть тело письма, то в нем можно обнаружить вложенное письмо, в заголовке которого как раз
и фигурирует telia.com.
Оказывается,
sendmail.cf проверяет и внутренние заголовки, содержащиеся в теле письма,
но это не имеет никакого значения для самого sendmail (Does it mean that sendmail.cf checks internal headers anyway but the result
doesn't matter for sendmail? ).
Вообще-то, на эти грабли я уже наступала, когда пыталась средствами sendmail.cf
заблокировать вложения с расширениями exe,com,pif,etc...
Тогда мне тогда также на sendmail-конфе
подтвердили,
что информация о вложениях находится во внутренних подзаголовках,
и проверке не подлежит.
Но вот то, что sendmail.cf и sendmail по разному относятся к внутренним подзаголовкам, я узнала только сейчас.
Кстати, обратите внимание на то, где в этом случае находится строка ruleset=CheckReceived:
не перед строкой from=, как это бывает, когда срабатывает реальная блокировка,
а перед строкой to=.
Одно это уже говорит о том, что набор правил отрабатывается в разные периоды:
в первом случае набор правил срабатывает на этапе проверки подзаголовков заголовка письма, отказ от приема письма действительный;
во втором случае рулсет проверяется на этапе разбора внутренних подзаголовков, то есть, фактически, тела письма, в лог пишется отказное сообщение, но все это не имеет значения для самого sendmail
("Internal headers in MIME parts do get checked but their results
are not acted on").
А вот и header письма, лог которого цитировался выше (кстати, обратите внимание, как отработала на этом спаме Спамооброна):
From MAILER-DAEMON Wed Jan 16 18:29:36 2008
Return-Path: < MAILER-DAEMON >
Received: from an.ru (relay.an.ru [213.142.209.142])
by mail.anrb.ru (8.14.2/8.14.2) with ESMTP id m0GDTVAR016777
for < consiglio@anrb.ru >; Wed, 16 Jan 2008 18:29:35 +0500
Received: by an.ru (Postfix)
id BD722578F5; Wed, 16 Jan 2008 16:21:32 +0300 (MSK)
Date: Wed, 16 Jan 2008 16:21:32 +0300 (MSK)
From: MAILER-DAEMON@an.ru (Mail Delivery System)
Subject: Undelivered Mail Returned to Sender
To: consiglio@anrb.ru
MIME-Version: 1.0
Content-Type: multipart/report; report-type=delivery-status;
boundary="9B4B0578DF.1200489692/an.ru"
Message-Id: < 20080116132132.BD722578F5@an.ru >
X-Antivirus: Dr.Web (R) for Mail Servers on mail host
X-Antivirus-Code: 100000
X-Spam-Ystatus: hits=-7.50
X-Spam-Flag: NO
X-Spam-Yversion: Spamooborona-2.1.0
Status: RO
This is a MIME-encapsulated message.
--9B4B0578DF.1200489692/an.ru
Content-Description: Notification
Content-Type: text/plain
This is the Postfix program at host an.ru.
I'm sorry to have to inform you that the message returned
below could not be delivered to one or more destinations.
For further assistance, please send mail to < postmaster >
If you do so, please include this problem report. You can
delete your own text from the message returned below.
The Postfix program
< ipnfifnu@olcon.murmansk.ru >: mail for olcon.murmansk.ru loops back to myself
--9B4B0578DF.1200489692/an.ru
Content-Description: Delivery error report
Content-Type: message/delivery-status
Reporting-MTA: dns; an.ru
Arrival-Date: Wed, 16 Jan 2008 16:21:32 +0300 (MSK)
Final-Recipient: rfc822; ipnfifnu@olcon.murmansk.ru
Action: failed
Status: 5.0.0
Diagnostic-Code: X-Postfix; mail for olcon.murmansk.ru loops back to myself
--9B4B0578DF.1200489692/an.ru
Content-Description: Undelivered Message
Content-Type: message/rfc822
Received: from localhost (localhost [127.0.0.1])
by relay.an.ru (Postfix) with ESMTP id 9B4B0578DF
for < ipnfifnu@olcon.murmansk.ru >; Wed, 16 Jan 2008 16:21:32 +0300 (MSK)
Received: from an.ru ([127.0.0.1])
by localhost (relay.an.ru [127.0.0.1]) (amavisd-new, port 10024) with ESMTP
id 70724-08 for < ipnfifnu@olcon.murmansk.ru >;
Wed, 16 Jan 2008 16:21:32 +0300 (MSK)
Received: from pne-smtpout2-sn1.fre.skanova.net (pne-smtpout2-sn1.fre.skanova.net [81.228.11.159])
by an.ru (Postfix) with ESMTP id 1EB9F578DA
for < ipnfifnu@olcon.murmansk.ru >; Wed, 16 Jan 2008 16:21:29 +0300 (MSK)
Received: from h195n2fls301o260.telia.com (81.230.233.195) by pne-smtpout2-sn1.fre.skanova.net (7.3.129)
id 478E02C700000E83 for ipnfifnu@olcon.murmansk.ru; Wed, 16 Jan 2008 14:21:05 +0100
Received: from [67.78.43.200] (HELO SWADLT)
by 81.230.233.195 (CommuniGate Pro SMTP 5.0.11)
with SMTP id 40127220 for ipnfifnu@olcon.murmansk.ru; Wed, 16 Jan 2008 14:21:14 +0100
Message-ID: < 002001c85842$abedbfb0$c3e9e651@h195n2fls301o260.telia.com >
From: "юБЮМЯ - я-оХРЕП" < ipnik@admiral.ru >
To: < ipnfifnu@olcon.murmansk.ru >
Subject: оКЕМЙЮ РЕПЛНСЯЮДНВМЮЪ
Date: Wed, 16 Jan 2008 14:21:14 +0100
25.10.2008. Разбираясь с особенностями маршрутизации в LOCAL_RULE_0,
попутно выяснила вот такую интересную и очень полезную деталь. Когда sendmail.cf применяет правила
к внутренним подзаголовкам (что, как было сказано раньше никак не отразится на статусе письма -
оно все равно будет доставлено),
макрос $&{deliveryMode} имеет значение "i", а когда разбираются заголовки обычные - "b".
На основании этого для оптимизации проверок можно переписать рулсеты, разбирающие подзаголовки (т.е. кроме Local_check_(relay|mail|rcpt)),
добавив проверку макроса $&{deliveryMode}: если его значение равно "b", то проверяем подзаголовок,
если же оно равно "i", то ничего не делаем (а зачем, ведь результат проверки никак не отразится на конечной доставке).
Кстати, то, что я написала ранее про место записи строки ruleset=CheckReceived: (перед from=) в случае обычного подзаголовка
и в случае внутреннего (после from, но перед to), распространяется и на макрос $&{deliveryMode}: если сделать его
вывод в лог с.п. syslog, то значение "b" будет записываться перед строкой from=, а "i" - после.
Насколько я понимаю, "i" означает interactive mode, то есть непосредственную доставку письма в локальный ящик.
Выходит, что на этом этапе наши рулсеты не играют никакой роли, хотя их результат отображается в логе.
Пример использования этого макроса в рулсете Check_Subject - здесь.
В CheckFrom - здесь. В CheckTo - здесь.
19. Почему иногда discard в /etc/mail/access не срабатывает?
/var/log/maillog
Apr 11 13:58:44 apache sendmail[4770]: m3B7wVX6004770: from=<santosn@one-n-udders.com>, size=2936, class=0,
nrcpts=1, msgid=<000601c89ba8$04e10af5$359b679e@baitgcyt>, proto=ESMTP, daemon=MTA,
relay=ppp-82-84-2-11.dialup.tiscali.it [82.84.2.11] (may be forged)
Apr 11 13:58:45 apache sendmail[4803]: m3B7wVX6004770: to=<maev@anrb.ru>, delay=00:00:10, xdelay=00:00:01,
mailer=smtp, pri=122936, relay=mail.anrb.ru. [212.193.134.2], dsn=5.0.0, stat=Service unavailable
Apr 11 13:58:45 apache sendmail[4803]: m3B7wVX6004770: m3B7wjX6004803: DSN: Service unavailable
Apr 11 13:58:46 apache sendmail[4803]: m3B7wjX6004803: ruleset=CheckReceived, arg1=from 82.84.2.11
(ppp-82-84-2-11.dialup.tiscali.it [82.84.2.11] (may be forged))\n\tby apache.anrb.ru (8.13.8/8.13.8) with ESMTP id
m3B7wVX6004770\n\tfor <maev@anrb.ru>; Fri, 11 Apr 2008 13:58:35 +0600, relay=localhost, reject=554 5.0.0 Bad Header
2: relaying denied.
Apr 11 13:58:47 apache sendmail[4803]: m3B7wjX6004803: to=<santosn@one-n-udders.com>, delay=00:00:02,
xdelay=00:00:02, mailer=esmtp, pri=34175, relay=mail4.ixwebhosting.com. [76.162.254.4], dsn=2.0.0, stat=Sent (ok
1207900349 qp 13973)
-------
Apr 11 13:59:53 apache sendmail[4894]: m3B7xcHH004894: from=<service@onevillage.net>, size=2932, class=0,
nrcpts=1, msgid=<000601c89ba9$03242aba$604ec294@byxfwcf>, proto=ESMTP, daemon=MTA,
relay=ppp-82-84-2-11.dialup.tiscali.it [82.84.2.11] (may be forged)
Apr 11 13:59:54 apache sendmail[4928]: m3B7xcHH004894: to=<mim@anrb.ru>, delay=00:00:11, xdelay=00:00:01,
mailer=smtp, pri=122932, relay=mail.anrb.ru. [212.193.134.2], dsn=5.0.0, stat=Service unavailable
Apr 11 13:59:54 apache sendmail[4928]: m3B7xcHH004894: m3B7xsHH004928: DSN: Service unavailable
Apr 11 13:59:58 apache sendmail[4928]: m3B7xsHH004928: ruleset=CheckReceived, arg1=from 82.84.2.11
(ppp-82-84-2-11.dialup.tiscali.it [82.84.2.11] (may be forged))\n\tby apache.anrb.ru (8.13.8/8.13.8) with ESMTP id
m3B7xcHH004894\n\tfor <mim@anrb.ru>; Fri, 11 Apr 2008 13:59:43 +0600, relay=localhost, reject=554 5.0.0 Bad Header
2: relaying denied.
Apr 11 13:59:59 apache sendmail[4928]: m3B7xsHH004928: to=<service@onevillage.net>, delay=00:00:05,
xdelay=00:00:05, mailer=esmtp, pri=34169, relay=mx0.123-reg.co.uk. [195.224.48.122], dsn=2.0.0, stat=Sent (OK
id=1JkE4q-0006UC-L0)
-------
Поясняю.
egrep tiscali.it /etc/mail/access дает
tiscali.it [TAB] DISCARD
И вот приходит письмо с релея ppp-82-84-2-11.dialup.tiscali.it.
Казалось бы, мой почтовый шлюз должен отказаться от этого письма. Но не тут-то было.
Он принимает сообщение и пытается его перенаправить на основной mx.
У основного mx-а /etc/mail/access симметричный со всеми шлюзами, но т.к. письмо приходит с моего же сервера,
то проверка на tiscali.it в /etc/mail/access не срабатывает. Но! Срабатывает проверка на tiscali в наборе
правил CheckReceived (проверка всех Received:, начиная со второго сверху).
Итог: основной mx отказывается от письма на этапе smtp-диалога. Почтовый шлюз получает отлуп и пытается доставить его отправителю.
На этот раз успешно. А ведь адрес отправителя мог оказаться поддельным. Но это другая история.
Нас же интересует одно, почему шлюз пропустил письмо?
Я считаю, что ответ кроется в "may be forged".
Как известно, sendmail пишет такое, когда прямое и обратное разрешение не соответствуют друг другу.
Стало быть, sendmail не считает возможным полагаться на недостоверные данные, а, значит, и делать discard в данном случае.
Вопрос на sendmail-конфе я задала, но ответа не получила
(все-таки английский у меня никудышный).
Поэтому пока останусь при своем мнении.
По крайней мере все имевшиеся до сих пор подобные случаи имели предупреждающие (may be forged) записи в логе.
28.04.2008. Сообщение от Владимира Васильева: "Если статус разрешения "may be forged",
то на вход рулесету check_relay подается IP $| IP, а не Hostname $| IP."
20. Почему иногда под одним номером процесса пишутся разные сообщения?
Mar 28 00:15:03 mail sendmail[9029]: m2RJEnMg009029: ruleset=check_mail, arg1=<sale@nv.com.ua>,
relay=visible-foe.volia.net [77.122.31.59], reject=554 5.0.0 Sorry,Your e-mail address looks like SPAM2N.If not,please
contact the postmaster@anrb.ru via another e-mail address.
Mar 28 00:15:11 mail sendmail[9029]: m2RJEnMg009029: from=<--rating@b-r.ru>, size=9371, class=0, nrcpts=1,
msgid=<01c8904f$ffe3e280$3b1f7a4d@--rating>, proto=ESMTP, daemon=MTA, relay=visible-foe.volia.net [77.122.31.59]
Mar 28 00:15:11 mail sendmail[9029]: m2RJEnMg009029: Milter change: header Subject: from
=?koi8-r?B?8NLB18Egyc7UxczMxcvU1cHM2M7PyiDTz8LT1NfFzs7P09TJLg==?= to [SPAM:: 13.20]
=?koi8-r?B?8NLB18Egyc7UxczMxcvU1cHM2M7PyiDTz8LT1NfFzs7P09TJLg==?=
Mar 28 00:15:11 mail sendmail[9029]: m2RJEnMg009029: Milter add: header: X-Spam-Ystatus: hits=13.20
Mar 28 00:15:11 mail sendmail[9029]: m2RJEnMg009029: Milter add: header: X-Spam-Flag: YES
Mar 28 00:15:11 mail sendmail[9029]: m2RJEnMg009029: Milter add: header: X-Spam-Yversion: Spamooborona-2.1.0
Mar 28 00:15:11 mail drweb-smf[9034]: [m2RJEnMg009029]: scan: the message(drweb.tmp.ShstoR) sent by --rating@b-r.ru
to z@anrb.ru is passed
Mar 28 00:15:11 mail sendmail[9029]: m2RJEnMg009029: Milter add: header: X-Antivirus: Dr.Web (R) for Mail Servers on
mail host
Mar 28 00:15:11 mail sendmail[9029]: m2RJEnMg009029: Milter add: header: X-Antivirus-Code: 100000
Mar 28 00:15:11 mail drweb-smf[9034]: [m2RJEnMg009029]: processing message from --rating@b-r.ru is over
Mar 28 00:15:11 mail sendmail[9386]: m2RJEnMg009029: to=<z@anrb.ru>, delay=00:00:04, xdelay=00:00:00,
mailer=local, pri=39733, dsn=2.0.0, stat=Sent
Смутило меня то, что сначала письму было отказано, а затем оно оказалось принято да еще с другим адресом отправителя!
Оказывается, это произошло за один smtp-сеанс.
Отправитель сначала указал в MAIL_FROM: sale@nv.com.ua и сразу получил отказ (я не принимаю почту с именем sale ), тогда, не закрывая текущей сессии,
он указал другой адрес (--rating@b-r.ru), и письмо было принято.
Вы можете сами проверить это, прителнетившись к своему почтовику и поменяв на ходу адреса отправителей.
Вы увидите, что письма разным получателям от разных отправителей запишутся в лог под одним номером.
Первоисточник - здесь.
21. Немного про опцию TryNullMXList
Насколько я поняла, эта опция используется на почтовых шлюзах, пересылающих почту на внутренние, скрытые за файрволлом,
сервера,
с тем чтобы избежать проблем с mx-записью.
В этом случае, mx-запись некоего домена указывает на почтовый шлюз, а он в свою очередь перенаправляет почту прямо по IP-адресу,
соотвествующему этому домену. Квалифицируется как неравноценная (худшая ) замена mailertable
(когда используюся квадратные скобки для отмены обращения к днс за mx-записью).
op.me:"
TryNullMXList [w]
If this system is the best (that is, lowest preference)
MX for a given host, its configuration rules should normally detect
this situation and treat that condition specially
by forwarding the mail to a UUCP feed, treating it as local,
or whatever.
However, in some cases (such as Internet firewalls)
you may want to try to connect directly to that host
as though it had no MX records at all.
Setting this option causes sendmail to try this.
The downside is that errors in your configuration
are likely to be diagnosed as "host unknown"
or "message timed out" instead of something more meaningful.
This option is disrecommended."
README:"
confTRY_NULL_MX_LIST TryNullMXList [False]
If this host is the best MX
for a host and other arrangements haven't been made, try connecting
to the host directly; normally this would be a config error."
Еще одно объяснение:
Neil W Rickert: " You firewall your network.
For all internal hosts, you set an MX record pointing to
your firewall gateway machine.
Mail comes to the gateway machine. When it lookups up the MX
records, it deletes the MX record pointing to itself and anything
with worse precedence. This leaves the MX list empty (null).
Because of the `TRY_NULL_MX_LIST' configuration, sendmail now
looks up the IP address and sends directly to that. Since it
is your gateway machine and has access to internal hosts,
this succeeds.
Without `TRY_NULL_MX_LIST' you would need to setup a mailertable
to work around what the MX records show. This eliminates that
step.
(Note: It is probably better to setup the mailertable anyway, for
more precise control).
Взаимосвязь с mailertable:
Why don't you make the machine running sendmail the lowest cost MX for
that name, and then set up a mailertable entry to forward mail for all
mail to that one specific machine to a mail relay of the same name, but
with square brackets around it (to force sendmail to skip the MX lookup
and instead send direct to the IP address, avoiding the problems introduce
by using TRY_NULL_MX_LIST). Alternatively, why not set up UUCP over
TCP/IP?
Ну и еще одно объяснение:
wrote:
> I want to receive all mail on my Sendmail host (Sparc, SunOS 4.1.4,
> Sendmail 8.7.4) but then have it send every piece of mail to an
> internal Lotus Notes mail gateway.
Try creating MX records. Set the Lotus Notes gateway as the lowest
cost MX for itself, and the Sun as a higher cost MX. Anything that gets
to the Sun for the Lotus Notes gateway will be automatically forwarded.
Of course, people outside your network will try to connect first to
the Lotus Notes gateway, and if they can't, then fall back to the Sun.
So, if there's no chance of them ever connecting to the Lotus Notes
gateway (because of a firewall), this is being rather rude.
In that case, you could set the Sun to be the lowest cost MX for the
Lotus Notes gateway and then set TRY_NULL_MX_LIST to true in the
sendmail.mc file for the Sun (and regenerate the sendmail.cf from it), but
this has other problems and is disrecommended.
The best solution would be to create a mailertable on the Sun that
explictly forwards everything for that gateway over to the machine of the
same name, but this time with square brackets added around the name to
keep sendmail from doing the MX lookup (which would get it into a loop).
22. Немного про "правильный" формат msgid & RFC
Пока только ссылка: http://www.linux.org.ru/view-message.jsp?msgid=2901433&lastmod=1215085193909
Пример конфига procmail (Johen Bern), который позволяет изменить msgid взят отсюда:
:0Hhf
* ^Message-Id:.*
| sed -e "/^[Mm]essage-[Ii][Dd]:/s/
(special chars might need add'l escaping ...) should do the trick.
20.10.2008. В моем постинге - неточность. Речь шла не об Outlook Express, а о Microsoft Office Outlook.
Вот как выглядит такой msgid:
Oct 23 08:07:01 mail sendmail[32227]: m9N26uno032227: syslog:MID:<005801c934b2$88199210$984cb630$@valev@oprst.edu>
Oct 23 08:07:01 mail sendmail[32227]: m9N26uno032227:
syslog:MID:Microsoft.Office.Outlook.12.0.-<005801c934b2$88199210$984cb630$@valev@oprst.edu>
А вот правила, которыми это все отслеживалось (в лог выводится мэйлер и msgid,
за все время контроля все имевшие место msgid с двумя @ исходили исключительно от Microsoft Office Outlook):
SCheckMailer
R$+ $:
$1 $| $&{MessageIdCheck}
R$+ $| < $+ @ $+ @ $+
> $:
$(syslog syslog:MID:$1-<$2@$3@$4> $)
SCheckMessageID
#Record the presence of the header MessageId
R$* $:
$(storage {MessageIdCheck} $@ $1 $) $1
R< $+ @ $+ @ $+
> $:
$(syslog syslog:MID:<$1@$2@$3> $)
24.10.2008.
Еще ссылка. Rewriting the Message-id Options.The standards require that the message-id be preserved, not rewritten
by an MTA.
...And you expected a Microsoft product to do the right thing? ;-)
23. Как увеличить число демонов на одном сервере(как снять ограничение на кол-во DAEMON_OPTIONS)
Per HEDELAND:
"Not only that, you have to change the source!:-) From sendmail/conf.h:
#define MAXDAEMONS 10 /* max number of ports to listen to */ "
24. Что означает ошибка "macro/class names too long" . А то, что количество макросов ограничено.
При написании решения по "взвешиванию" срабатываний в dnsbl, столкнулась
с ограничением на число макросов.
Мне хотелось вес каждого срабатывания определить в одном месте для удобства чтения и использования.
Но в силу этого ограничения, это сделать не удалось.
Дело в том, что данное решение тестировалось на рабочем конфиге, который уже использовал массу макросов,
а новое решение увеличило их кол-во до недопустимого значения, поэтому пришлось от макросов "для красоты" отказаться.
Claus Assmann: "You can take a look at the fine source code :-)
sendmail/conf.h
#define MAXMACROID 0377 /* max macro id number */
That's octal, hence 255 macros are possible.
It's split (sendmail/macro.c)
127 macros with multi-char names
127 macros with single-char names
(maybe off by one depending on whether 0 is possible...)
#define MAXMACNAMELEN 25 /* max macro name length */
There are too many macros with long names in use :-( You can have only 0377 - 0240.
25. Sendmail - MS Exchange - CRLFCRLF.
Периодически на форумах возникает вопрос о проблемах при передаче данных между Sendmail - MS Exchange.
[1]: Dec 21 2005,
Jose Marcio Martins da Cruz : RFC 2822 (and previous too) define that between the chunk of
headers and the message body shall be an empty line. Also, lines shall end with
CRLF not CR. You can't have a CR without a LF folowing it.
[2]:
[2.0]: Jan 2 2008.
Bill Colle: "Exchange misinterpreted a
: < CR >< CR >.< CR >< CR > in mid-body as a broken message end. `
:
: That's a ridiculous bug for any SMTP implementation to have, but is
: about par for the course for the imbeciles coding up Microsoft's
: faux-SMTP software... "
It isn't really news that Exchange is garbageware.
[3]: October 28, 2006.
CR/LF Characters Missing from End of Internet Text Body Parts. A logic error was preventing a final CR/LF sequence from being written to the end of the text body parts. Microsoft has confirmed this to be a problem in Microsoft Exchange Server version 5.0.
This fix has been posted to the following Internet
location.
[4]:
Microsoft ESMTP MAIL Service, Version: 6.0.3790.3959 ready at Thu, 15 Nov 2007.
When sending to an exchange server, the send transaction
times out just after the message is sent, like this (the example
belows takes upwards of ten minutes to complete).
Bill Cole: The '.' on a line by itself is the message terminator. After that, the
sending side is waiting for receiving side to respond.
> Whose fault is this?
Exchange or possibly something in between that is failing to transmit to
Exchange what sendmail is sending.
> How do I get around it?
Figure out why Exchange isn't sending any acknowledgment of the message.
In addition to some intermediary doing harm, another common problem is
filtering of mail done at that final point which is simply taking too
long.
[6]: Microsoft ESMTP MAIL Service, Version: 6.0.3790.3959.06-Май-08. По симптомам похоже на проблему с MTU path discovery.
ICMP по дороге не зарезаны все подряд без разбору?
[7]: Exchange2003.7 февраля 2008 г. Видимо domainprep помог.
[8]: ([8.0]) D. J. Bernstein.
You can't get mail through to msn.com and thousands of other systems around the Internet. Your mailer is violating 822bis section 2.3, which specifically prohibits all bare LFs.
What is a bare LF, anyway?
It is an ASCII linefeed (LF) character not preceded by an ASCII carriage-return (CR) character.
Every line in an Internet mail message is required to end with CR LF. The entire message ends with CR LF dot CR LF. 822bis specifically prohibits other uses of LF.
The mail clients discussed above are incorrectly ending lines with LF and, in most cases, ending the entire message with LF dot LF. That's not CR LF dot CR LF, so a server such as msn.com will sit there waiting for the rest of the message. After a while it'll give up and drop the connection. Your mail doesn't get through.
Some mail servers convert a bare LF into CR LF, and accept LF dot LF as the end of a mail message. This behavior is specifically prohibited by 821bis.
You can fix the problem by putting ``,E=\r\n'' at the end of Mether, Mtcp, or Msmtp in sendmail.cf.
[9]: Exim & Microsoft ESMTP MAIL Service, Version: 6.0.3790.1830 ready at Sat, 7 Oct 2006. Вот и нарыли что у прова прокс партизанский стоял (транспарент), попросили его отключить, все заработало....
[10]: Exchange 2003 SP2.15-03-2005. Нерешенное.
[11.] Самое подробное описание причины этой проблемы от BadWar.
Чтобы оно не затерялось, приведу его полностью.
" ...
В sendmail конец письма обозначается параметром E=\r\n , что значит "." или "." или "." .
Exchange заканчивает письмо другим параметром (когда пишет другому exchange'у) .
Последний код письма 2E 0D 0A, его надо перевести в ASCII, тогда вполне возможно будет получено решение.
Остальные письма уходят нормально, код завершения 2E 0A.
Получается, что между 2E и 0A он ставит ещё 0D, который ког sendmail не понимает.
Пока что на данный момент над этим бьюсь.
Очередная порция разгрёба.
2E - это "точка", которая ставится после оканчания письма
0D - arriage Return, возврат каретки. Во многих языках программирования этот символ, обозначаемый \r, можно использовать для возврата в начало строчки без перевода строки. В некоторых операционных системах этот же символ, обозначаемый Ctrl-M, ставится в конце каждой строчки текстового файла перед LF.
0A - Line Feed, перевод строки. Сейчас в конце каждой строчки текстового файла ставится либо этот символ, либо CR, либо и тот и другой (CR, затем LF), в зависимости от операционной системы. Во многих языках программирования обозначается \n и при выводе текста приводит к переводу строки.
Т.е. E=\r\n - это как раз таки и есть то, что нам надо (\r - для почтовиков построенных, не на базе SMTP (в данном случае exchange), и \n - почтовик, построенный на базе SMTP). Логически рассудить, то должно всё работать. Код окончания письма - 2E 0A - стандарт для SMTP MTA (точка и перевод строки) и 2E 0D 0A - стандарт для почтовиков, типа Exchange (точка, возврат каретки и перевод строки)
Получается когда exchange посылает письма через sendmail, он оканчивает письмо кодом 2E 0D 0A, и sendmail его нормально принимает и отправляет письма дальше, кроме моего случае с доменными письмами. Так же вся входящая почта принимается без проблем на sendmail и нормально перенаправляется на exchange (он понимает 2E 0A и 2E 0D 0A)
Терь вопрос, какого хр..а exchange при отправке письма внутри домена на другой exchange через sendmail неожиданно прерывает соединения. Как раз вот после ввода кода на окончания письма 2E 0D 0A выходит ошибка 421 4.4.1 collect: unexpected close on connection from exchange и письмо не уходит. Поолучается проблема в самом exchange и его надо ковырять, как бы не вышло, что данную проблему просто исправить не получится. Повторюсь Exchenge v.6.5.7638.2 SP2
Вообщем sendmail работает нормально, как надо, все свои функции выполняет. Просто exchange, видя smtp адрес, который находится в AD, пытает отправить письмо по X400 протоколу и причём нельзя это исправить. Я уже создал один единственный SMTP коннектор, который является smarthost'ом и напрявляет всю исходящую почту на sendmail. Естественно, та почта, что идёт в инет (yandex,mail and etc) он посылает по SMTP и всё гуд, а вот внутри домена по Х400, что ни есть гуд.
Честно говоря, я не знаю как заставить sendmail понимать Х400, и оставил бы sendmail, только для отправки почты во вне. Возможно ли копировать всю исходящую/входящую почту для контроля с помощью exchange? Хотя б копировать почту, которая уходит в домен(с которым у меня проблема), при этом что б он не копировал всю внутреннюю почту, тогда б я создал коннектор, который на данный домен отправлял почту напрямую...
Выяснилось, что exchange в письма делает вложения BINARYMIME
[RFC1830], похоже из-за этого sendmail его не передаёт, т.к. не понимает этого.
Нужно включить данную функцию в работу в sendmail. Получается включить
необходимо BINARYMIME и CHUNKING. Пока немогу найти в исходниках этого, что скомпилять.
Вот кстати какие команды отдаёт exchange
250-TURN
250-SIZE
250-ETRN
250-PIPELINING
250-DSN
250-ENHANCEDSTATUSCODES
250-8bitmime
250-BINARYMIME
250-CHUNKING
250-VRFY
250-X-EXPS GSSAPI NTLM LOGIN
250-X-EXPS=LOGIN
250-AUTH GSSAPI NTLM LOGIN
250-AUTH=LOGIN
250-X-LINK2STATE
250-XEXCH50
250 OK
А вот sendmail
250-ENHANCEDSTATUSCODES
250-PIPELINING
250-8BITMIME
250-SIZE
250-DSN
250-DELIVERBY
250 HELP
Когда exchange, думая, что посылает письмо на другой exchange, он посылает письмо с вложением по стандарту RFC 1830 (binarymime), а данный стандарт sendmail не поддерживает, но разработчики сказали, что в будущем собираются реализовать данную возможность
(BODY=BINARYMIME might be an option in the future.).
..."
26. Where does sendmail get this info from? Particularly (node name) and (subdomain name).
Навеяно вот этим обсуждением, ничем общественно полезным не закончившимся (к моему великому сожалению).
Я говорю "к сожалению", потому что я не люблю НЕПОНЯТНЫЕ проблемы sendmail'a
(ИМХО, первопричина таких ситуаций - сам админ), некорректные постановки вопроса,
неадекватные ответы вопрошающих и, самое главное, жаль бесполезно потраченного времени.
Per Hedeland:
Sendmail 8.9.1 gets it through starting with gethostname(), and if that
doesn't contain at least one '.', hunting through the name services
specified for "hosts" trying to find a name that does.
Assuming it finds
one, it uses the part before the first '.' for (node name) (and for
(short domain name)), and the part after it for (subdomain name).
echo|sendmail -bt -d0
Version 8.14.2
Compiled with: DNSMAP LOG MAP_REGEX MATCHGECOS MILTER MIME7TO8 MIME8TO7
NAMED_BIND
NETINET NETUNIX NEWDB PIPELINING SASLv2 SCANF USERDB
XDEBUG
============ SYSTEM IDENTITY (after readcf) ============
(short domain name) $w = mail
(canonical domain name) $j = mail.anrb.ru
(subdomain name) $m = anrb.ru
(node name) $k = mail
========================================================
ADDRESS TEST MODE (ruleset 3 NOT automatically invoked)
Enter <ruleset> <address>
uname -n
> > Linux mail
hostname
mail
hostname -f
mail.anrb.ru
А я до сих пор ломаю голову на тем, что надо было ТАКОГО сделать с системой и sendmail'ом,
чтобы домен первого уровня вдруг начал дублироваться ...
27. Как запустить 2 sendmailа на разных портах и с разными конфигами?
12-27.11.2008. Что-то ничто не давалось так тяжело, как этот вопрос.
"Быть или не быть", "делить или не делить" - так и не пришла к однозначному решению.
Может, я здесь что-то накрутила, напутала, усложнила ... ?
Ваши мысли, комментарии, замечания, личный опыт будут очень кстати.
Итак, хотя sendmail-гуру Per Hedeland сказал, что Sendmail - это почтовый роутер, и любая почта для него является и
входящей и исходящей, все же для постмастера направление движения почты
при определении оптимальной конфигурации почтового сервера имеет большое значение.
Например, мой почтовик почту от моих юзеров и от внешних отправителей
для моих юзеров и для внешних получателей
обрабатывает по разному.
То есть мало того, что для меня имеет значение, входящая
это почта или исходящая, еще имеет значение, кто отправитель/получатель - локальный или внешний.
Это выливается в необходимость обходить некоторые проверки в sendmail.cf с помощью
контроля за IP адресом отправителя и имевшей (или не имевшей) место smtp-авторизацией.
1. В Local_check_mail, CheckFrom, check_eoh я делаю обходы
многочисленных проверок HELO, IP релеев, доменных имен релеев, конвертных и заголовочных
e-mail с помощью таких правил:
#Do not check if it is local ip-address
R$* $: < $&{client_addr} >
R< $=R $* > $@ OK
#Do not check if it is smtp-authenticated mail
R$* $: < $&{auth_authen} >
R<$+> $@ OK
То есть почта от моих юзеров дальнейшим проверкам в этих рулсетах подвергаться не должна.
2. У меня есть три локальные spam-check группы, для которых делаются некоторые
"небесспорные" проверки, а остальные юзеры этой экзекуции не подвергаются, и вот эта проверка
2 остальные, ей подобные, включены почти в каждый Check*:
R$* $: <$&{Spam_Check}>
R<0> $@ OK
Эта проверка лишняя, когда получатель внешний.
3.1. В-третьих, я еще веду список "белых" адресов внешних отправителей. А это значит, что
и эта проверка включена в каждый Check*:
R$* $: $&<{WL_mail_from}>
R<1> $@ OK
Эта проверка не нужна, когда отправитель локальный.
3.2. Для внешних отправителей, набравшихся наглости подставить в поле from: административные адреса anrb.ru,
сработают свои блокировки. Казалось бы, если разделить внешнюю и внутреннюю почту, от этой проверки можно
вовсе отказаться, просто блокируя на первом сервере любую внешнюю почту, содержащую домен anrb.ru в access:
From:anrb.ru [TAB] REJECT
Но не тут-то было: тогда законные адм-отправители не смогут писать своим же пользователям:
от них-то почта уйдет спокойно, а вот через первый сервер она не пройдет.
Тогда на первом сервере нужно будет оставить проверки, а на втором их просто не делать.
3.3. Приходится ограждать внутренние закрытые списки рассылок от внешней почты.
И тут, казалось бы, можно избежать этого, если разделить внешнюю и внутреннюю почту, и добавив в access
To: list@anrb.ru [TAB] REJECT
Но как и в предыдущем случае, это не пройдет.
Во всех 5 примерах совершаются "лишние" операции, а их максимальное количество за день равно
12N + 56*K + 5*M + 4*L
где N - общее число соединений за день, дошедших до check_mail.
Почему не число писем? Да потому, что какое-то письмо может быть отвергнуто на одном из этапов, а проверочка-то может успеть исполниться.
K - количество исходящих писем, M - число писем для внутренних рассылок, L - число писем с адм-адресов.
4. Я ограничиваю общее количество соединений за определенный промежуток времени
и количество одновременных соединений с одного хоста, а также использую dnsbl.
Для первых двух ограничений используются строки в /etc/mail/access
ClientRate:1.2.3.4.0 [TAB] 0
ClientRate: [TAB] 10
ClientConn:1.2.3.0 [TAB] 4
СlientConn: [TAB] 10
Для "обходов" dnsbl:
CONNECT:1.2.3.4 OK
Здесь локальной сети 1.2.3.4 разрешается обращаться к почтовику без ограничений,
а всем остальным - только 10 соединений в минуту и не более 4 одновременных соединений.
Количество "лишних" проверок будет равно кол-ву соединений, устанавливаемых из моей локальной сети.
Хотя здесь есть такая тонкость: если IP из локальной сети
указан в access c тэгом CONNECT: и значением OK или RELAY,
то он довольно быстро выскочит из check_relay,
миновав проверки в DNSBL, RateConnection & ClientConnection.
А вот если релеинг локальным юзерам разрешен только через smtp-авторизацию,
то избавиться от вышеуказанных проверок можно только с помощью FEATURE(delay_checks).
А я очень не люблю эту фичу: она меняет порядок исполнения рулсетов так,
что check_mail & check_relay будут исполняться после check_rcpt.
А большинство отлупов на моей системе
происходит именно на этапах check_relay & check_mail.
И затягивать отказ на 1-2 рулсета не хотелось бы
(передо мной ведь в данном случае стоит задача оптимизации, а обходить остальные рулсеты,
если сработала блокировка в предыдущем, я теперь умею.).
5.Не забываем про FEATURE(`greet_pause'):
как правило, GreetPause для локальной сети устанавливается в 0,
а это равносильно тому, как если бы эта фича вовсе не использовалась
для пользователей из локальной сети
6. Когда DDOS-ят почтовый сервер, и он перестает откликаться на запросы,
то почту отправить не могут также все: локальные юзеры получают в этом случае
"Could not connect to server". Хотя по большому счету 2 sendmail'a на одном компе здесь не помогут:
во-первых, пожирание ресурсов системы при DDOS скажется и на сервисе, слушающем 587 порт,
во-вторых, ничто и никто не помешает заddos-ить (параллельно или нет) и MSA.
Поэтому здесь поможет, и то частично, разнесение внешней и локальной почты не только по разным sendmail'ам, но
и по разным компам.
7.Вот список параметров, которые могут различаться для локальных и внешних отправителей.
define(`confSTATUS_FILE',`/etc/mail/mailstat')dnl - хотя на эти данные полагаться нельзя.
define(`confMAX_MESSAGE_SIZE', `125000000')dnl
define(`confMAX_RCPTS_PER_MESSAGE', `100')dnl
define(`confMAX_HOP', `20')dnl
Возможно также понадобится настроить таймауты индивидуально для входящей и исходящей почты:
define(`confTO_INITIAL', `2m')dnl
define(`confTO_CONNECT', `2m')dnl
define(`confTO_HELO', `2m')dnl
define(`confTO_MAIL', `2m')dnl
define(`confTO_RCPT', `2m')dnl
define(`confTO_DATAINIT', `5m')dnl
define(`confTO_DATABLOCK', `5m')dnl
define(`confTO_DATAFINAL', `5m')dnl
define(`confTO_COMMAND', `5m')dnl - вот этот параметр, а вернее его значение по умолчанию (30m) традиционно
вызывает нарекания. Если sendmail на 25п. должен ждать следующей команды от передающего сервера в течение 30 минут,
то представьте себе, сколько одновременных соединений это может вызвать. Есть предположение, что большой timeout
этой команды является одной из причин проблемы с созданием тредов.
А для MSA можно установить значение и побольше 5 минут.
define(`confTO_QUEUERETURN', `1d')dnl
и другие таймауты.
8. Для исходящей почты могут вовсе не понадобится:
define(`confCONNECTION_RATE_WINDOW_SIZE',`60')
FEATURE(`smrsh')
FEATURE(`access_db')
FEATURE(`blacklist_recipients')
FEATURE(`greet_pause')
FEATURE(ratecontrol)
FEATURE(conncontrol)
FEATURE(dnsbl)
9. NB! Есть возможность задать некоторые индивидуальные для демона значения прямо в опции DAEMON_OPTIONS:
RELEASE_NOTES: "... New suboptions for DaemonPortOptions to set them individually per daemon socket:
DeliveryMode DeliveryMode
refuseLA RefuseLA
delayLA DelayLA
queueLA QueueLA
children MaxDaemonChildren ..."
В стандартной конфигурации эти значения задаются опциями:
define(`confMAX_DAEMON_CHILDREN', `320')dnl
define(`confQUEUE_LA', `140')dnl
define(`confREFUSE_LA', `220')dnl
define(`confDELAY_LA', `220')dnl
То есть в случае с 2 демонами sendmail можно задать индивидуальные значения для вышеуказанных параметров прямо в строках,
DAEMON_OPTIONS(`Port=smtp, Name=MTA')
DAEMON_OPTIONS(`Port=587, Name=MSA, M=E')
2 конфига здесь не понадобятся.
И кстати, OP.ME: "...Change the default values of QueueLA from 8 to (8 * numproc) and
RefuseLA from 12 to (12 * numproc) where numproc is the
number of processors online on the system (if that can be
determined). For single processor machines, this change
has no effect ..."
Итак, приведено достаточно примеров, когда для локальной почты требуется упрощенный либо
другой вариант sendmail.cf & access. У меня "обходы" правил осуществляются прямо в конфиге
(1-3 пункты) или с помощью дополнительных строк в access (4-5).
А вот опции из п.7 поделить никак нельзя.
А что, если для исходящей локальной почты использовать отдельный демон с отдельным конфигом?
Как? Известно, что по умолчанию один sendmail слушает 2 порта: 25(smtp) и 587(submission).
Раз это один процесс, то и конфиг, соответственно, sendmail использует один и тот же.
То есть нам этот вариант не подходит.
=== Небольшое отступление. Почему-то большинство предпочитает отказаться от 587 порта с/п FEATURE(no_default_msa).
Цитаты про sendmail на 587 выложены здесь.
Помимо разбора синтаксиса e-mail адресов, заданных локальными отправителями
(подозреваю, что именно эта функция подразумевается под термином submission, т.е.
представление на рассмотрение или предпроверка с целью освободить 25 порт от
"работы над синтаксическими ошибками"),
такое разделение позволяет блокировать исходящий от нас неперсонифицированный
(т.е отправленный с IP, прописанного в access & relay-domains) спам:
если велеть sendmail'у, запущенному на 587 порту с Modifiers=a
("... DaemonPortOptions (DAEMON_OPTIONS())
has now suboptions (called modifiers), one of which is `a'. This tells the daemon to require authentication for all connections to it...
...Requiring SMTP AUTH for all mails is in general a bad idea, because then you cannot receive mails from other users (since the cannot authenticate). So you must do this only on a server that is solely intended for your own users to send mail, not for a publically advertised (via MX records) server..."
),
требовать от отправителей обязательную smtp-аутентификацию,
то установить источник спама не по IP, а по использованному логину не составит труда.
Т.е. благодаря авторизации именно по имени , а не
по IP-адресу, мы легко сможем установить, кто виновник.
Почему это нельзя сделать по IP? В силу "особенностей национального местного провайдерства"
я очень долго не могла понять, почему считается, что нельзя с точностью до персоны выяснить,
кто разослал спам через dialup. Теперь и я с этим согласна. Больше ничего сказать не могу.
Почему нельзя такое же провернуть с 25 портом, не заморачиваясь с 2 sendmail'ами?
Да потому, что тогда sendmail начнет требовать авторизацию не только от локальных юзеров,
но и от внешних почтовых серверов, которые хотят передать нам почту. А это уже лишнее.
Внешняя почта должна приниматься без авторизации.
(Кстати, меня однажды спрашивали,
"как сделать так, чтобы почта от локального клиента локальному тоже требовала smtp-авторизацию".
Теперь догадываюсь, что Андрей Лаврентьев имел в виду решение именно через sendmail 587 и обязательную авторизацию.)
Локальным клиентам в этой ситуации предписывается настроить на почтовом клиенте
smtp-авторизацию и указать 587 порт для связи с исходящим сервером. При этом 587 открыт всему
миру, и пользователь может релеить почту через родной сервер и за пределами локальной сети
в том числе. А входящей почты для 587 порта от MTA не может быть по определению:
почтовый сервер-клиент умеет соединяться только с 25 портом почтового сервера-демона.
А 25 порт на сервере открывается только снаружи, то есть он доступен только внешним отправителям
и недоступен или всем локальным клиентам, или только диалапщикам (на наше усмотрение).
Кстати, теперь уже можно закрыть 25 порт вообще для всей локальной сети. Это позволит не
выпускать за пределы локальной сети спам, рассылаемый спам-ботами с зараженных клиентских компов через
сторонние почтовые сервера.
25 порт таким образом служит только для внешней входящей почты, то есть предназначен для конечной доставки (LDA).
MTA_внешний->MTA_наш(MX)->LDA
587 - только для исходящей локальной почты, для релеинга в том числе.
MUA->MSA->MTA_внешний или наш.
Что будет если локальный клиент отправит письмо локальному же клиенту?
MUA->MSA->MTA(наш_MX)->LDA.
(?) Значит, если закрывать 25 порт от локальной сети на хосте с sendmail'ами по схеме "сначала все запретить, потом добавить разрешения",
то надо оставить возможность "общения" между 25 и 587 портами.
Отступление окончено. ===
Итак, а все-таки, что если на этот 587 порт, и без того предназначенный только для локальных клиентов,
повесить отдельный sendmail-процесс. Ес-но у него будет свой конфиг, а именно из-за этого все и затевалось,
я предполагаю, что в нем не будет
раздела LOCAL_CONFIG вовсе, и скорее всего не будет множества FEATURE, свой access (а скорее всего он и не понадобится).
Тот же sendmail, который останется на 25 порту, получит "облегченный" конфиг без обходов локальной почты
и облегченный access без тех же обходов.
Мои нынешние sendmail.cf & access настолько загруженные (egrep -cv "#|^$" sendmail.mc~500), что быстро ориентироваться
в них стало затруднительно.
Упрощение конфига и access должно, во-первых, оптимизировать исполнение многочисленных antispam-проверок для внешних отправителей,
исключить антиспам-проверки для локальных отправителей (ес-но, при условии, что от моих юзеров спам не идет),
а во-вторых, установить оптимальные именно для исходящей локальной почты параметры.
NB!!! Ну а теперь самое интересное: а что если спам и вирусы из локальной сети все-таки идут, причем прямо через 587 порт?
Пока я еще обнаружу "вредителя" (ну нет меня в природе на данный момент, например)!
Если бы sendmail
был запущен один, пусть и на 2 портах, этим "добром" занимались бы Drweb+VadeRetro.
А теперь, когда демона 2 и конфига 2, как быть с фильтрами? Ведь дело происходит на одном компе!
Можно ли просто указать 2 разных сокета в определении 2 фильтров? А ведь демон наверняка будет общаться только с одним?
И как быть с ключевым файлом? Может ли он обслуживать два сервера на одном IP?
Или тогда нужно запускать Drweb+VadeRetro на отдельном компе, и гонять к нему запросы от обоих демонов?
Вот если возможен только последний вариант, то все-все-все вышесказанное про необходимость
2 демонов с разными конфигами меркнет. ИМХО.
Ответ от тп DrWEb меня порадовал:
"А что мешает эту строку
INPUT_MAIL_FILTER(`drweb-filter',`S=local:/var/drweb/ipc/drweb-milter.sock, T=C:10m;S:8m;R:8m;E:10m')
прописать для обоих sendmail`ов? drweb-milter должен работать прекрасно с 2 sendmail`ами."
Ссылки по теме:
[1]. можно (как) только для MSA отключить проверку входящих соединений в DNSBL ?
[2].
I'm running two sendmails on single Linux machine without
problem. Including TLS between them. :-)
Just bound them on different interfaces:
FEATURE(`no_default_msa')dnl
DAEMON_OPTIONS(`Addr=192.168.1.1, Name=MTA')
DAEMON_OPTIONS(`Port=587, Addr=192.168.1.1, Name=MSA, M=E')
and for other sendmail and his cf file use your other IP.
This is path-related part of site.config.m4 that I'm using for
building other sendmail:
define(`confMBINDIR', `\"/opt/sendmail/bin\"')dnl
define(`confEBINDIR', `\"/opt/sendmail/bin\"')dnl
define(`confUBINDIR', `\"/opt/sendmail/bin\"')dnl
define(`confSHAREDLIBDIR', `\"/opt/sendmail/lib\"')dnl
define(`confHFDIR', `\"/opt/sendmail/mail\"')dnl
define(`confSTDIR', `\"/opt/sendmail/mail\"')dnl
APPENDDEF(`confENVDEF', `-D_PATH_SENDMAILCF=\"/opt/sendmail/mail/sendmail.cf\"')dnl
APPENDDEF(`confENVDEF', `-D_PATH_SENDMAILPID=\"/opt/sendmail/mail/sendmail.pid\"')dnl
APPENDDEF(`confENVDEF', `-D_PATH_SENDMAIL=\"/opt/sendmail/mail/sendmail.cf\"')dnl
Of course, you will have to redefine QueueDir path, hash/dbm map paths
and so on... in OtherSendmail.mc, for example:
define(`ALIAS_FILE', `/opt/sendmail/mail/aliases')dnl
define(`QUEUE_DIR', `/opt/sendmail/mqueue')dnl
define(`STATUS_FILE', `/opt/sendmail/mail/statistics')dnl
define(`confCR_FILE', `/opt/sendmail/mail/relay-domains')dnl
define(`confCW_FILE', `/opt/sendmail/mail/local-host-names')dnl
define(`confCT_FILE', `/opt/sendmail/mail/trusted-users')dnl
and so on... It takes some time when you doing this first time, but
it's not so hard...
[3]. I wish to have sendmail listening on Port 25 , pass to anti anti-virus app
which passes back to sendmail on another port
[4].
Standard *initial* suggestion is to use LDAP based per account email
routing: http://www.sendmail.org/m4/ldap_routing.html. It would allow you to easily add additional MX servers, additional
mailbox servers, additional (backup) LDAP servers.
[5].You have to have two _different_ names/domains for the two mail servers.
One name _can_ be a sub-domain of the other
[6].
Как избежать ошибки "config error: mail loops back to me (MX problem?)", которая может возникнуть при общении этих 2 sendmail'Ов:
Neil W Rickert: "If you can give the two sendmails different values for $j, that would
solve the problem. Alternatively, define a separate mailer for
sending between them, and set the "k" flag in the mailer flags (the
"F=" string). "
op.me (5.4. M -- Define Mailer):
"k Normally when sendmail connects to a host via SMTP,
it checks to make sure that this isn't accidently the same host name
as might happen if sendmail is misconfigured or if a long-haul network interface is set in loopback mode.
This flag disables the loopback check.
It should only be used under very unusual circumstances ..."
[7].
Now, there *is* a use for requiring SMTP AUTH for an MSA on port 587, or on
port 25 *if the server is used only for relaying, not final delivery*. Are
you configuring an MSA or relay-only server? Note that this still will not
prevent users from delivering directly to local users on the destination
(MX) server.
[8].How to turn off SMTP AUTH Options
You can:
- disable SMTP AUTH per daemon (DaemonPortOptions, M=A)
- disable SMTP AUTH per connection (Srv_Features, A)
- edit the source code.
[9].DaemonPortOptions (DAEMON_OPTIONS())
has now suboptions (called modifiers), one of which is `a'.
This tells the daemon to require authentication for all connections to it.
Requiring SMTP AUTH for all mails is in general a bad idea, because then you cannot receive mails from other users (since the cannot authenticate). So you must do this only on a server
that is solely intended for your own users to send mail,
not for a publically advertised (via MX records) server.
... Per default, relaying is allowed for any user who authenticated via a trusted mechanism, i.e.,
one that is defined via TRUST_AUTH_MECH(`list of mechanisms') ...
... The ruleset trust_auth is used to decide whether the client's authentication identifier (authid) is trusted to act as
(proxy for) the requested authorization identity (userid).
The provided rules allow authid to act for userid if both are identical and they disallow it
if the authentication failed.
The ruleset Local_trust_auth can be used to provide further tests.
As usual, it can either return the error mailer ($# error) to disallow proxying or $# OK to allow proxying...
[10].Если все же нужно какой-то IP пропускать без авторизации:
Srv_Features:1.2.3.4 A S # dont do SMTP AUTH and TLS
Connect:127.0.0.1 RELAY
Srv_Features:127.0.0.1 A
[12]. Именно отсюда - 8.12 и включение отдельного MSP. Как один из
вариантов.
Конструкция из двух машин, кстати, не нужна была никогда - никто не мешает запустить два sendmail на одной машине. (У меня в
хозяйстве есть машина, где их три на разных группах IP. И ничего уникального тут нет.)
[13].
Is possible to set different DeliveryMode for MSA without using separate sendmail daemon?
"... enable _FFR_DM_PER_DAEMON (8.13.4 and better)."
28. Встроенные анти-DOS средства sendmail.
Claus Assmann:
See sendmail/srvrsmtp.c, look for _FFR_NO_PIPE
and MAXBADCOMMANDS.
The former can delay the spammer (if you fix the code a bit...)
the latter can help you to drop the connection.
op.me:
4.6. Measures against Denial of Service Attacks
Sendmail has some built-in measures against sim-
ple denial of service (DoS) attacks. The SMTP server
by default slows down if too many bad commands are
issued or if some commands are repeated too often
within a session. Details can be found in the source
file sendmail/srvrsmtp.c by looking for the macro
definitions of MAXBADCOMMANDS, MAXNOOPCOMMANDS, MAXHE-
LOCOMMANDS, MAXVRFYCOMMANDS, and MAXETRNCOMMANDS. If
an SMTP command is issued more often than the corre-
sponding MAXcmdCOMMANDS value, then the response is
delayed exponentially, starting with a sleep time of
one second, up to a maximum of four minutes (as
defined by MAXTIMEOUT). If the option MaxDaemonChil-
dren is set to a value greater than zero, then this
could make a DoS attack even worse since it keeps a
connection open longer than necessary. Therefore a
connection is terminated with a 421 SMTP reply code if
the number of commands exceeds the limit by a factor
of two and MAXBADCOMMANDS is set to a value greater
than zero (the default is 25).
29. Как из op.me получить op.txt
Выбирайте:
nroff -me op.me | ul -t dumb > op.txt
cat op.me | neqn | nroff -me | ul -t dumb
$ make ROFF_CMD=nroff op.txt
rm -f op.txt
pic -C op.me | eqn -C -Tascii | nroff -Tascii -me | ul -t dumb > op.txt
neqn -C -Tascii op.me | nroff -me | ul -t dumb > op.txt
neqn -C -Tascii8 op.me | nroff -me | ul -t dumb > op.txt - я пользуюсь именнно этим
If you don't have a PostScript viewer (ghostscript), then take
a look at
http://www.sendmail.org/~ca/email/doc8.VERSION/op.html
http://www.sendmail.org/~ca/email/doc8.VERSION/op.gz
(replace version with 9, 10, 11, or 12), the latter is
the plain text version (gzip'ed).
nroff -me -Tascii op.me>op.txt
groff -me -Tascii op.me>op.txt
30. Почему нельзя сразу отвергнуть письмо, если его размер
превышает допустимый
Пока только ссылка.
Комментарии позже.
04.12.2008.
Опция define(`confMAX_MESSAGE_SIZE', `5100000') задает макcимальный размер
письма,
которое может быть доставлено получателю через наш почтовик.
Это ограничение имеет отношение именно к конечной доставке или недоставке
письма получателю,
а не к принятию/отказу почтового сервера.
То есть вне зависимости от того, превышает размер письма допустимый или
нет,
в письмо сначала принимается целиком (во время приема письма в
/var/spool/mail/ появляется
файл d1A2B3C4D5E, размер которого постепенно растет до размера принимаемого
письма),
затем определяется размер этого письма, и только потом принимается решение -
принимать или отказать.
Если вы выставили ограничение в 5Mb, а вам отправили, скажем, письмо
весом в 20 Mb,
то сначала ваш почтовик примет это письмо, а затем откажет ему.
Получается почти как в мультике "Каникулы в Простаквашино".
Почтальон ежедневно приносил посылку дяде Федору, но поскольку у того не
было документов, уносил ее.
При этом он произносил что-то вроде:"Раз посылка пришла - я ее должен
принЕсть. А раз докУментов нет - должен унЕсть."
Наш почтовик - это и есть почтальон Печкин, проделывающий бесполезную,
заведомо (для нас) ненужную работу:
"Раз письмо пришло - я его должен сначала принять, а раз размер большой -
должен отказать."
И все-таки, есть ли возможность отказать такому письму сразу?
"... If the client (correctly) advertises the size on the MAIL command
as
specified in the SIZE SMTP extension, sendmail will reject the message
at that point. If the client doesn't advertise it, sendmail has no
choice but to receive the whole thing (it doesn't write it to disk
though) - there is no provision in the SMTP protocol for aborting the
DATA phase mid-stream. (Closing the connection would be treated as a
connection problem and result in a retry by a correctly functioning SMTP
client.) ..."
Что в переводе звучит ~ так: Если почтовый клиент объявил размер
отправляемого им письма в команде MAIL
как это определено в SIZE SMTP extension, то sendmail отвергнет это письмо.
Если MUA этого не сделал, то sendmail'у не остается ничего кроме как принять
письмо целиком
(хотя он не запишет это письмо на диск) (вот с этим я не согласна:
достаточно посмотреть
в /var/spool/mail ). SMTP протокол не предоставляет возможность
обрыва соединения
в середине фазы DATA.
AFAIR MTA may send in advance "next command reply" and break connection
but Per is right that many valid MTA will simply retry when it is
issued in middle of HUGE message body transmission.
MTA может выдать заранее "ответ на следующую команду" и оборвать
соединение, но Per
прав в том, что множество нормальных MTA просто повторят попытку передачи
сообщения,
если обрыв случится в середине процесса передачи тела письма большого
размера.
Sendmail will reject the message if it is bigger than the specified size
regardless of how the client behaves - only that without SIZE
advertisement from the client, it can't be rejected until the body has
been received.
Sendmail отвергнет письмо если его размер больше определенного вами
значения
вне зависимости от поведения MUA (т.е. объявил он размер сообщения или нет).
Разница только в том, что без предварительно объявленного MUA параметра SIZE
sendmail не сможет отвергнуть письмо пока не примет тело письма целиком.
Далее еще на 2 листах ребята обсуждают 2 забавных обстоятельства,
которые , думаю, полезно будет знать и нам:
1. Cisco router, если его поместить между sendmail и MUA, может
блокировать
ESMTP banner и команду клиента EHLO, вынуждая клиента использовать HELO и
отказаться от
SMTP extensions.
2. Outlook Express & Microsoft Outlook не поддерживают ESMTP.
Они не устанавливают размер сообщения перед тем, как его послать, и не
запрашивают
у сервера, какой размер сообщения он принимает. Они просто посылают письмо и
смотрят,
что будет дальше.
При некоторых невыясненных обстоятельствах Outlook воспринимает ответ 550
как временную ошибку
и повторяет отправку большого сообщения. Юзеры не видят сообщения об ошибке
на экране
и не знают, что отправка сообщения не была успешной,
или что это сообщение посылается бесконечное число раз.
При этом письмо остается в очереди Outlook Express, и MUA повторяет попытки
отправки этого
письма до тех пор, пока не удалишь его из "outbox mail".
Что при этом делается с локальной сетью - догадайтесь сами ...
Продемонстируем п.2. Для этого используем макрос $&{msg_size}.
SLocal_check_mail
R$* $:
$(syslog syslog:mail:msg_size: $&{msg_size} $) $1
Scheck_compat
R$* $:
$(syslog syslog:compat:msg_size: $&{msg_size} $)
HX-Mailer:
$>+CheckMailer
SCheckMailer
R$* $:
$(syslog syslog:X-M: $1 $) $1
Dec 5 16:29:13 mail sendmail[9882]: mB5BT9G2009882: syslog:mail:msg_size:7651
Dec 5 16:29:13 mail sendmail[9882]: mB5BT9G2009882: syslog:X-M:The.Bat!
Dec 5 16:29:14 mail sendmail[9882]: mB5BT9G2009882: from=<abcdef123@yandex.ru>, size=7480, class=0, nrcpts=1,
msgid=<161145888.20081205161627@yandex.ru>, bodytype=8BITMIME, proto=ESMTP, daemon=MTA, relay=forwards4.yandex.ru
[77.88.32.20]
Dec 5 16:29:14 mail sendmail[9891]: mB5BT9G2009882: syslog:compat:msg_size:7912
Dec 5 16:29:14 mail sendmail[9891]: mB5BT9G2009882: to=<terrapin@bvkexpo.ru>, delay=00:00:01, xdelay=00:00:00,
mailer=local, pri=37912, dsn=2.0.0, stat=Sent
Dec 5 18:26:00 mail sendmail[25803]: mB5DPvTw025803: syslog:mail:msg_size:
Dec 5 18:26:00 mail sendmail[25803]: mB5DPvTw025803: syslog:X-M:Microsoft.Office.Outlook.11
Dec 5 18:26:02 mail sendmail[25803]: mB5DPvTw025803: from=<anir@otherdomain.ru>, size=983936, class=0,
nrcpts=1, msgid=<000001c956dc$590a9770$5a01890a@MM>, proto=SMTP, daemon=MTA, relay=ms.otherdomain.ru [195.34.193.140]
Dec 5 18:26:03 mail sendmail[26044]: mB5DPvTw025803: syslog:compat:msg_size:984358
Dec 5 18:26:03 mail sendmail[26044]: mB5DPvTw025803: to=<gatling@bvkexpo.ru>, delay=00:00:03, xdelay=00:00:00,
mailer=local, pri=1014358, dsn=2.0.0, stat=Sent
Dec 5 17:21:54 mail sendmail[15621]: mB5CLo8D015621: syslog:mail:msg_size:
Dec 5 17:21:55 mail sendmail[15621]: mB5CLo8D015621: syslog:X-M:Microsoft.Outlook.Express.6.00.2900.2869
Dec 5 17:21:55 mail sendmail[15621]: mB5CLo8D015621: from=<curtis@verilux.net>, size=9496, class=0, nrcpts=1,
msgid=<01c956d3$54f1f100$6c822ecf@curtis>, proto=ESMTP, daemon=MTA, relay=hn.kd.ny.adsl [125.47.8.198] (may be
forged)
Dec 5 17:21:55 mail sendmail[15670]: mB5CLo8D015621: syslog:compat:msg_size:9952
Dec 5 17:21:55 mail sendmail[15670]: mB5CLo8D015621: to=<consiglio@anrb.ru>, delay=00:00:01, xdelay=00:00:00,
mailer=local, pri=39952, dsn=2.0.0, stat=Sent
31. Про Delivery Mode & OpMode
По причине большого объема перенесено сюда.
32. Почему не всегда можно воспользоваться сохранением заголовка в макросе.
Потому что при сохранении заголовка в макросе, данные в круглых скобках теряются.
HReceived: $>+CheckReceived
SCheckReceived
R$* $: $(storage {Received} $@ $1 $) $1
R$* $: $(syslog syslog:Rec0:<$&{Received}> $) $1
R$* $: $(syslog syslog:Rec1:<$1> $) $1
Dec 15 14:50:59 mail sendmail[8751]: mBF9oxvp008751: syslog:Rec0:< from[138.88.3.196] by.apache.anrb.ru.with.ESMTP.id.mBF9WrfP006924.for< parad...@anrb.ru >;Mon, 15.Dec.2008.14:33:02+0500 >
Dec 15 14:50:59 mail sendmail[8751]: mBF9oxvp008751: syslog:Rec1:< from[138.88.3.196](pool-138-88-3-196.res.east.verizon.net [138.88.3.196])by.apache.anrb.ru(8.13.8/8.13.8)
with.ESMTP.id.mBF9WrfP006924.for;Mon,15.Dec. 2008.14:33:02+0500 >
Dec 15 14:50:42 mail sendmail[8607]: mBF9ocfM008607: syslog:Rec0:< ; 15.Dec.2008.09:44:16.-0000 >
Dec 15 14:50:42 mail sendmail[8607]: mBF9ocfM008607: syslog:Rec1:< (qmail.46011.invoked.by.uid.60001);15.Dec. 2008.09:44:16.-0000 >
На sendmail-конфе мое сообщение прошло незамеченным.
Конечно, в рамках рулсета CheckReceived можно обойтись и без макроса, просто удвоив ввод и работая только с одним из удвоенных параметров.
Но , если с этим заголовком нужно поработать в другом рулсете, то придется смириться с частичной потерей данных.
Или попробовать запомнить их в отдельном макросе, что-то типа
R$* ( $+ ) $* $: $(storage {Lost_data} $@ $2 $) $1 ( $2 ) $3
Или даже так:
R$* ( $+ ) $* $: $(storage {Lost_data} $@ $1($2)$3 $) $1 ( $2 ) $3
Интересно, можно внутри скобки использовать? Если нет, то $1-$2-$3
33. Непонятки с пустым макросом $&{To} при заполненном заголовке To:
HTo: $>+CheckTo
HCc: $>+CheckTo
SCheckTo
R$* $:
$(storage {To} $@ $1 $) $1
R$* $:
$(syslog syslog:To:0: $1 $)
Scheck_eoh
R$* $:
<$&{To}>
R<>
$: $(syslog
syslog:eoh:00: <$&{To}><$&u><$&{nrcpts}> $)
Dec 17 15:20:43 mail sendmail[13519]: mBHAKdMS013519: syslog:eoh:00:<><paradise><1>
Dec 17 15:20:43 mail sendmail[13519]: mBHAKdMS013519: from=<import@buonitaly.com>, size=153798, class=0,
nrcpts=1, msgid=<4BEEB51BF85A4B0783ED5798F049A56D@04OKT>, proto=ESMTP, daemon=MTA, relay=mx68.mail.ru [194.67.23.246]
Dec 17 15:21:54 mail sendmail[13575]: mBHAKdMS013519: to=<paradise@anrb.ru>, delay=00:01:11, xdelay=00:01:10,
mailer=local, pri=184353, dsn=2.0.0, stat=Sent
From import@buonitaly.com Wed Dec 17 15:20:44 2008
Return-Path: <import@buonitaly.com>
Received: from mx68.mail.ru (mx68.mail.ru [194.67.23.246])
by mail.anrb.ru (8.14.2/8.14.2) with ESMTP id mBHAKdMS013519
for <paradise@anrb.ru>; Wed, 17 Dec 2008 15:20:43 +0500
Received: from mail by mx68.mail.ru with local
id 1LCtPm-000Pyx-00
for paradise@anrb.ru; Wed, 17 Dec 2008 13:14:02 +0300
X-ResentFrom: <onb2005@mail.ru>
X-MailRu-Forward: 1
Received: from [80.91.176.193] (port=58452 helo=zero.hosted.in)
by mx68.mail.ru with esmtp
id 1LCtPl-000PxK-00; Wed, 17 Dec 2008 13:14:01 +0300
Received-SPF: none (mx68.mail.ru: 80.91.176.193 is neither permitted nor denied by domain of buonitaly.com)
client-ip=80.91.176.193; envelope-from=import@buonitaly.com; helo=zero.hosted.in;
X-Mru-PTR: none
X-Mru-NR: 5
X-Mru-OF: unknown (unknown)
X-Mru-RC: UA
Received: from 89-97-102-203.ip17.fastwebnet.it ([89.97.102.203] helo=04OKT)
by zero.hosted.in with esmtpa (Exim 4.69)
(envelope-from <import@buonitaly.com>)
id 1LCszh-0000wV-3y; Wed, 17 Dec 2008 11:47:26 +0200
Message-ID: <4BEEB51BF85A4B0783ED5798F049A56D@04OKT>
Reply-To: <import@buonitaly.com>
From: <import@buonitaly.com>
To: <ovs_chsz@aaaaa.net>, <ost@bbbbb.ee>, <eshka@ffffffff.ru>,
<eshka@nv.ggggggggg.net>, <os@avvv.ru>, <orshiz@iiiiiik.by>,
<lmash@zzzzzzzzz.bbbbbbb.net>, <orp@ffff.ggg.ru>, и еще штук 30 получателей
Subject: =?koi8-r?B?8M/L1dDBxc0g09TBzsvJOiAxQTY2NSwgMUE2NzUsIDE1NDBULCAxNQ==?=
=?koi8-r?B?NTBULCAxNTYzLCAxNTkzLCBUaXRhbiBTQzogMjIsMjUsMjcsMzMsNDMu?=
Date: Tue, 16 Dec 2008 23:49:10 +0100
MIME-Version: 1.0
Content-Type: multipart/related;
type="multipart/alternative";
boundary="----=_NextPart_000_008C_01C95FD8.E489F1B0"
X-Priority: 1
X-MSMail-Priority: High
X-Mailer: Microsoft Outlook Express 6.00.2900.5512
Disposition-Notification-To: <import@buonitaly.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - zero.hosted.in
X-AntiAbuse: Original Domain - mail.ru
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - buonitaly.com
X-Spam: Not detected
X-Mras: Ok
X-Drweb-SpamState: no
X-Drweb-SpamState-Num: 0
X-Drweb-SpamScore: 0
X-Drweb-SpamVersion: Vade Retro 01.280.14 AV+AS Profile: <none>; Bailout: N/A
X-Antivirus: Dr.Web (R) for Unix mail servers drweb plugin ver.4.44.2.0805030
X-Antivirus-Code: 0x100000
Status: RO
X-Status:
X-Keywords:
X-UID: 5432
За 3 дня, что я отслеживала почту с пустым To: мне попалось с десяток таких писем. Причина не заполнения макроса $&{To} мне
непонятна. Но все эти письма объединяет одна особенность: получателей ну очень много. Я пробовала смоделировать подобное письмо,
но безуспешно. Все мои тестовые письма оказались с заполненным макросом $&{To}.
Зачем CheckTo c плюсом? А иначе в To: текст в скобках будет опущен, например,
Dec 15 19:54:11 mail sendmail[28967]: mBFEs7V4028967: syslog:eoh:00:<><deodar><1>
Dec 15 19:54:11 mail sendmail[28967]: mBFEs7V4028967: from=<yortInterScienceAlerts@yort.com>, size=7946,
class=0, nrcpts=1, msgid=<200812151438.mBFEcPTr018471@cronos3.yort.com>, proto=ESMTP, daemon=MTA,
relay=xmail4.yort.com [2.2.1.2]
Dec 15 19:54:11 mail sendmail[29012]: mBFEs7V4028967: to=<deodar@anrb.ru>, delay=00:00:00, xdelay=00:00:00,
mailer=local, pri=38387, dsn=2.0.0, stat=Sent
From yortInterScienceAlerts@yort.com Mon Dec 15 19:54:11 2008
Return-Path: <yortInterScienceAlerts@yort.com>
Received: from xmail4.yort.com (xmail4.yort.com [2.1.1.5])
by mail.anrb.ru (8.14.2/8.14.2) with ESMTP id mBFEs7V4028967
for <deodar@anrb.ru>; Mon, 15 Dec 2008 19:54:11 +0500
[skipped]
Received: (from wispers@localhost)
by cronos3.yort.com (8.14.2/8.14.2/Submit) id mBFEcPTr018471;
Mon, 15 Dec 2008 09:38:25 -0500 (EST)
Date: Mon, 15 Dec 2008 09:38:25 -0500 (EST)
Message-Id: <200812151438.mBFEcPTr018471@cronos3.yort.com>
X-Authentication-Warning: cronos3.yort.com: wispers set sender to yortInterScienceAlerts@yort.com using -f
From: FEBS Journal<yortInterScienceAlerts@yort.com>
To: (alert recipient)
Subject: yort Interscience Content Alert: FEBS Journal 276, 1
34. Извещение пользователю, если письмо от него было воспринято удаленной системой как спам.
Недавно мне пришлось поднимать летние логи, потому что одна пользователь сообщила мне, что ее почта пропадает бесследно,
в том числе пропала очень важная, летняя. Как я и полагала, удаленная почтовая система эту почту посчитала спамом
(это я определила по сообщению в скобках, следовавшему за stat=Sent), и по всей видимости, просто уничтожила ее.
Поскольку мне совсем не улыбается выслушивать несправедливые упреки и шерстить старые логи,
решила я определять такую почту оперативно, и сразу извещать об этом пользователей.
Извещение у меня пока ручное, а вот поиск такой почты - в скрипте, запускаемом ежедневно.
if [ "$1" = "" ] ; then
filename=/var/log/maillog.1
else
filename=$1
fi
string="OK|(Message )?(accepted|received|queue|Transmission in progress|Thanks)"
egrep "stat=Sent.+" $filename|egrep -vi "$string" >/var/log/remote-answer-spam
if [ -s /var/log/remote-answer-spam ] ; then
size=`wc -c /var/log/remote-answer-spam|awk '{print $1}'`
max_report_size=1000000
if [ "$size" -gt "$max_report_size" ] ; then
echo "Stat file is too large ($size) so remote-answer-spam cant be sent."|mail -s$0 postmaster
else
mail -sremote-answer-spam postmaster </var/log/remote-answer-spam
fi
fi
35. Почему FEATURE(dnsbl,...) не блокирует почту с IP-адресов, попавших в данный blacklist?
05.02.2009. Источник - здесь.
Будьте внимательны при заполнении значений аргументов FEATURE(dnsbl, ...)
Запятая в тексте ошибки приводит к тому, что самая значительная строка dnsbl-блока $#error опускается.
Пример. Заменим знак "-" на "," .
FEATURE(`dnsbl', `cbl.abuseat.org', `"550 Mail from " $&{client_addr} " rejected , see
cbl.abuseat.org/lookup.cgi?ip="$&{client_addr}')
Команда m4 /usr/src/sendmail/cf/m4/cf.m4 sendmail.mc >sendmail.cf
при этом ошибку не выдает, а сам блок в sendmail.cf выглядит вот так:
# DNS based IP address spam list cbl.abuseat.org
R$* $: $&{client_addr}
R$-.$-.$-.$- $: $(dnsbl $4.$3.$2.$1.cbl.abuseat.org. $: OK $)
ROK $: OKSOFAR
R$+ $: TMPOK
Хотя он должен был бы выглядеть вот так:
# DNS based IP address spam list cbl.abuseat.org
R$* $: $&{client_addr}
R$-.$-.$-.$- $: $(dnsbl $4.$3.$2.$1.cbl.abuseat.org. $: OK $)
ROK $: OKSOFAR
R$+ $: TMPOK
R$+ $#error $@ 5.7.1 $: "550 Mail from " $&{client_addr} " rejected , see
cbl.abuseat.org/lookup.cgi?ip="$&{client_addr}
Я набралась наглости, и оставила на sendmail-конфе сообщение,
предлагающее осветить в документации этот момент. Оказалось, что информация об этом в README уже имеется (ответил СамСамыч Claus Assmann :)) :
"Remember that these options are M4 variables, and hence may need to
be quoted. In particular, arguments with commas will usually have to
be ``double quoted, like this phrase'' to avoid having the comma
confuse things. This is common for alias file definitions and for
the read timeout."
Вообще-то было бы, наверное, правильнее, если бы в таком случае m4 выдавал сообщение об ошибке, не допуская запятую в аргументе,
если она не``double quoted'' но как говорится, "жираф большооой, ему видней". :)
36. Почему access файл не блокирует почту для локальных адресов
05.02.2009. Потому что нужно читать первоисточники. В данном случае это README, и он ясно говорит:
blacklist_recipients
Turns on the ability to block incoming mail for certain
recipient usernames, hostnames, or addresses. For
example, you can block incoming mail to user nobody,
host foo.mydomain.com, or guest@bar.mydomain.com.
These specifications are put in the access db as
described in the anti-spam configuration control section
later in this document.
If you use:
FEATURE(`blacklist_recipients')
then you can add entries to the map for local users, hosts in your
domains, or addresses in your domain which should not receive mail:
To:badlocaluser@ ERROR:550 Mailbox disabled for badlocaluser
To:host.my.TLD ERROR:550 That host does not accept mail
To:user@other.my.TLD ERROR:550 Mailbox disabled for this recipient
This would prevent a recipient of badlocaluser in any of the local
domains (class {w}), any user at host.my.TLD, and the single address
user@other.my.TLD from receiving mail. Please note: a local username
must be now tagged with an @ (this is consistent with the check of
the sender address, and hence it is possible to distinguish between
hostnames and usernames).
То есть сам по себе access файл действует только на внешних отправителей/получателей.
Для того, чтобы наложить ограничение на локальных юзеров, нужно использовать дополнительную фичу
FEATURE(`blacklist_recipients')
Да, еще раз подчеркну то, что автор вопроса благополучно пропустил мимо ушей:
access предназначен только для глобальных запретов ((From|To):(domain|e-mail|IP) -> ALL_USERS
если нужен избирательный запрет, то необходимы дополнительные правила.
Взгляните, в какое бурное обсуждение вылилось нежелание читать доки.
И нежелание внимательно читать посты.
А также нежелание отвечать на вопросы.
А ведь про blacklist я написала еще в первом своем ответе.
Господи, и когда я избавлюсь от дурной привычки отвечать на конфах ???
Ведь это просто невыносимо, когда на 10 твоих наводящих вопросов автор отвечает избирательно, как ему самому захочется.
Да, а еще я дождалась-таки, что мои рулсеты назвали гадостью. Вот. :)
Нее, голову пеплом не посыплю и в монастырь не уйду, не дождутся. :)
37. Mail.ru говорит "dsn=5.1.1, stat=User unknown", в то время как ящик существует.
Это не имеет прямого отношения к sendmail, просто не хочется заводить отдельную страницу.
Источник.
Это может означать, что IP, с которого посылается письмо, попал в blacklist на mail.ru.
Причина, в принципе, легко обнаруживаема, если читать свою почту, а не бежать сразу на opennet.ru.
Почему автор не сделал это сразу, останется теперь для меня загадкой.
Но здесь есть 2 интересных момента.
1. Почему все-таки попадание в BL отражается ответом User unknown.
2. Попасть в BL на mail.ru достаточно легко. Я и сама на эти грабли наступала. Как-то тестировала mailertable на транзитном mx-е,
и так получилось, что письмо (одно!), предназначенное, скажем, terrapin@anrb.ru, ускакало на terrapin@mail.ru.
Я это не сразу обнаружила, но, видимо, товарищ terrapin на mail.ru пожаловался на спам от меня, в итоге мой транзитный
MX попал в BL, что обнаружилось тоже не сразу, а лишь спустя пару месяцев, когда мне понадобилось отправить
с него почту на mail.ru. Ну и с моими коллегами это тоже происходило, когда человек ошибался в адресе, и письмо уходило совсем другому
пользователю mail.ru. К счастью, разблокировка происходит довольно быстро.
38. Как правильно задавать вопросы на sendmail-конфе.
Я пару раз натыкалась на слова Claus Assmann о том, что в вопросе нужно обозначить наличие проблемы,
иначе супер-гуру полагают, что интерес чисто академический, и могут проигнорировать вопрос.
То есть в вопросе должно прозвучать, что вы столкнулись с определенной проблемой и это не теоретический, а практический вопрос.
Хотя такие энтузиасты (в самом хорошем и человечном смысле этого слова) как
Andrzej Adam Filip, Grant Taylor, David F. Skoll, D. Stussy, Joe Maimon и другие ответят на вопрос в любом случае, если они знают решение.
39. Потеря писем.
У меня проблемы с получателями: делают честные глаза и говорят, что не получали какое-то письмо.
Я уже на это жаловалась.
Совет по поводу TheBat! Как известно в нем можно настроить фильтрацию писем в отдельную папку.
Однажды лично у меня случилось так, что письмо было получено TheBat!, но ни в одной папке не появилось.
Нашла я его, непосредственно просмотрев файлы MESSAGES.TB* в папке Inbox.
Также возможно, что юзер сознательно удалит письмо, а затем заявит, что не получал его.
Так что просмотреть лог - это одно. А если юзер доступен физически :), то смотрим папку Inbox, затем Trash, затем
TheBat!\Mail\Inbox\MESSAGES.TB*, затем смотрим корзину на предмет наличия заблаговременно удаленных MESSAGES.TB*.
Если таковые обнаружатся, делаем копии текущих TheBat!\Mail\Inbox\MESSAGES.TB*, восстанавливаем удаленные MESSAGES.TB*
и ищем письмо в них.
40. Как определить несколько алиас-файлов.
define(`ALIAS_FILE',`/etc/mail/aliases,/etc/mail/aliases2')
/etc/sendmail.cf
O AliasFile=/etc/mail/aliases,/etc/mail/aliases2
[1]
[2]
41. Зачем очищать макрос.
Признаюсь, я практически не слежу за очищением макросов. Мне было не понятно, для чего это нужно, если
макрос очищается в начале сессии. Упустила то, что за одну сессию может быть послано несколько писем,
и если макрос не очищен на предыдущем письме, то последующее письмо может вызвать ошибочное исполнение рулсета.
Вообще-то, как правило, я обнуляю макросы в начале в секции LOCAL_CONFIG, которая задает значения макросов. Выходит, этого
недостаточно? Значения макросов в самих рулсетах тоже обнуляю, но не всегда. Потому что это несколько геморройно:
если произошел отказ при достижении макросом определенного значения, то сначала макрос нужно очистить, а потом только выдавать #error.
[1]
42. Строгое соответствие доменного имени в access. FEATURE(relay_hosts_only).
По умолчанию домен, упомянутый в access, означает и все свои поддомены.
То есть действие будет применено к *.domain.ru.
Если вам нужно строгое соответствие, то используйте FEATURE(relay_hosts_only).
By default, names that are listed as RELAY in the access db and class {R} are treated as domain names, not host names.
For example, if you specify ``foo.com'', then mail to or from foo.com, abc.foo.com, or a.very.deep.domain.foo.com
will all be accepted for relaying. This feature changes the behaviour to lookup individual host names only
Ссылки: [1],
[2].
Задачка.
Есть некий домен, который упомянут в access (To:domain.ru RELAY) на транзитном релее.
На этот релей приходит почта, предназначенная несуществующему домену, скажем, river_tom.domain.ru
По каким-то соображениям автор не хочет использовать FEATURE(relay_hosts_only), чтобы исключить поддомены из разрешенных к релеингу.
И вместе с тем его не устраивает лишняя работа sendmail по обработке сообщений для несущ. поддоменов domain.ru.
Решение, которое у него почему-то не заработало, но прекрасно отработавшее у меня:
LOCAL_CONFIG
SLocal_check_rcpt
R$* $: $>Parse0 $>3 $1
R$+<@$+> $: $1<@$2>
R$+<@$+.> $: $1<@$2.>
R$+ $#error $: "553 5.1.8 Domain of recipient address does not exist."
Этот набор был когда-то написан по пожеланию Askon для SendmailACL.
43. Сетки популярных бесплатных почтовых систем для внесения в белые списки.
Источник.
HOSTGOOGLE="{64.233.160.0/19 ,66.102.0.0/20,66.249.80.0/20,72.14.192.0/18,74.125.0.0/16,209.85.128.0/17,216.239.32.0/19}"
HOSTMAILRU="{194.67.23.0/24,194.67.45.0/24,194.67.57.0/24}"
HOSTRAMBLER="{81.19.66.0/23}"
HOSTYANDEX="{213.180.192.0/19,87.250.224.0/19,77.88.0.0/18}"
44. Нужен или нет NDR? Имеем ли мы право отказываться от формирования или получения NDR?
Этот вопрос оч. часто появляется на форумах. Пока только ссылки.
Sendmail: бесконечная попытка отправки
Specific configuration of sendmail to ignore 5.*.* codes
Postfix: Postfix + non-delivery notification
45. Как откладывать отвергнутую почту в отдельный файл?
1.1 Если задачу нужно решать только средствами sendmail и отказ почты основан на
адресе отправителя/получателя/IP-адресе источника/любой другой информации, которую можно вытащить по IP источника, то нужно использовать изменение маршрута.
1.2 Если опять-таки только средствами sendmail и отказ почты основан на остальных заголовках письма, то только через карантин.
2. Также можно использовать какой-нибудь фильтр, который будет осуществлять проверку заголовков и тело письма и принимать решение _после_ принятия письма.
3. Ну и procmail можно припахать.
46. Как из sendmail.cf получить sendmail.mc.
Привожу ссылку на мой комментарий на тот случай, если кто-нибудь допишет
что-либо толковое по данной теме.
1. Переписать все модули, с которыми собран данный конфиг. Они указаны в начале sendmail.cf в первых строках, например, строка
##### $Id: dnsbl.m4
означает, что конфиг собран с поддержкой dnsbl-баз (FEATURE(`dnsbl',`the value', `the value')),
##### $Id: greet_pause.m4
означает, что наложены ограничения на этап HELO smtp-сессии с помощью FEATURE(`greet_pause',`the value')
2. Посмотреть, заполнена ли секция MAIL FILTER DEFINITION.
Например, я использую VadeRetro & DrWeb, поэтому в моем sendmail.cf есть такой раздел:
######################################################################
######################################################################
#####
##### MAIL FILTER DEFINITIONS
#####
######################################################################
######################################################################
Xdrweb-filter, S=local:/var/drweb/ipc/drweb-milter.sock, T=C:10m;S:8m;R:8m;E:10m
Это означает, что в sendmail.mc есть строка
INPUT_MAIL_FILTER(`drweb-filter',`S=local:/var/drweb/ipc/drweb-milter.sock, T=C:10m;S:8m;R:8m;E:10m')
3. Посмотреть секцию MAILER DEFINITIONS и соотнести ее с подходящими строками в начале sendmail.cf.
Например, у меня в этой секции написано следующее:
######################################################################
######################################################################
######################################################################
#####
##### MAILER DEFINITIONS
#####
######################################################################
######################################################################
##################################################
### Local and Program Mailer specification ###
##################################################
##### $Id: local.m4,v 8.59 2004/11/23 00:37:25 ca Exp $ #####
[skip]
...
[skip]
Mlocal, P=/usr/bin/procmail, F=lsDFMAw5:/|@qSPfhn9, S=EnvFromL/HdrFromL, R=EnvToL/HdrToL,
T=DNS/RFC822/X-Unix,
A=procmail -Y -a $h -d $u
Mprog, P=/usr/libexec/smrsh, F=lsDFMoqeu9, S=EnvFromL/HdrFromL, R=EnvToL/HdrToL, D=$z:/,
T=X-Unix/X-Unix/X-Unix,
A=smrsh -c $u
а в начале конфига упомянуты следующие файлы:
##### $Id: linux_procmail.m4,v 8.13 1999/04/24 05:37:43 gshapiro Exp $ #####
##### $Id: local_procmail.m4,v 8.22 2002/11/17 04:24:19 ca Exp $ #####
##### $Id: smrsh.m4,v 8.14 1999/11/18 05:06:23 ca Exp $ #####
Все это есть следствие заданных опций в конфиге
MAILER(`local')
ifdef(`PROCMAIL_MAILER_PATH',,
define(`PROCMAIL_MAILER_PATH', `/usr/bin/procmail'))
FEATURE(local_procmail)
FEATURE(`smrsh')
Использование MAILER(`smtp') повлечет за собой появление в конфиге следующего блока:
#####################################
### SMTP Mailer specification ###
#####################################
##### $Id: smtp.m4,v 8.65 2006/07/12 21:08:10 ca Exp $ #####
[skip]
...
[skip]
Msmtp, P=[IPC], F=mDFMuX, S=EnvFromSMTP/HdrFromSMTP, R=EnvToSMTP, E=\r\n, L=990,
T=DNS/RFC822/SMTP,
A=TCP $h
Mesmtp, P=[IPC], F=mDFMuXa, S=EnvFromSMTP/HdrFromSMTP, R=EnvToSMTP, E=\r\n, L=990,
T=DNS/RFC822/SMTP,
A=TCP $h
Msmtp8, P=[IPC], F=mDFMuX8, S=EnvFromSMTP/HdrFromSMTP, R=EnvToSMTP, E=\r\n, L=990,
T=DNS/RFC822/SMTP,
A=TCP $h
Mdsmtp, P=[IPC], F=mDFMuXa%, S=EnvFromSMTP/HdrFromSMTP, R=EnvToSMTP, E=\r\n, L=990,
T=DNS/RFC822/SMTP,
A=TCP $h
Mrelay, P=[IPC], F=mDFMuXa8, S=EnvFromSMTP/HdrFromSMTP, R=MasqSMTP, E=\r\n, L=2040,
T=DNS/RFC822/SMTP,
A=TCP $h
4.
2. Собрав все модули, сформировать test_sendmail.mc, далее из него получить
test_sendmail.cf.
3. diff sendmail.cf test_sendmail.cf
4. Далее придется думать.
Если изменения предшественником вносились прямо в sendmail.cf, то придется сделать то же самое.
В общем, работа не из легких. http://www.sendmail.org/~ca/email/more.html#CF2MC
47.
48.
49.
50.
Обратная связь
Страница создана 27 июня 2007г. Последнее обновление - 17 ноября 2010г.