29 ответов в этой теме

[Medlar]

Поэтому и выбирается вариант "попытаться отправить позже, в соответствии с интервалами отложенной отправки"

Честно говоря, на фоне проблем, порождаемых данной ситуацией , сама по себе отложенная отправка писем из failed меня волнует мало. На данный момент все 9 застрявших писем - это полуспам. Если там застрянет важное письмо, я найду способ доставить его получателю.

Меня гораздо больше волнует застревание почты в /var/drweb/msgs/out и не удаление почты из /var/drweb/msgs/in.
Я не могу предусмотреть ВСЕГО. Например, в сентябре одно из проблемных писем высылалось отправителем несколько раз за сутки.
Хорошо, если отправитель всегда будет соблюдать разумный интервал отправки. А если он начнет лупить эти письма очередью? Да у меня скрипт только и будет рестартовать демоны, и если меня не будет рядом, то хаоса не избежать.

Я написала рулсеты к sendmail.cf, отрабатывающие те ограничения, которые у меня сработали, на этапе smtp-диалога.
Так что проблем, вызванных именно "too many hops" & "headers too large" я , скорее всего, смогу избежать.
Надо будет показать рулсеты sendmail-гуру, но я уже предвижу ответ Claus Assmann, что это конкретный изврат...
И мне ... придется наябедничать - не обессудьте ...

Но! Еще остаются другие ограничения, и вот, например, это - message size exceeds maximum - я не смогу обработать на этапе smtp-диалога по понятной причине.

Теперь по поводу застревания почты в /var/drweb/msgs/in.
18 октября и 12 ноября в часы пиковой нагрузки drweb засбоил. В октябре была внешняя конкретная атака, пришлось drweb отключить на часок. В ноябре уже мои юзеры постарались. К самому факту сбоя претензий не имею (сервер Intel® Core™2 Duo CPU E8400 @ 3.00GHz, ОП 2Gb) - в планах переезд на более мощный сервер.

Претензии мои к тому, что вся почта осталась навеки в /var/drweb/msgs/in (347 писем) несмотря на то, что она была доставлена получателям.
Скрипт написала, убедилась в доставке каждого письма. Обработку логов ЗНАЧИТЕЛЬНО усложнило то, что в половине случаев DrWeb не записывал в лог номер директории, и при отсутствии в Received: номера sendmail-процесса идентификация писем происходила на основе sender&recipient, выцарапанных из файла .envelope, и IP&date&time&msgid(если_он_вообще_был) из .msg.
/var/drweb/msgs/in/2/000A5892.msg:

...

Как вы, наверное, догадываетесь, на это ушла уйма времени.
И еще, наверное, вы догадываетесь, что у меня есть более важные занятия, нежели постоянно караулить наполнение директорий out & in, а потом бесконечно обрабатывать логи.
В общем, мне не весело. Я В УНЫНИИ. НЕ ЗНАЮ, КАК ВЫ ...

Сообщение было изменено userr: 14 Ноябрь 2012 - 20:02
скрыл частную инфу.

[userr]

Medlar,
Скрыл частную инфу. Вам имхо лучше написать в Поддержку.

updated
хотя увидел, что в других письмах темы это все тоже есть...

[Medlar]

