Со вчера в maillog на хосте наблюдаю такое поведение (время сегодняшнее – это создавался тикет тестовый):
<code> ----------------------------
# grep pAL8kJda032224  /var/log/maillog
Nov 21 12:46:19 helpdesk sendmail[32224]: pAL8kJda032224: from=<username1@domain.com>, size=2778, class=0, nrcpts=1, msgid=<5A058B7A4BCB6C408C19F292CBBC993941F0B55D@ex3.domain.loc>, proto=ESMTP, daemon=MTA, relay=serv1.domain.loc [*.*.*.555]
Nov 21 12:48:20 helpdesk sendmail[32225]: pAL8kJda032224: timeout waiting for input from local during Draining Input
Nov 21 12:49:20 helpdesk sendmail[32225]: pAL8kJda032224: to="| /etc/smrsh/rt_mailgate --debug --queue Helpdesk --action correspond --url http://*.222.444.888/", ctladdr=<rt-techsupport@helpdesk.domain.net> (8/0), delay=00:03:01, xdelay=00:03:01, mailer=prog, pri=33002, dsn=4.0.0, stat=Deferred: prog mailer (/usr/sbin/smrsh) exited with EX_TEMPFAIL
</code> ----------------------------
тикет создается, его видно в веб-морде и на почту приходит уведомление.
Потом минут через 40 sendmail пытается обработать то, что у него в очереди осталось и создается дубль тикета:
<code> ----------------------------
Nov 21 13:26:18 helpdesk sendmail[32267]: pAL8kJda032224: timeout waiting for input from local during Draining Input
Nov 21 13:27:18 helpdesk sendmail[32267]: pAL8kJda032224: to="| /etc/smrsh/rt_mailgate --debug --queue Helpdesk --action correspond --url http://*.222.444.888/", ctladdr=<rt-techsupport@helpdesk.domain.net> (8/0), delay=00:40:59, xdelay=00:03:00, mailer=prog, pri=123002, dsn=4.0.0, stat=Deferred: prog mailer (/usr/sbin/smrsh) exited with EX_TEMPFAIL
</code> ----------------------------

и так повторяется каждые 40 минут.. за ночь приехало много заявок )
в /var/spool/mqueue скапливаются файлы писем..

до вчера все работало норм, и единственное, что поменялось - я вечером перенес mysql сервер на другой IP.
доступ к нему есть и все работает. только вот появился этот глюк.

тикеты я закрываю с помощью отправки письма в тред со спец командой «Status::: resolved»
По сути – это такое же письмо, как и при создании тикета.
Но.

В логе оно выглядит так:
<code> ----------------------------
# grep pALAFHvZ004150  /var/log/maillog
Nov 21 14:15:17 helpdesk sendmail[4150]: pALAFHvZ004150: from=<username111@domain.com>, size=2861, class=0, nrcpts=1, msgid=<1010B3E13F8D3743A135C08E3BDAF0E00DA9894E@ex3.domain.loc>, bodytype=7BIT, proto=ESMTP, daemon=MTA, relay=serv1.domain.loc [*.*.*.555]
Nov 21 14:15:24 helpdesk sendmail[4151]: pALAFHvZ004150: to="| /etc/smrsh/rt_mailgate --debug --queue Helpdesk --action correspond --url http://*.222.444.888/", ctladdr=<rt-techsupport@helpdesk.domain.net> (8/0), delay=00:00:07, xdelay=00:00:07, mailer=prog, pri=33082, dsn=2.0.0, stat=Sent
</code> ----------------------------
Получено и обработано БЕЗ ошибок. И ессно файл письма удаляется из каталога очереди и оно НЕ дублируется.
Можно увидеть отличие между строчками в логе:
<code> ----------------------------
Nov 21 12:46:19 helpdesk sendmail[32224]: pAL8kJda032224: from=<username1@domain.com>, size=2778, class=0, nrcpts=1, msgid=<5A058B7A4BCB6C408C19F292CBBC993941F0B55D@ex3.domain.loc>, proto=ESMTP, daemon=MTA, relay=serv1.domain.loc [*.*.*.555]

Nov 21 14:15:17 helpdesk sendmail[4150]: pALAFHvZ004150: from=<username111@domain.com>, size=2861, class=0, nrcpts=1, msgid=<1010B3E13F8D3743A135C08E3BDAF0E00DA9894E@ex3.domain.loc>, bodytype=7BIT, proto=ESMTP, daemon=MTA, relay=serv1.domain.loc [*.*.*.555]
</code> ----------------------------
это некий параметр "bodytype=7BIT"

Я прихожу к выводу, что /etc/smrsh/rt_mailgate почемуто не может распарсить письма от юзеров именно из-за этого параметра и поэтому возникает ошибка.
Просмотр логов за пятницу показал, что этот параметр ПРИСУТСТВУЕТ в логе при создании тикетов юзерами, например:
<code> ----------------------------
Nov 18 17:13:31 helpdesk sendmail[6961]: pAIDDVLK006961: from=<username2@domain.com>, size=4731, class=0, nrcpts=1, msgid=<BC04E45885C95B4F9B2AC74F48A704D01EACD471@ex3.domain.loc>, bodytype=7BIT, proto=ESMTP, daemon=MTA, relay=serv1.domain.loc [*.*.*.555]
</code> ----------------------------
А сегодня уже не присутствует.

Хотя мое предположение врядли верное.. тут чтото другое.

что это может быть и как бороться ?