sendmail отсутствуют вложения

Милтеров ни каких нет.

Сам sendmail в письма не лезет, так что ты чего-то не знаешь о своей системе.

смотри дебаг (-d 15 к примеру)

Поддерживаются следующие флаги отладки:

-d0 Общая отладка.
-d1 Показать информацию об отправке.
-d2 Закончить на finis( ).
-d3 Распечатать среднюю загрузку.
-d4 Места на диске достаточно.
-d5 Показать события.
-d6 Показать необработанные почтовые сообщения.
-d7 Имя файла очереди.
-d8 Преобразование имен DNS.
-d9 Трассировка запросов RFC1413.
-d9.1 Создать каноническое имя для хоста.
-d10 Показывать уведомление о доставке получателю.
-d11 Трассировать доставку.
-d12 Показать подключение зависимого хоста.
-d13 Показывать уведомление о доставке.
-d14 Показать запятые в полях заголовков.
-d15 Показать действия по получению сетевых запросов.
-d16 Инициируемые соединения.
-d17 Показать список хостов MX.

и sendmail.cf покажи

Милтеры:

/etc/mail# grep -i milter sendmail.mc
dnl # define(`confMILTER_MACROS_HELO', confMILTER_MACROS_HELO``, {verify}'')
dnl # define(`confMILTER_MACROS_ENVRCPT', confMILTER_MACROS_ENVRCPT``, {greylist}'')
dnl # INPUT_MAIL_FILTER(`greylist', `S=local:/var/run/milter-greylist/milter-greylist.sock, F=T, T=R:30s')

sm-mta[30380]: pBDBHKQX030380: from=<....>, size=530398 

sendmail[30383]: pBDBHPDG030383: ...., size=14790, class=0, nrcpts=3

Конфиг показать не могу...

а mc и cf точно соответствуют друг другу?

grep MaxMessageSize sendmai.cf ?

систему настрайвал сам )

про sendmailconfig точно знаю и по датам создания mc->cf делается...

sm-mta[30380]: pBDBHKQX030380: from=<....>, size=530398
sendmail[30383]: pBDBHPDG030383: ...., size=14790, class=0, nrcpts=3
Сообщение одно и то же (по равному msgid)

А где msgid ? Вот по queue id разное получается.... Выборку по pBDBHKQX030380 можно посмотреть ? И это... Раз sm-mta, отправитель локальный, да ?

У вас там не такая простая конфигурация, там два sendmail'а, ещё поди фильтры какие есть. Может там вобще идёт другое письмо с уведомлением, что в том письме был вирус?

ЕМНИП, sm-mta это бесправный (без прав root'а) sendmail, который только принимает почту по 25-ому порту и складывает в очередь. А отпаравляет почту дальше уже другой sendmail.

У вас там не такая простая конфигурация, там два sendmail'а,

Два Sendmail уже давно. С 8.13, кажется, такая конфигурация используется.

ЕМНИП, sm-mta это бесправный (без прав root'а) sendmail,

Это да, бесправный.

который только принимает почту по 25-ому порту

А тут - нет. Наоборот, это тот sendmail, который локальную почту обрабатывает, например, отправляемую через mail и т.п. А который на 25-ом порту слушает, от root работает.

смысл такой: принимается письмо sm-mta, это собственно всего навсего префикс записи в лог(по крайней мере я так понимаю(в системе не такого бинарника, и это является параметром опции -L sm-mta в init скрипте) при пересылке идет уже просто процесс sendmail.

лог:

Dec 13 15:17:25 <server> sm-mta[30380]: pBDBHKQX030380: from=<..1.>, size=530398, class=0, nrcpts=2, msgid=<201112131117.pBDBHKQX030380@<мой хост>>, proto=ESMTP, daemon=IPv4, relay=<чужой реллей>
//Видим уменьшение размера с 530398 до 14790...
Dec 13 15:17:25 <server> sendmail[30383]: pBDBHPDG030383: from=..1., size=14790, class=0, nrcpts=3, 
//Всё верно:
msgid=<201112131117.pBDBHKQX030380@<мой хост>>, relay=root@localhost
Dec 13 15:17:26 <server> sendmail[30385]: pBDBHPDG030383: to=<..ориг. адресат.>, delay=00:00:01, xdelay=00:00:01, mailer=esmtp, pri=194790, relay=<правильный реллей>, dsn=2.0.0, stat=Sent (ok:  Message 9123948 accepted)
//всё верно:
Dec 13 15:17:26 <server> sendmail[30385]: pBDBHPDG030383: to=<...кому копия.>, delay=00:00:01, xdelay=00:00:00, mailer=esmtp, pri=194790, relay=<ещё один правильный реллей>, dsn=2.0.0, stat=Sent ( <201112131117.pBDBHKQX030380@<....>> Queued mail for delivery)
netstat -ntpl | grep -i 25
tcp        0      0 0.0.0.0:25              0.0.0.0:*               LISTEN      13175/sendmail: MTA

Вообще, мейлер не простой, он копирует почту. Но тут претензий ни каких.

Такая конфигурция с 8.12, но ТС говорил про самостоятельную настройку системы.

Зачем для слушанья 25-го порта права рута? Для избежания этого и городили два sendmail'а.

grep MaxMessageSize sendmail.cf
#O MaxMessageSize=0

Dec 13 15:17:25 <server> sm-mta[30380]: pBDBHKQX030380: from=<..1.>, size=530398,
class=0, nrcpts=2, msgid=<201112131117.pBDBHKQX030380@<мой хост>>, proto=ESMTP, daemon=IPv4, relay=<чужой реллей>

А где строчка с pBDBHKQX030380 и «stat=Sent» ? То, что relay=<чужой реллей>, действительно, должно означать, что это тот sendmail, который слушает...

//Видим уменьшение размера с 530398 до 14790...
Dec 13 15:17:25 <server> sendmail[30383]: pBDBHPDG030383: from=..1., size=14790, class=0, nrcpts=3,

В каком месте из queue id pBDBHKQX030380 получилось pBDBHPDG030383 ?

Зачем для слушанья 25-го порта права рута? Для избежания этого и городили два sendmail'а.

В общем-то, незачем. Но два городили, всё же, чтобы не давать лишних прав локально запускаемому sendmail. Который на 25-ом порту, тот использует sendmail.cf для работы, а локально запускаемый - submit.cf.

Почем-то показалось, что «sm» в «sm-mta» может означать submit. Был неправ видимо.

Зачем для слушанья 25-го порта права рута ?

Они затем, чтобы можно было локальный майлер запустить, который по майлбоксам почту раскладывает. Оно не нужно, если, например, lmtp используется и какой-нибудь Dovecot/Cyrus/разное. А, если, нет ?

Проблему решили... Приходило письмо содержащее среди прочего точку на пустой строке в блоке между границами(boundary), в очередь оно принималось нормально, а кода мейлером разгребалась очередь (читал из файла) он на этой точке и обнаруживал конец письма. Для мейлера в описании есть ключ -i который заставляет игнорить эти точки. Вопрос только кто виноват в таком поведении: клиент отправивший письмо, или мой почтовик, который по идее должен читать multipart не до точки а до обнаружения границы. Всё же я склоняюсь что клиент не прав так как по RFC - точка на пустой строке это конец письма.