У меня нет здесь частной информации. НЕТ. Адреса моих пользователей могут появиться в Сети только в одном случае: если они сами того пожелают (либо попросят указать в качестве контактного email на нашем сайте, либо оставят свой адрес в Сети сами).
Во всех примерах, которые я выкладываю у себя на сайте или на сторонних форумах, используются адреса-ловушки (http://linux.ufaras.ru/sendmail2.html#9).
Так что возвращаю то, что вы затерли:
/var/drweb/msgs/in/2/000A5892

Received: from pip251.ipost.com ( pip251.ipost.com [64.84.6.251] )
by mail.anrb.ru (Dr.Web ® milter module ver.6.0.2.0)
; Thu, 18 Oct 2012 13:11:31 +0600

Oct 18 13:12:01 mail sendmail[19220]: q9I7BSbF019220: syslog:rcpt:O1:<terrapin@anrb.ru>
Oct 18 13:12:23 mail sendmail[19220]: q9I7BSbF019220: syslog:eoh_auth:1:<>
Oct 18 13:12:41 mail sendmail[19220]: q9I7BSbF019220: from=<errors+9z1zfpoa8ktcipk3e5746hlk048977so0jr4f7i6st0@support1.superarraybioscience.com>, size=19339, class=0, nrcpts=1, msgid=<1350543810.22509.0.461521@support1.superarraybioscience.com>, proto=ESMTP, daemon=MTA, relay=pip251.ipost.com [64.84.6.251]
Oct 18 13:20:43 mail sendmail[19220]: q9I7BSbF019220: Milter (drweb-filter): timeout before data read, where=eom
Oct 18 13:20:46 mail sendmail[19220]: q9I7BSbF019220: Milter (drweb-filter): to error state
Oct 18 13:20:48 mail sendmail[23622]: q9I7BSbF019220: to=<terrapin@anrb.ru>, delay=00:08:46, xdelay=00:00:00, mailer=local, pri=49642, dsn=2.0.0, stat=Sent

Впредь буду отмечать это ОСОБО.
А адреса отправителей во всех приведенных примерах были оставлены как есть, потому что это был спам.

[Medlar]

Возможно сумеем придумать как это обойти, но пока свежих идей нет.

У меня есть идея! ЕСТЬ!
Я подняла старые записи и обнаружила, что еще в 2006г. в плюсы СПамообороне записала следующее:" Если письмо пришло нескольким получателям, а один из них не указан в списке проверяемых адресов, то письмо для этого пользователя также будет проверено. "

Главный итог моего расследования был такой: "Итак, нет разнородных юзеров в получателях письма -> нет клонов письма -> нет инициированного drweb'ом дополнительного sendmail-процесса -> нет отказа (в случае, если есть причина для отказа) -> нет проблемы зависания писем для непривилегированных пользователей в /var/drweb/msgs."

МНе кажется в создавшейся ситуации было бы разумным не мелочиться и не исключать из проверки непривилегированного пользователя, то есть тем самым не формировать клоны для доставки письма непривилегированному пользователю и не порождать проблемы.

Какой смысл в этом исключении, если проверка пройдет все равно: ведь в списке получателей есть привилегированные пользователи, И ПИСЬМО БУДЕТ ОБЯЗАТЕЛЬНО ПРОВЕРЕНО! От DrWeb не убудет (или "армия не обеднеет", как говорили в советские времена), если он сделает одну маааааленькую работку - пометит полученное письмо спам-меткой. И доставит письмо в рамках исходного процесса.

Мне сложно представить, что я должна сделать, как извратиться и что придумать, чтобы использовать этот момент для незаконного увеличения количества проверяемой почты. Ясно, что для этого нужно на определенном этапе переписывать заголовок так,чтобы в числе получателей оказался один привилегированный получатель, тогда заведомо вся почта будет проверяться.
На данный момент я не представляю, как это можно реализовать.

[userr]

У меня нет здесь частной информации. НЕТ.
...
Так что возвращаю то, что вы затерли:

1. Я эту информацию только скрыл из общего доступа, она осталась на форуме и доступна специалистам.
2. Хорошо, я понял и больше Ваши письма не трогаю.
3. Тем не менее предложение написать в Поддержку остается. Со ссылкой на эту тему.

[valya krasnoglazova]

вы подтверждаете, что в последней версии этой проблемы нет?

багфикс для MailD продуктов готовится к выпуску, были выпущены багфиксы для остальных компонентов и продуктов, кроме пакетов drweb-maild, в т.ч. был багфикс для drweb-daemon

[valya krasnoglazova]

... почта скапливается не только в /var/drweb/msgs/out & /var/drweb/infected/def/drweb, но и в /var/drweb/msgs/in:
find /var/drweb/msgs/in -type d|egrep -c "000[0-9A-Z]{5}" = 161

скопление в /var/drweb/msgs/in скорее всего вызвано тем, что в Sendmail при ожидании обработанного Xdrweb-milter'ом письма успевают истечь либо:

- таймаут на соединение с Xdrweb-milter
- таймаут на ожидание ответа от Xdrweb-milter ®

это sendmail.cf, секция настроек xdrweb-milter:

Xdrweb-milter, S=local:/var/drweb/ipc/drweb-milter.sock, F=T, T=C:5m;S:5m;R:5m;E:1h

C - таймаут на соединение с Xdrweb-milter (в старых версиях sendmail он был всего 1 минуту, желательно увеличить до 5)
R - таймаут на ожидание ответа - желательно сделать его больше или равным General/IpcTimeout в maild_sendmail.conf

это все описано в разделе 6 readme

[valya krasnoglazova]

насчет вынужденного на тек. момент рестарта drweb-sender и срабатывания лимитов в Sendmail - при попытке заинжектить клон обработаного письма:

1. рестарт приходится делать из-за бага в drweb-sender (баг в общем и целом можно описать как кратковременные приступы склероза при отправке обработанных), баг этот не связан ни с клонированием, ни c тонкостями взаимодействия с Sendmail, только с фазами Луны. В следующем багфиксе будет поправлен.

2. срабатывание лимитов в sendmail.cf при попытке инжекта клона:

- sendmail в этом случае, как видно по приведенному логу, генерирует DSN для постмастера
- drweb-sender начинает отложенную отправку, что вызывает вопросы -----> это поведение будет, скорее всего, поправлено в 6.0.2, и описано в разделе Интеграция с sendmail

т.е., вероятный, ход действий для версии багфикса: если "object = /usr/sbin/sendmail -i -bm -f " - вызванный drweb-sender'ом завершился с ошибкой, в зависимости от Sender/SendDSN = yes - будет генерироваться DSN, а письмо сразу перемещаться в out/failed

Но! Еще остаются другие ограничения, и вот, например, это - message size exceeds maximum - я не смогу обработать на этапе smtp-диалога по понятной причине.

- тут только увеличивать maximum message size на размер = размеру добавляемых для клона хидеров, это число рассчитываемо

3. проблемы клонирования

Главный итог моего расследования был такой: "Итак, нет разнородных юзеров в получателях письма -> нет клонов письма -> нет инициированного drweb'ом дополнительного sendmail-процесса -> нет отказа (в случае, если есть причина для отказа) -> нет проблемы зависания писем для непривилегированных пользователей в /var/drweb/msgs."
МНе кажется в создавшейся ситуации было бы разумным не мелочиться и не исключать из проверки непривилегированного пользователя, то есть тем самым не формировать клоны для доставки письма непривилегированному пользователю и не порождать проблемы.
Какой смысл в этом исключении, если проверка пройдет все равно: ведь в списке получателей есть привилегированные пользователи, И ПИСЬМО БУДЕТ ОБЯЗАТЕЛЬНО ПРОВЕРЕНО! От DrWeb не убудет (или "армия не обеднеет", как говорили в советские времена), если он сделает одну маааааленькую работку - пометит полученное письмо спам-меткой. И доставит письмо в рамках исходного процесса.

при обработке клонирование делается из-за необходимости применять разные правила для получателей из разных групп (файлы со списками, regex и пр., где перечислены адреса), в случае когда тело одно.

Т.е. убирание правила из конфига, или перегруппировка получателей, или и то и другое сразу - прекращает клонирование письма, письмо остается одним и тем же на всех стадиях обработки и проверяется всеми заданными плагинами, увеличивается скорость обработки.

в нашем случае клонирование вызывают SETTING'и "scan=all:-plugin", "scan=all", "scan=no" - которые применяется к письму, только если отправитель/получатель из определенной группы - попробовать модифицировать правила.
От maild точно также не убудет проверять vaderetro'й и исходящие из защищамого домена письма на спам.

4. про логи

Обработку логов ЗНАЧИТЕЛЬНО усложнило то, что в половине случаев DrWeb не записывал в лог номер директории, и при отсутствии в Received: номера sendmail-процесса идентификация писем происходила на основе sender&recipient, выцарапанных из файла .envelope, и IP&date&time&msgid(если_он_вообще_был) из .msg.

по возможности просьба приаттачить примеры подобных логов, которые захватывают половину случаев, когда DrWeb не записывал в лог номер директории. Не исключено, что баги в логировании.

5.

18 октября и 12 ноября в часы пиковой нагрузки drweb засбоил.

Претензии мои к тому, что вся почта осталась навеки в /var/drweb/msgs/in (347 писем) несмотря на то, что она была доставлена получателям.

неплохо бы увидеть логи drweb и mail за эти даты, чтобы понять, почему все осталось в /var/drweb/msgs/in.

как уже написала выше, проблема скорее всего в таймаутах, но в любом случае, нам надо увидеть это все в логах

Сообщение было изменено valya krasnobaeva: 15 Ноябрь 2012 - 18:46

[GrayCat]

неплохо бы увидеть логи drweb и mail за эти даты, чтобы понять, почему все осталось в /var/drweb/msgs/in.

а вы возьмите мои - и логи, и msgs
там ровно та же ситуация - письма из msgs/in никуда не делись

[valya krasnoglazova]

а вы возьмите мои - и логи, и msgs
там ровно та же ситуация - письма из msgs/in никуда не делись

спасибо, чем больше, тем лучше