Exim, свой «фильтр»

А какая задача решается? Мне кажется использование почтового сервера тут крайне лишнее, если возникает мысль пересылать письма по 500метров то что-то явно не так. Тем более что формат почтовых сообщений неэффективен для хранения бинарных данных(во-первых, надо их ещё раскодировать, во-вторых, письмо весит больше чем все вложенные в него файлы) и вообще для обработки.

Ну тут как бы вариантов нет.
Это все касается сдачи электронной отчетности. На это есть регламентирующие документы. И это должно работать по smtp.

Так вот надо письмо получить. Посмотреть куда его отправить (понять это можно только открыв письмо и распарсив xml). Подписать своим сертификатом. И отправить в две стороны подписанное письмо.

Как-то так.

Случаи с 500 метровыми файлами редкие, но бывают. И бывают они как обычно в последний день месяца и все сразу.

procmail же!

(а зачем тут сервер?, мне fetchmail'а хватает)

Да, и как уже сказали - неэффективно. из 6и бит получается 8 бит, соответственно из 6Мб получится 8Мб почты. Хотя - дело ваше.

насколько я понял это можно сделать через pipe и shadow_copy, но меня смущает, что при этом будет

зря боитесь - PIPE никогда не ложится на диск. А что касается временного файла - смонтируйте /tmp в RAM. Это и с т.з. безопасности полезно, и работает быстро.

>procmail же!
гляну. спасибо.

(а зачем тут сервер?, мне fetchmail'а хватает)

Э...
Ну каким еще образом принимать почту от 123@domain.tld в inbox@domain.tld. ну и потом ее уже пересылать на 321@domain_2.tld
??

Да, и как уже сказали - неэффективно. из 6и бит получается 8 бит, >соответственно из 6Мб получится 8Мб почты. Хотя - дело ваше.

Есть закон. :)

зря боитесь - PIPE никогда не ложится на диск

ну на диск то не ложится...
Но при этом будет копирование в памяти через pipe
Т.е. лишний ресурс все равно тратится.

>Э... Ну каким еще образом принимать почту от 123@domain.tld в inbox@domain.tld. ну и потом ее уже пересылать на 321@domain_2.tld ??

у меня - fetchmail+procmail+msmtp. Последняя програмулька отправляет, первая принимает, а вторая сортирует, что куда складывать. Она-же может выполнить любую команду, в т.ч. и отправку.

Вообще-то Ъ админы юзают sendmail, но я в нём не стал разбираться - слишком сложно.

Т.е. лишний ресурс все равно тратится.

копирование выполняется через небольшой буфер в RAM. У вас есть способ лучше? Так вот, ваш «новый способ» будет заведомо хуже PIPE. Или это будет PIPE. ;)

я же писал про local_scan

Так вот он передает fd в функцию.

Т.е. не надо ничего копировать. Тебе отдали файловый дескриптор и с ним и работаешь.

Но с ним проблема в том, что он вызывается не на том этапе.

drBatty> fetchmail

Не принимает (по smtp), а вытягивает (по pop3/imap) — разница есть, да?

Вообще-то Ъ админы юзают sendmail

ну нах его :). Он нравится только тем кто убил кучу времени на изучение m4 и теперь не знают куда девать свои знания.

а откуда письмо получается? Может не создавать лишних сущностей а сразу генерить подписанные письма и слать?

PS бедный спул, письма по 500метров...

PPS не разбираюсь в бухгалтерии, но нифигаж себе отчётность на 500 метров. Или это от xml так разбухает?

>а откуда письмо получается? Может не создавать лишних сущностей а сразу генерить подписанные письма и слать?

Письмо от клиента. Мы звено по середине. Письмо подписано клиентом. Но так - же подписывается и нами.

PS бедный спул, письма по 500метров...

Это редкость и крайний случай. Но он будет каждый месяй/квартал.
Причем будет куча куда более мелких писем (на порядок-два).
Но проблема в том, что нужно рассчитывать, что весь поток почты будет приходить в течении недели...

PPS не разбираюсь в бухгалтерии, но нифигаж себе отчётность на 500 метров. Или это от xml так разбухает?

Xml... Но дело не столько в нем. Это один из видов отчетов. Среднесписочная численность сотрудников. Из этого вытекает что таких, у кого этот файл будет большой не так много...

Еще возникла мысль...
По идее же можно использовать incron.
Натравить его на нужный каталог (в каталог, куда будет сваливаться вся входящая почта)

Сейчас попробовал... Работает и нужный скрипт вызывается (событие ON_MOVED_TO)...
Вроде все он.

Но смущает что будет при нагрузке и куче одновременных (или почти одновременных) событий.

Кто-нибудь использовал его для чего-то серьезного.

Т.е. хотелось бы быть уверенным, что он не упадет и будет работать ожидаемо...

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

согласен.

В общем читайте доку, она рулез :)
Все оказалось гораздо проще.
Через pipe можно передать то, что нужно. И имя файла с письмом в том числе.

Поторопился...
Имя файла мне отдавал костыль на incrond
А вот через пайп гонится все письмо...

А вот через пайп гонится все письмо...

Ну и что? :-) В случае procmail, письмо лежит и в файле, и прогоняется через pipe. В любом случае, 500 мегабайт через pipe...

$ time { dd if=/dev/zero bs=512 count=1024k | cat >/dev/null ; }
1048576+0 records in
1048576+0 records out
536870912 bytes (537 MB) copied, 1,37433 s, 391 MB/s

real	0m1.383s
user	0m0.234s
sys	0m2.174s

Полторы секунды. Проблем то?

>Ну и что? :-)
да я уже смирился :)

В любом случае, 500 мегабайт через pipe...

ну в /dev/null то не интересно

Вот мой результат в тестовой виртуалке:

root@mta:~# du -s msg.64
414992   msg.64

root@mta:~# time cat msg.64 > /dev/null

real   0m0.411s
user   0m0.016s
sys   0m0.388s

root@mta:~# time cat msg.64 > msg.64.1

real   0m9.989s
user   0m0.028s
sys   0m3.732s