[Карта]                      [Начало]                      [Sendmail-ссылки]                      [Синтаксис]                      [Типовые задачки]                      [Задачки по маршрутизации]                      [Задачки по макарадингу]                      [SendmailACL]                      [Spamooborona]                      [VadeRetro]                      [Regex]                      [Тонкости]                      [Недок.особен.]                      [Несущ.юзеры]                      [Прячемся!]                      [RFC1893.Цитаты]                      [ТП.Эмоции]                      [Антиспам&Разум]                     


Sendmail. Тонкости. Delivery Mode & Operation Mode

1. Общее про Delivery Mode & OpMode.

2. Первоисточники про DeliveryMode.

3. Первоисточники про OpMode.

3.1. Соль.

4. Примеры.

5. Мой вывод.

5.1. Что следует изменить в решении задачек по маршрутизации с учетом п.5.

6. По поводу взаимоотношений между DeliverMode & OpMode & queue.

1. Общее про Delivery Mode & OpMode

Здесь будет накапливаться инфа о том, почему для разрешения проблемы "Особенности решений по перемаршрутизации почты в LOCAL_RULE_0" я использую макрос $&{deliveryMode}. Несмотря на неодобрение sendmail-гуру Анджея Адама Филипа моего решения, я все-таки рискну и продолжу копать в этом направлении. Может, это просто тупое женское упрямство, но другого выхода и источника информации у меня нет, поэтому я продолжу упорствовать. Ну, а чтобы не вводить вас в заблуждение и не запутывать, все мои личные выводы будут выделелены зеленым цветом. Чтобы вы их не принимали за Истину.

Итак, никак не могла я смириться с четырехкратным исполнением моих правил в решении задачек по перемаршрутизации, а оптимальное решение никак не находилось, поэтому стала перебирать все подходящие макросы, которые помогли бы разграничить каждый из 4 этапов исполнения правил. Про <$&{addr_type}> подсказал Andrzej Adam Filip.
op.me: The type of the address which is currently being rewritten. This macro contains up to three characters, the first is either `e' or `h' for envelope/header address, the second is a space, and the third is either `s' or `r' for sender/recipient address. Notice: for header addresses no distinction is currently made between sender and recipient addresses, i.e., the macro contains only `h'.
Это помогло разграничить отправителя и получателя, то есть сократить число проходов вдвое.
А вот как разграничить первый проход правил и второй проход правил? Я стала выводить в лог все подходившие по смыслу макросы, остановившись в конце концов на двух - Delivery Mode & OpMode.
И, о чудо, оказалось, что первый макрос изменяет свое значение в каждом из проходов, а второй или остается неизменным (d), или меняет значение с d на q (d - когда почта идет от локального клиента внешнему, то есть работает мэйлер (e)smtp; d->q - когда почта приходит локальному клиенту, то есть работает мэйлер local, подробности позже).
Теперь остается самое сложное - подвести под это теорию. И пока никак ...
Пока я не нашла этому никакого объяснения в документации и полагаюсь исключительно на свою практику. Отслеживая в течение месяца макрос $&{deliveryMode} в почте на транзитном mx-е, я лишь утвердилась в своем первоначальном выводе: на этапе smtp-диалога (CONNECT, HELO, MAIL, RCPT, DATA) значение макроса $&{deliveryMode} равно b, когда происходит непосредственная доставка письма в локальный ящик значение макроса $&{deliveryMode} становится равным i.
Если условно разбить процесс доставки сообщения на 2 фазы:
1) SMTP-диалог (MTA->MTA или MUA->MTA )
2) локальная доставка или дальнейший транзит (MTA->LDA или MTA->MTA)
то можно сказать, что на первом этапе sendmail работает в режиме background, на втором этапе - в режиме interactively.
(MTA или MUA) -> MTA -> (LDA или MTA)
        background                interactive


15/12/2008 Свет в конце тунеля забрезжил, так что в выходные опишу ситуацию.
Ключевая фраза от Claus Assmann:

> I have read in a great deal of posts that DeliveryMode=interactive
> is supposed to improve performance, but I've yet to find a reference
> as to HOW it improves performance. Could someone point me to some
> information on this?

It implements synchronous delivery, hence it doesn't fork() a sendmail copy for delivery as background mode would do. If you do that, you can turn off SuperSafe which avoids the costly meta-data filesystem operation (fsync()). This can result in substantial throughput improvement depending on your disk (and OS).
If you want the best performance: don't queue... Of course you need to check the activity on your system, but unless you have a high-end disk system it will be the bottleneck.

И еще. Per Hedeland.
sendmail forks for delivery, but that has nothing to do with the
daemon running, it's just its default delivery mode ("background"). You
can prevent that fork by calling sendmail with -odi ("interactive"
delivery mode).


2. Что говорят про DeliveryMode первоисточники?

op.me: ${deliveryMode} The current delivery mode sendmail is using. It is initially set to the value of the DeliveryMode option.

4.7. Delivery Mode

There are a number of delivery modes that send- mail can operate in, set by the DeliveryMode (d) con- figuration option. These modes specify how quickly mail will be delivered. Legal modes are:

i deliver interactively (synchronously)
b deliver in background (asynchronously)
q queue only (don't deliver)
d defer delivery attempts (don't deliver)

There are tradeoffs. Mode "i" gives the sender the quickest feedback, but may slow down some mailers and is hardly ever necessary. Mode "b" delivers promptly but can cause large numbers of processes if you have a mailer that takes a long time to deliver a message. Mode "q" minimizes the load on your machine, but means that delivery may be delayed for up to the queue interval. Mode "d" is identical to mode "q" except that it also prevents lookups in maps including the -D flag from working during the initial queue phase; it is intended for ``dial on demand'' sites where DNS lookups might cost real money. Some simple error mes- sages (e.g., host unknown during the SMTP protocol) will be delayed using this mode. Mode "b" is the usual default.

If you run in mode "q" (queue only), "d" (defer), or "b" (deliver in background) sendmail will not expand aliases and follow .forward files upon initial receipt of the mail. This speeds up the response to RCPT commands. Mode "i" should not be used by the SMTP server.

5.6. O -- Set Option
There are a number of global options that can be set from a configuration file. Options are repre- sented by full words; some are also representable as single characters for back compatibility. The syntax of this line is:
O option=value
This sets option option to be value. Note that there must be a space between the letter `O' and the name of the option. An older version is:
Oovalue
where the option o is a single character. Depending on the option, value may be a string, an integer, a boolean (with legal values "t", "T", "f", or "F"; the default is TRUE), or a time interval.
All filenames used in options should be absolute paths, i.e., starting with '/'. Relative filenames most likely cause surprises during operation (unless otherwise noted).
The options supported (with the old, one charac- ter names in brackets) are:
...
...
DeliveryMode=x
[d] Deliver in mode x. Legal modes are:

i Deliver interactively (synchronously)
b Deliver in background (asynchronously)
q Just queue the message (deliver during queue run)
d Defer delivery and all map lookups (deliver during queue run)
Defaults to ``b'' if no option is specified, ``i'' if it is specified but given no argu- ment (i.e., ``Od'' is equivalent to ``Odi''). The -v command line flag sets this to i. Note: for internal reasons, ``i'' does not work if a milter is enabled which can reject or delete recipients. In that case the mode will be changed to ``b''.
...
All options can be specified on the command line using the -O or -o flag, but most will cause sendmail to relinquish its set-user-ID permissions. The options that will not cause this are SevenBitInput [7], Eight- BitMode [8], MinFreeBlocks [b], CheckpointInterval [C], DeliveryMode [d], ErrorMode [e], IgnoreDots [i], SendMimeErrors [j], LogLevel [L], MeToo [m], OldStyle- Headers [o], PrivacyOptions [p], SuperSafe [s], Verbose [v], QueueSortOrder, MinQueueAge, Default- CharSet, Dial Delay, NoRecipientAction, ColonOkInAddr, MaxQueueRunSize, SingleLineFromHeader, and AllowBo- gusHELO. Actually, PrivacyOptions [p] given on the command line are added to those already specified in the sendmail.cf file, i.e., they can't be reset. Also, M (define macro) when defining the r or s macros is also considered "safe".


3. А что говорят первоисточники про OpMode?

op.me: ${opMode} The current operation mode (from the -b flag).

APPENDIX A. COMMAND LINE FLAGS.
-bx         Set operation mode to x. Operation modes are:
         m          Deliver mail (default)
         s          Speak SMTP on input side
         a|         ``Arpanet'' mode (get envelope sender information from header)
         d          Run as a daemon in background
         D          Run as a daemon in foreground
         t          Run in test mode
         v          Just verify addresses, don't collect or deliver
         i          Initialize the alias database
         p          Print the mail queue
         P          Print overview over the mail queue (requires shared memory)
         h          Print the persistent host status database
         H          Purge expired entries from the persistent host status database

/usr/sbin/sendmail -bd -q30m
The line that actually invokes sendmail has two flags: "-bd" causes it to listen on the SMTP port, and "-q30m" causes it to run the queue every half hour.

3.2. Daemon Mode
If you allow incoming mail over an IPC connec- tion, you should have a daemon running. This should be set by your /etc/rc file using the -bd flag. The -bd flag and the -q flag may be combined in one call:
/usr/sbin/sendmail -bd -q30m
An alternative approach is to invoke sendmail from inetd(8) (use the -bs -Am flags to ask sendmail to speak SMTP on its standard input and output and to run as MTA). This works and allows you to wrap send- mail in a TCP wrapper program, but may be a bit slower since the configuration file has to be re-read on every message that comes in. If you do this, you still need to have a sendmail running to flush the queue:
/usr/sbin/sendmail -q30m

3.3. Forcing the Queue
In some cases you may find that the queue has gotten clogged for some reason. You can force a queue run using the -q flag (with no value). It is enter- taining to use the -v flag (verbose) when this is done to watch what happens:
/usr/sbin/sendmail -q -v

Ну и напоследок RELEASE_NOTES (кажется, эта инфа может пригодиться).

The .cf file is chosen based on the operation mode. For -bm (default), -bs, and -t it is submit.cf if it exists for all others it is sendmail.cf (to be backward compatible). This selection can be changed by the new option -Ac or -Am (alternative .cf file: client or mta). See sendmail/SECURITY.

Change the $&{opMode} macro if the operation mode changes while the MTA is running. For example, during a queue run.

Add new ${opMode} macro that is set to the current operation mode (e.g., `s' for -bs, `t' for -bt, etc.). Suggested by Claude Marinier .

The macro ${deliveryMode} now specifies the current delivery mode sendmail is using instead of the value of the DeliveryMode option.

Add new mode, -bD, that acts like -bd in all respects except that it runs in foreground. This is useful for using with a wrapper that "watches" system services. Suggested by Kyle Jones of UUNET.


3.1. Соль.

Итак, по умолчанию sendmail запускается в режиме DeliveryMode=background.
DeliverMode можно задать из командной строки (-odx), а можно поменять значение опцией в конфиге, например, define(`confDELIVERY_MODE',`queue')
(README: confDELIVERY_MODE DeliveryMode [background] Default delivery mode.)
Будучи запущенным в режиме background sendmail порождает копию sendmail'a, которая в свою очередь имеет DeliveryMode=interactive.
Кроме режима DeliveryMode, sendmail'у при запуске указывается и Operation Mode из флага -b. Обычно это daemon in background:
sendmail -bd -q1h


4. Примеры.


Ну а теперь куча примеров, которые демонстируют изменение макросов DeliveryMode & OpMode.
Эти примеры я собирала в течение долгого времени, потом сортировала скриптом по значениям (Delivery|Op)Mode & mailer=(local|relay) и проверяла, не пересекаются ли данные.

LOCAL_RULE_0
R$*                                    $: $(syslog syslog:LC0: $1<$&{addr_type}><$&{deliveryMode}><$&{opMode}> $) $1
CheckFrom
R$*                                    $: $(syslog syslog:From: <$&{addr_type}> $) $1
CheckTo
R$*                                    $: $(syslog syslog:To: <$&{addr_type}> $) $1
check_eoh
R$*                           $: $(syslog syslog:eoh:<$&f><$&u><$&{deliveryMode}><$&{opMode}> $)

-------
mailer=local. Sendmail в режиме DeliveryMode=background & OpMode=d (OpMode определяется из строки запуска sendmail'a: sendmail -bd -q1h)
Dec 9 19:24:50 mail sendmail[30222]: mB9EOku9030222:syslog:LC0:whereisit<@whereisitkinra.com.><e.s><b><d>
Dec 9 19:24:50 mail sendmail[30222]: mB9EOku9030222: syslog:LC0:consiglio<@anrb.ru.><e.r><b><d>
Dec 9 19:24:51 mail sendmail[30222]: mB9EOku9030222: syslog:From:<h.s>
Dec 9 19:24:51 mail sendmail[30222]: mB9EOku9030222: syslog:To:<h.r>
Dec 9 19:24:51 mail sendmail[30222]: mB9EOku9030222: syslog:eoh:<whereisit@whereisitkinra.com><consiglio><b><d>
Dec 9 19:24:51 mail sendmail[30222]: mB9EOku9030222: from=<whereisit@whereisitkinra.com>, size=5638, class=0, nrcpts=1, msgid=<1776435971.20080820194812@whereisitkinra.com>, bodytype=8BITMIME, proto=SMTP, daemon=MTA, relay=iota.sitelutions.com [69.26.178.210]
Sendmail в режиме DeliveryMode=interactive. OpMode перешел в режим queue (видимо потому, что доставка локальная? кстати, такого режима в описании OpMode нет. То, что это именно queue, я просто догадываюсь.)
Dec 9 19:24:51 mail sendmail[30235]: mB9EOku9030222:syslog:LC0:whereisit<@whereisitkinra.com.><e.s><i><q>
Dec 9 19:24:51 mail sendmail[30235]: mB9EOku9030222: syslog:LC0:consiglio<@anrb.ru.><e.r><i><q>
Dec 9 19:24:51 mail sendmail[30235]: mB9EOku9030222: to=<consiglio@anrb.ru>, delay=00:00:01, xdelay=00:00:00, mailer=local, pri=36077, dsn=2.0.0, stat=Sent
-------
mailer=esmtp. Sendmail в режиме DeliveryMode=background & OpMode=d.
Dec 9 19:15:54 mail sendmail[27179]: mB9EFswO027179: syslog:LC0:consiglio<@anrb.ru.><e.s><b><d>
Dec 9 19:15:55 mail sendmail[27179]: mB9EFswO027179: syslog:LC0:someuser<@oxisenergy.com.><e.r><b><d>
Dec 9 19:15:55 mail sendmail[27179]: mB9EFswO027179: syslog:LC0:otheruser<@oxisenergy.com.><e.r><b><d>
Dec 9 19:15:55 mail sendmail[27179]: mB9EFswO027179: syslog:From:<h.s>
Dec 9 19:15:55 mail sendmail[27179]: mB9EFswO027179: syslog:To:<h.r>
Dec 9 19:15:55 mail sendmail[27179]: mB9EFswO027179: syslog:To:<h.r>
Dec 9 19:15:55 mail sendmail[27179]: mB9EFswO027179: syslog:eoh:<consiglio@anrb.ru><><b><d>
Dec 9 19:16:06 mail sendmail[27179]: mB9EFswO027179: from=<consiglio@anrb.ru>, size=1181266, class=0, nrcpts=2, msgid=<39E21B5E587847E6B890C5BE1AC73D9D@lenak>, proto=ESMTP, daemon=MTA, relay=[1.2.3.1]
Sendmail в режиме DeliveryMode=interactive. OpMode сохранил режим daemon in background (из-за mailer=esmtp?)
Dec 9 19:16:07 mail sendmail[27293]: mB9EFswO027179:syslog:LC0:consiglio<@anrb.ru.><e.s><i><d>
Dec 9 19:16:07 mail sendmail[27293]: mB9EFswO027179: syslog:LC0:someuser<@oxisenergy.com.><e.r><i><d>
Dec 9 19:16:07 mail sendmail[27293]: mB9EFswO027179: syslog:LC0:otheruser<@oxisenergy.com.><e.r><i><d>
Dec 9 19:16:12 mail sendmail[27293]: mB9EFswO027179: to=<otheruser@oxisenergy.com>,<someuser@oxisenergy.com>, ctladdr=<consiglio@anrb.ru> (1627/45), delay=00:00:17, xdelay=00:00:05, mailer=esmtp, pri=1331266, relay=inbound-mx.globalgold.co.uk. [194.1.150.4], dsn=2.0.0, stat=Sent (Ok: queued as D710C7DC141)
-------
mailer=esmtp. Sendmail в режиме DeliveryMode=background & OpMode=d. Работа с алиасом.
Dec 9 17:02:27 mail sendmail[28810]: mB9C2NYT028810:syslog:LC0:someuser<@mail.rb.ru.><e.s><b><d>
Dec 9 17:02:27 mail sendmail[28810]: mB9C2NYT028810: syslog:LC0:terrapin<@anrb.ru.><e.r><b><d>
Dec 9 17:02:27 mail sendmail[28810]: mB9C2NYT028810: syslog:From:<h.s>
Dec 9 17:02:27 mail sendmail[28810]: mB9C2NYT028810: syslog:To:<h.r>
Dec 9 17:02:27 mail sendmail[28810]: mB9C2NYT028810: syslog:eoh:<someuser@mail.rb.ru><><b><d>
Dec 9 17:02:27 mail sendmail[28810]: mB9C2NYT028810: from=<someuser@mail.rb.ru>, size=248021, class=0, nrcpts=1, msgid=<web-20073049@mail.rb.ru>, bodytype=7BIT, proto=ESMTP, daemon=MTA, relay=mailgate.ufa-rb.ru [193.233.144.2]
DeliveryMode=i. Почта для terrapin через aliases перенаправляется на другой сервер.
Opmode=q всегда, когда идет перенаправление по алиасу, т.е. письмо кладется в очередь:
Dec 9 17:02:27 mail sendmail[28841]: mB9C2NYT028810:syslog:LC0:someuser<@mail.rb.ru.><e.s><i><q>
Dec 9 17:02:27 mail sendmail[28841]: mB9C2NYT028810: syslog:LC0:terrapin<@anrb.ru.><e.r><i><q>
Dec 9 17:02:27 mail sendmail[28841]: mB9C2NYT028810: syslog:LC0:terrapin<@imech.anrb.ru.><e.r><i><q>
Dec 9 17:02:28 mail sendmail[28841]: mB9C2NYT028810: to=terrapin@imech.anrb.ru, delay=00:00:01, xdelay=00:00:01, mailer=esmtp, pri=278456, relay=imech.anrb.ru. [212.193.134.20], dsn=2.0.0, stat=Sent (Ok: queued as BD3B97640D0)

--------
mailer=esmtp. Отказы удаленной системы.
Dec 9 18:03:19 mail sendmail[31769]: mB9D3I0g031769: syslog:LC0:deodar<@anrb.ru.><e.s><b><d>
Dec 9 18:03:19 mail sendmail[31769]: mB9D3I0g031769: syslog:LC0:otheruser<@ioc.ac.ru.><e.r><b><d>
Dec 9 18:03:20 mail sendmail[31769]: mB9D3I0g031769: syslog:From:<h.s>
Dec 9 18:03:20 mail sendmail[31769]: mB9D3I0g031769: syslog:To:<h.r>
Dec 9 18:03:20 mail sendmail[31769]: mB9D3I0g031769: syslog:eoh:<deodar@anrb.ru><><b><d>
Dec 9 18:03:26 mail sendmail[31769]: mB9D3I0g031769: from=<deodar@anrb.ru>, size=1273384, class=0, nrcpts=1, msgid=<493E6D9E.6060301@anrb.ru>, proto=ESMTP, daemon=MTA, relay=[1.2.3.4]
DeliveryMode=i; Opmode=d
Dec 9 18:03:26 mail sendmail[31843]: mB9D3I0g031769: syslog:LC0:deodar<@anrb.ru.><e.s><i><d>
Dec 9 18:03:26 mail sendmail[31843]: mB9D3I0g031769: syslog:LC0:otheruser<@ioc.ac.ru.><e.r><i><d>
Dec 9 18:03:57 mail sendmail[31843]: mB9D3I0g031769: to=<otheruser@ioc.ac.ru>, ctladdr=<deodar@anrb.ru> (1029/45), delay=00:00:38, xdelay=00:00:31, mailer=esmtp, pri=1393384, relay=mail.ioc.ac.ru. [193.233.3.4], dsn=4.7.1, stat=Deferred: 451 4.7.1 Please try again later (TEMPFAIL)
НО! Письму было отказано временной ошибкой, поэтому Opmode=q, т.е. письмо кладется в очередь
Dec 9 18:36:42 mail sendmail[14831]: mB9D3I0g031769: syslog:LC0:deodar<@anrb.ru.><e.s><i><q>
Dec 9 18:36:42 mail sendmail[14831]: mB9D3I0g031769: syslog:LC0:otheruser<@ioc.ac.ru.><e.r><i><q>
Опять неудача:
Dec 9 18:36:58 mail sendmail[14831]: mB9D3I0g031769: to=<otheruser@ioc.ac.ru>, ctladdr=<deodar@anrb.ru> (1029/45), delay=00:33:39, xdelay=00:00:16, mailer=esmtp, pri=1483384, relay=mail.ioc.ac.ru. [193.233.3.4], dsn=4.7.1, stat=Deferred: 451 4.7.1 Please try again later (TEMPFAIL)
Dec 9 19:36:00 mail sendmail[7960]: mB9D3I0g031769: syslog:LC0:deodar<@anrb.ru.><e.s><i><q>
Dec 9 19:36:00 mail sendmail[7960]: mB9D3I0g031769: syslog:LC0:otheruser<@ioc.ac.ru.><e.r><i><q>
Dec 9 19:36:28 mail sendmail[7960]: mB9D3I0g031769: to=<otheruser@ioc.ac.ru>, ctladdr=<deodar@anrb.ru> (1029/45), delay=01:33:09, xdelay=00:00:28, mailer=esmtp, pri=1573384, relay=mail.ioc.ac.ru. [193.233.3.4], dsn=2.0.0, stat=Sent (mB9EUOVT029794 Message accepted for delivery)

-------
Когда я вывела в report file все записи с "маячком" <i><d>, то egrep mailer=local (или -v mailer=(e)smtp) report был пустым,
т.е. <i><d> свойственнен лишь mailer=(e)smtp.

-------
А это иллюстрация того, какие значения мы получим в случае Service unavailable
Dec 9 18:15:52 mail sendmail[6402]: mB9DFnBA006402: syslog:LC0:paradise<@anrb.ru.><e.s><b><d>
Dec 9 18:15:52 mail sendmail[6402]: mB9DFnBA006402: syslog:LC0:user_spb<@mail.ru.><e.r><b><d>
Dec 9 18:15:52 mail sendmail[6402]: mB9DFnBA006402: syslog:LC0:oneuser<@ufamail.ru.><e.r><b><d>
Dec 9 18:15:52 mail sendmail[6402]: mB9DFnBA006402: syslog:LC0:paradiserus<@paradiserus.com.><e.r><b><d>
Dec 9 18:15:52 mail sendmail[6402]: mB9DFnBA006402: syslog:From:<h.s>
Dec 9 18:15:52 mail sendmail[6402]: mB9DFnBA006402: syslog:To:<h.r>
Dec 9 18:15:52 mail sendmail[6402]: mB9DFnBA006402: syslog:eoh:<paradise@anrb.ru><><b><d>
Dec 9 18:15:53 mail sendmail[6402]: mB9DFnBA006402: from=<paradise@ anrb.ru>, size=550450, class=0, nrcpts=3, msgid=<008101c959ff$b6dab990$ee01a8c0@bvk>, proto=ESMTP, daemon=MTA, relay=92.50.138.202.dynamic.ufanet.ru [92.50.138.202]
Это не локальная доставка, поэтому первоначально имеем <i><d>
Dec 9 18:15:54 mail sendmail[6436]: mB9DFnBA006402: syslog:LC0:paradise<@anrb.ru.><e.s><i><d>
Dec 9 18:15:54 mail sendmail[6436]: mB9DFnBA006402:syslog:LC0:paradiserus<@paradiserus.com.><e.r><i><d>
Dec 9 18:15:54 mail sendmail[6436]: mB9DFnBA006402: syslog:LC0:user_spb<@mail.ru.><e.r><i><d>
Dec 9 18:15:54 mail sendmail[6436]: mB9DFnBA006402:syslog:LC0:oneuser<@ufamail.ru.><e.r><i><d>
Dec 9 18:15:54 mail sendmail[6436]: mB9DFnBA006402: to=<paradiserus@paradiserus.com>, ctladdr=<paradise@ anrb.ru> (1572/45), delay=00:00:02, xdelay=00:00:00, mailer=esmtp, pri=730450, relay=daddy.paradiserus.com. [77.238.230.221], dsn=4.2.0, stat=Deferred: 450 4.2.0 <paradiserus@paradiserus.com>: Recipient address rejected: Greylisted, see http://postgrey.schweikert.ch/help/paradiserus.com.html
Dec 9 18:15:56 mail sendmail[6436]: mB9DFnBA006402: to=<user_spb@mail.ru>, ctladdr=<paradise@ anrb.ru> (1572/45), delay=00:00:04, xdelay=00:00:02, mailer=esmtp, pri=730450, relay=mxs.mail.ru. [94.100.176.20], dsn=5.0.0, stat=Service unavailable
Dec 9 18:16:25 mail sendmail[6436]: mB9DFnBA006402: to=<oneuser@ufamail.ru>, ctladdr=<paradise@ anrb.ru> (1572/45), delay=00:00:33, xdelay=00:00:29, mailer=esmtp, pri=730450, relay=cat.ufanet.ru. [81.30.197.10], dsn=2.0.0, stat=Sent (OK id=1LA2MP-000KpE-41)
Доставляем отказы
Dec 9 18:16:25 mail sendmail[6436]: mB9DFnBA006402: syslog:LC0:paradise<@anrb.ru.><e.r><i><d>
Dec 9 18:16:25 mail sendmail[6436]: mB9DFnBA006402: syslog:LC0:paradise<@anrb.ru.><e.r><i><d>
Dec 9 18:16:25 mail sendmail[6436]: mB9DFnBA006402: mB9DGPBA006436: DSN: Service unavailable
Интересен тот факт, что $&{addr_type} в случае MAILER-DAEMON вовсе пустой, это надо взять на заметку и при случае воспользоваться
И только в этом единственном случае при <i><d> мы увидим mailer=local
Dec 9 18:16:25 mail sendmail[6436]: mB9DFnBA006402: syslog:LC0:MAILER-DAEMON<><i><d>
Dec 9 18:16:25 mail sendmail[6436]: mB9DFnBA006402: mB9DGPBA006436: DSN: Service unavailable
Dec 9 18:16:25 mail sendmail[6436]: mB9DGPBA006436: to=<paradise@ anrb.ru>, delay=00:00:00, xdelay=00:00:00, mailer=local, pri=30000, dsn=2.0.0, stat=Sent
Почта была ранее помещена в очередь, поэтому - <i><q>
Dec 9 18:36:40 mail sendmail[14831]: mB9DFnBA006402:syslog:LC0:paradise<@anrb.ru.><e.s><i><q>
Dec 9 18:36:41 mail sendmail[14831]: mB9DFnBA006402:syslog:LC0:paradiserus<@paradiserus.com.><e.r><i><q>
Dec 9 18:36:42 mail sendmail[14831]: mB9DFnBA006402: to=<paradiserus@paradiserus.com>, ctladdr=<paradise@ anrb.ru> (1572/45), delay=00:20:50, xdelay=00:00:01, mailer=esmtp, pri=820450, relay=daddy.paradiserus.com. [77.238.230.221], dsn=2.0.0, stat=Sent (Ok: queued as 5494E5C6E)


5. Мои выводы.

1. Остаюсь при своем мнении: в первый проход $&{DeliveryMode}=b, во второй $&{DeliveryMode}=i, значит, я могу использовать этот макрос в решениях задачек по мршрутизации для оптимизации (сокращения проходов вдвое).
2. Значение OpMode, если sendmail запущен как sendmail- bd -q1h, изменяется в зависмости от mailer'a и успешности/неуспешности доставки:
mailer         OpMode
local         q (исключение - сообщение от MAILER-DAEMON - d)
*file*         q
(e)smtp         d (если доставка была успешной сразу) и q (если письмо было перенаправлено по алиасу или доставка была отложена по причине временного отказа удаленной системы)
NB! newalises или sendmail -bi (кстати, я как-то видела рекомендацию Claus Assmann использовать именно newaliases) дает $&{OpMode}=i.
Мои выводы подкрепляются еще и тем, что в конфиг добавлено вот это:
LOCAL_RULE_0
R$*                                    $: $1 $| <$&{deliveryMode}><$&{opMode}>
R$* $| <b><d>                           $: $1
R$* $| <i><q>                           $: $1
R$* $| <i><d>                           $: $1
R$* $| <i><i>                           $: $1
R$* $| $*                           $: $(syslog syslog:LC0: $1$2 $) $1
И ежедневно делается egrep "syslog:LC0:" maillog. Так вот, пока пусто. 2 месяца прошло.

5. Что следует изменить в решении задачек по маршрутизации с учетом п.5.

Когда почте отказано с временной ошибкой, письмо помещается в очередь. Следующая попытка отправки письма повлечет за собой повторное исполнение LOCAL_RULESET_0. Если это задачка про копирование почты, то почта скопируется еще раз. Отказываться от копирования при OpMode=q нельзя: алиасы и локальные юзеры окажутся неохваченными.
Думаю над этим.


6. Взаимоотношения между DeliverMode & OpMode & queue.

Небольшое разъяснение про DeliveryMode=queue (первоисточник утерян):
"I think you want Odq instead. This will put sendmail in the mode where it will _never_ attempt immediate delivery (foreground or background) of mail it has just received. Instead, it'll just drop the work files into the queue directory. Somewhere around five minutes later, your daemon will wake up and run the queue, and deliver the messages to the gateway. "

А вот очень полезное разЪяснение от Neil W Rickert по поводу взаимоотношений между DeliverMode & OpMode & queue:

>Can someone clarify what the difference is between specifying
>O DeliveryMode=queueonly
>and not setting a queue time or setting it to zero?
>Don't these two options basically result in the same behaviour?

sendmail -bd -q15m
DeliveryMode=background ## the default
Sendmail attempts to send/deliver the mail on arrival, but in a background process. If there is a temporary failure in the attempt to send, then the message is dropped in the queue. Sendmail starts a queue runner every 15 minutes.

sendmail -bd ### no queue interval
DeliveryMode=background ## the default
Sendmail attempts to send/deliver the mail on arrival, but in a background process. If there is a temp failure the message is dropped in the queue. It will stay in the queue forever, unless a queue run is initiated by some other means.

sendmail -bd -q15m
DeliveryMode=queue
The mail is dropped into the queue on arrival. No attempt is made to send/deliver at that time. A queue run is started every 15 minutes. Delivery will be attempted on these queue runs.

sendmail -bd ### no queue interval
DeliveryMode=queue
The mail is dropped into the queue on arrival. It will stay there forever, unless a queue run is initiated elsewhere (via crontab, or manually or with ETRN).

Еще одно объяснение Neil W Rickert
I am currently using:
sendmail -bd -q5m -odq
so that there are queue runs every 5 minutes, but arriving email is queued on arrival. For outbound mail, I do leave the default delivery mode, so that it goes out quickly. It is hard to change that, for some user agents specify the delivery mode on their command line.
At present, much of the outbound mail actually originates on Window clients, so is received with smtp, and goes into the queue until the next queue run.
In my experience, users do not notice the delay of up to 5 minutes.
As an alternative, I tried 'sendmail -bd -q1h -odi'. This should deliver immediately, without forking off a child process. Doing this allows one to control the number of sendmail processes with MaxDaemonChildren. My users immediately noticed the change. The effect was that, submitting mail from a windows email client, the client hung for a while after apparently sending the mail. I have switched back to queueing all incoming mail with 5 minute queue runs and my users are happy again. I also configure MinQueueAge=56m, so that messages are only retried about once per hour.

>So, here is my question:
>Is there a way to make the smtp daemon (/usr/lib/sendmail -bd) to
>deliver interactively all local mail and queue everything else?
>Even better, could it be possible to specify all the "fast delivery hosts"
>(local, virtual hosts in the same machine or other hosts on my local
>network) in a file to do this?

You could mark all mailers expensive, other than the local mailer. Then configure the option HoldExpensive=True, so that these are not sent. I tried this, but did not like it.
The trouble is that some messages will have both a local recipient and a remote recipient. The local recipient will receive the mail immediately. Then the queue file will be marked as having been used. The other recipients will have to wait for the MinQueueAge before they are even tried for the first time. I went back to straight queuing, whereby all recipients are tried within about 5 minutes, and my users don't complain.

---

Обратная связь
Страница создана 24 декабря 2008г. Последнее обновление - 25 декабря 2008г.