Коллеги помогите советом.
Есть скрипт sender.sh содержащий одну строку:
cat mess.txt | mutt -x -s "Тема" -a "file" user@host.ru
Отправляет почту на указанный адрес через консольного почтового клиента mutt+msmtp(для отправки через smtp сервер).
при запуске sender.sh письмо уходит, при настройке запуска по cron скрипт запускается, но письмо не уходит. на sender.sh права полные. В которую сторону покопать можно?
>Коллеги помогите советом.
>Есть скрипт sender.sh содержащий одну строку:
>cat mess.txt | mutt -x -s "Тема" -a "file" user@host.ru
>Отправляет почту на указанный адрес через консольного почтового клиента mutt+msmtp(для отправки через
>smtp сервер).
>при запуске sender.sh письмо уходит, при настройке запуска по cron скрипт запускается,
>но письмо не уходит. на sender.sh права полные. В которую сторону
>покопать можно?В сторону указывания полных путей ко всем файлам, упомянутым в скрипте. Подсказка: mutt - тоже
файл.
>В сторону указывания полных путей ко всем файлам, упомянутым в скрипте. Подсказка:
>mutt - тоже
>файл.Не помогло
>В сторону указывания полных путей ко всем файлам, упомянутым в скрипте. Подсказка:
>mutt - тоже
>файлНе помогло
>>В сторону указывания полных путей ко всем файлам, упомянутым в скрипте. Подсказка:
>>mutt - тоже
>>файл
>
>Не помоглопокажите строчку из crontab-а и текст скрипта который не работает.
>[оверквотинг удален]
>>cat mess.txt | mutt -x -s "Тема" -a "file" user@host.ru
>>Отправляет почту на указанный адрес через консольного почтового клиента mutt+msmtp(для отправки через
>>smtp сервер).
>>при запуске sender.sh письмо уходит, при настройке запуска по cron скрипт запускается,
>>но письмо не уходит. на sender.sh права полные. В которую сторону
>>покопать можно?
>
>В сторону указывания полных путей ко всем файлам, упомянутым в скрипте. Подсказка:
>mutt - тоже
>файл.какой интерпретатор стоит у скрипта sender.sh: "#!/bin/bash" | "#!/bin/sh" | "#!/bin/ksh"
боюсь соврать но вроде крон използует, ksh
>боюсь соврать но вроде крон използует, kshman 5 crontab
/bin/sh по умолчанию
>какой интерпретатор стоит у скрипта sender.sh: "#!/bin/bash" | "#!/bin/sh" | "#!/bin/ksh"
>боюсь соврать но вроде крон използует, kshСтоит
#!/bin/shДа забыл указать что FreeBSD 7 у меня
Строка из крона*/5 * * * * root /tmp/sender.sh
По логам крона скрипт sender.sh был запущен. Но вот почту не отправил.
Скрипт еще вычисляет предыдущую дату но не суть.Я его урезал до двух строк чтобы протестить саму отправку#!/bin/sh
cat /tmp/mess.txt | /usr/local/bin/mutt -x -s "Тема" user@host.ru
>
>>какой интерпретатор стоит у скрипта sender.sh: "#!/bin/bash" | "#!/bin/sh" | "#!/bin/ksh"
>>боюсь соврать но вроде крон използует, ksh
>
>Стоит
>#!/bin/sh
>
>Да забыл указать что FreeBSD 7 у меняЕще раз:
покажите строчку из crontab-а и текст скрипта который не работает, в том виде в котором он сейчас!!! не работает.Телепатов нет..
>Телепатов нет..Выше смотри
>
>>Телепатов нет..
>
>Выше смотриНе ...
Видимо нато полный путь к cat тоже прописать
>Да забыл указать что FreeBSD 7 у меня
>Строка из крона
>
>*/5 * * * * root /tmp/sender.shа точна в системном строка прописана, а не в пользовательском?
(кста, а зачем в системном? чем юзерский не устраивает)>По логам крона скрипт sender.sh был запущен. Но вот почту не отправил.
>#!/bin/sh
>cat /tmp/mess.txt | /usr/local/bin/mutt -x -s "Тема" user@host.ruну таки если написать:
cat /tmp/mess.txt > /tmp/mess2.txt
файл /tmp/mess2.txt появицца? (содержимое правильное?)
далее в логах не крона, а в почтовых логах что будет по поводу отправки письма?
далее продолжаем тупое дебаженье:
/usr/local/bin/mutt >/tmp/xxx.log 2>/tmp/xxx2.log
все ожидаемо?)PS и это, полный путь к cat, плз =)
>PS и это, полный путь к cat, плз =)Ну это уже слишком, IMHO. cat обычно лежит в /bin, а /bin обычно по умолчанию есть в $PATH у кронтаба.
>>PS и это, полный путь к cat, плз =)
>
>Ну это уже слишком, IMHO. cat обычно лежит в /bin, а /bin
>обычно по умолчанию есть в $PATH у кронтаба.Я тоже думаю что полные пути излишни. Но все равно попробую.
Всем спасибо за отзывы. FreeBSD на работе завтра доберусь все советы протестирую.
О результатах доложу.
>Я тоже думаю что полные пути излишни.Полные пути нужны только к тем командам, которые находятся в каталогах не перечисленных в $PATH кронтаба. Т.е., для всяких там /usr/local/bin и прочих /opt пути полные писать надо, но вот /bin и /usr/bin, там обычно по умолчанию есть.
>>Я тоже думаю что полные пути излишни.
>
>Полные пути нужны только к тем командам, которые находятся в каталогах не
>перечисленных в $PATH кронтаба. Т.е., для всяких там /usr/local/bin и прочих
>/opt пути полные писать надо, но вот /bin и /usr/bin, там
>обычно по умолчанию есть.Полные пути не нужны вовсе. Для этого в начале скрипта должна присутствовать строка:
PATH="/bin:...:${PATH}"; export PATH;
>[оверквотинг удален]
>>
>>Полные пути нужны только к тем командам, которые находятся в каталогах не
>>перечисленных в $PATH кронтаба. Т.е., для всяких там /usr/local/bin и прочих
>>/opt пути полные писать надо, но вот /bin и /usr/bin, там
>>обычно по умолчанию есть.
>
>Полные пути не нужны вовсе. Для этого в начале скрипта должна присутствовать
>строка:
>
>PATH="/bin:...:${PATH}"; export PATH;работает для утилит аля cat, но для менее известных, и возможно устанавливаемых во всякие /usr/local/bin, /home/me/bin не сильно спасает.
к примеру:
PATH=/bin:/usr/bin:/usr/local/bin:/usr/local/mega_project/bin
mega_utility 1 2 3 4шо будит если mega_utility будет установлена дважды, первый раз в /usr/local/bin, второй раз в /usr/local/mega_project/bin новая версия с патчем закрывающим гига-дыру (вот такая невнимательность ссзб-одмина). утилита не из репозиториев, а своя какая-нить.
>к примеру:
>PATH=/bin:/usr/bin:/usr/local/bin:/usr/local/mega_project/bin
>mega_utility 1 2 3 4
>
>шо будит если mega_utility будет установлена дважды, первый раз в /usr/local/bin, второй
>раз в /usr/local/mega_project/bin новая версия с патчем закрывающим гига-дыру (вот такая
>невнимательность ссзб-одмина). утилита не из репозиториев, а своя какая-нить.Пример глупый и некрасивый. Если программное обеспечение свое ("утилита") -- скрипт тоже свой. Никто не мешает использовать:
PATH="/usr/local/mega_project/bin:${PATH}"Системный пути из cron(a) достаточно просто наследовать, имхо.
>Пример глупый и некрасивый.зато из жизни.
> Если программное обеспечение свое ("утилита") -- скрипт тоже
>свой. Никто не мешает использовать:
>PATH="/usr/local/mega_project/bin:${PATH}"теперь закидываем в этот каталог что-нить левое под именем cat и понеслось.
>>Пример глупый и некрасивый.
>
>зато из жизни.
>> Если программное обеспечение свое ("утилита") -- скрипт тоже
>>свой. Никто не мешает использовать:
>>PATH="/usr/local/mega_project/bin:${PATH}"
>
>теперь закидываем в этот каталог что-нить левое под именем cat и понеслось.Если у злоумышленника есть доступ на запись в /usr/local/mega_project, а ваш скрипт использует абсолютный путь /usr/local/mega_project/mega_tool. Ничто не помешает ему заменить этот mega_tool своим. Именно по этому еще раз подчеркиваю пример не из жизни и более чем академический интерес не представляет.
>[оверквотинг удален]
>>> Если программное обеспечение свое ("утилита") -- скрипт тоже
>>>свой. Никто не мешает использовать:
>>>PATH="/usr/local/mega_project/bin:${PATH}"
>>
>>теперь закидываем в этот каталог что-нить левое под именем cat и понеслось.
>
>Если у злоумышленника есть доступ на запись в /usr/local/mega_project, а ваш скрипт
>использует абсолютный путь /usr/local/mega_project/mega_tool. Ничто не помешает ему заменить этот mega_tool
>своим. Именно по этому еще раз подчеркиваю пример не из жизни
>и более чем академический интерес не представляет.Ну нет права записи у злоумышленника, даже самого злоумышленника нет :)
Есть стечение обстоятельств при которых в пути поиска обнаруживается утилита с другой версией (или с иными ключами ком. строки) или вообще с таким же именем что и в скрипте, но обнаруживается раньше и делающая совсем не то что надо, не обязательно что это главная утилита скрипта, так мелкая второстепенная утилитка, а скрипт может юзать десятки таких утилит и все они разбросаны по каталогам. Утилита может там оказаться в результате установки более новой версии другого софта, установка произойдет позже чем установлен и проверен на работоспособность скрипт. Устанавливать будет другой человек, через год-другой. В итоге неожиданно что-нить сломается. Даже то что скрипт просто выдаст ошибку имеет свое значение. Да правка на 2 мин, но все же.
>Есть стечение обстоятельств при которых в пути поиска обнаруживается утилита с другой
>версией (или с иными ключами ком. строки) или вообще с такимОк. Пусть так. А теперь возьмем другой крайний случай. Ваш скрипт использует абсолютные пути. Например, /usr/lib/python2.4/.. Далее цитирование "в результате установки более новой версии другого софта, установка произойдет позже чем установлен и проверен на работоспособность скрипт. Устанавливать будет другой человек, через год-другой. В итоге неожиданно что-нить сломается."
>>Есть стечение обстоятельств при которых в пути поиска обнаруживается утилита с другой
>>версией (или с иными ключами ком. строки) или вообще с таким
>
>Ок. Пусть так. А теперь возьмем другой крайний случай. Ваш скрипт использует
>абсолютные пути. Например, /usr/lib/python2.4/.. Далее цитирование "в результате установки более новой
>версии другого софта, установка произойдет позже чем установлен и проверен на
>работоспособность скрипт. Устанавливать будет другой человек, через год-другой. В итоге неожиданно
>что-нить сломается."что и где сломается?
>>>Есть стечение обстоятельств при которых в пути поиска обнаруживается утилита с другой
>>>версией (или с иными ключами ком. строки) или вообще с таким
>>
>>Ок. Пусть так. А теперь возьмем другой крайний случай. Ваш скрипт использует
>>абсолютные пути. Например, /usr/lib/python2.4/.. Далее цитирование "в результате установки более новой
>>версии другого софта, установка произойдет позже чем установлен и проверен на
>>работоспособность скрипт. Устанавливать будет другой человек, через год-другой. В итоге неожиданно
>>что-нить сломается."
>
>что и где сломается?Скрипт перенесен на другую платформу, где /usr/lib/python2.4 или /usr/bin, /bin ... et cetera отсутствует как класс, а в скрипте они захардкожены. "Устанавливать будет другой человек, через год-другой". Вспомнит он многими добрыми словами человека черкавшего этот скрипт. Попутно он будет заменять десятки/сотни абсолютных путей.
any way, у обоих подходов есть "-" и "+". Ситуации, когда встречается дублирование софта в разных prefix=, скорее исключение, чем правило. На мой взгляд, характерно бо`льше для хостинг-площадок.
>Скрипт перенесен на другую платформу, где /usr/lib/python2.4 или /usr/bin, /bin ... et
>cetera отсутствует как класс, а в скрипте они захардкожены. "Устанавливать будет
>другой человек, через год-другой". Вспомнит он многими добрыми словами человека черкавшего
>этот скрипт. Попутно он будет заменять десятки/сотни абсолютных путей.Если все пути собраны в начале скрипта и завязаны на задаваемый (настраиваемый) префикс, то не все так страшно, но только в том случае если скрипт не обычным копированием переносится, а устанавливается через тот же configure в рамках какого-то пакета. Конечно есть множество скриптов которые именно обычным копированием и перетаскиваются, т.к. не будет же человек для каждого скрипта писать спеку для установки через систему пакетов :)
>
>any way, у обоих подходов есть "-" и "+". Ситуации, когда встречается
>дублирование софта в разных prefix=, скорее исключение, чем правило. На мой
>взгляд, характерно бо`льше для хостинг-площадок.Согласен.
PS развели тут, понимаешь, дискуссию :))
>Конечно есть множество скриптов которые именно
>обычным копированием и перетаскиваются, т.к. не будет же человек для каждого
>скрипта писать спеку для установки через систему пакетов :)Мноние не будут, а кто-то точно будет. (Например, я очень не люблю что-либо устанавливать в систему не из RPM-пакетов.)
>>>PS и это, полный путь к cat, плз =)
>>
>>Ну это уже слишком, IMHO. cat обычно лежит в /bin, а /bin
>>обычно по умолчанию есть в $PATH у кронтаба.о да, логично, почти :)
а ничего что есть перцы (одмины) - любители неожиданных решений, ну там прописать крону в $PATH оригинальные пути хз куда? и cat уже не cat, а вот /bin/cat однозначен шо ппц :)
не ну поняно что такой одмин ССЗБ, но как гриться - береженого бог бережет, приговаривала монашка одевая на свечку десятый презерватив :))>Я тоже думаю что полные пути излишни.
зряяяя..... :))
>>Я тоже думаю что полные пути излишни.
>
>зряяяя..... :))Полные пути не помогли. Все опробовал. И от пользователя тоже делал и от root.
Лог работы mutt вот найти не могу. в /var/log содаются записи типа mutt-user-белиберда
но там только текст сообщения создаваемое cat mess.txt.
Перенаправить поток ошибок типа mutt >> mutt.log 2> mutt2.log и подобное тому не создает указаных файлов.
>Полные пути не помогли. Все опробовал.Попробуйте в вашем скрипте заменить /bin/sh на /bin/sh -x и смотреть, что он там делает.
Также небезопасно размещать скрипт, который вызывается из крона в /tmp
>>>Я тоже думаю что полные пути излишни.
>>
>>зряяяя..... :))
>
>Полные пути не помогли. Все опробовал. И от пользователя тоже делал и
>от root.
>Лог работы mutt вот найти не могу. в /var/log содаются записи типа
>mutt-user-белиберда
>но там только текст сообщения создаваемое cat mess.txt.
>Перенаправить поток ошибок типа mutt >> mutt.log 2> mutt2.log и подобное тому не создает указаных файлов.я написал mutt >/tmp/mutt.log 2>/tmp/mutt2.log, есть разница
>я написал mutt >/tmp/mutt.log 2>/tmp/mutt2.log, есть разницаесть разница я так и делал...
/bin/sh -x попробую
Сам скрипт sender.sh
#!/bin/sh -x
/bin/echo "Pesec" | /usr/local/bin/mutt -s "Тема "user@host.ru
/tmp/mutt.log 2>/tmp/mutt2.log
Ручной запуск, результат:+ /bin/echo Pesec
+ /usr/local/bin /mutt #!/bin/sh -x/tmp/mutt.log пустой
/tmp/mutt2.log пустойЗапуск по крон , результат
/tmp/mutt.log пустой
содержимое /tmp/mutt2.log:Error sending message , child exited 78 ().
выше криво написал...совсем запарился
Ручной запуск, результат:+ /bin/echo Pesec
+ /usr/local/bin /mutt -s Тема user@host.ru
Че делать то? Все уж перековырял.
>Че делать то? Все уж перековырял.Ну далее распутывать ниточку "Error sending message , child exited 78 ()."
В гугле поищите по этой фразе. Там есть люди с подобными проблемами. Судя по всему это даже не проблема mutt-а, а проблема вашего MTA. Например, здесь (http://objectmix.com/mutt/202130-mutt-sendmail-problem.html) всё рещилось, когда на sendmail установили SGID-бит.
>>Че делать то? Все уж перековырял.
>
>Ну далее распутывать ниточку "Error sending message , child exited 78 ()."
>
>
>В гугле поищите по этой фразе. Там есть люди с подобными проблемами.
>Судя по всему это даже не проблема mutt-а, а проблема вашего
>MTA. Например, здесь (http://objectmix.com/mutt/202130-mutt-sendmail-problem.html) всё рещилось, когда на sendmail установили SGID-бит.
>Одна беда. У меня все настроено и работает при ручном запуске. А из под Cron никак. Да и smtp сервер используется внешний..а не свой
Ушел читать буквари в очередной китайский раз....
>Одна беда. У меня все настроено и работает при ручном запуске. А
>из под Cron никак.Есть вариант, что на это влияют какие-то переменные окружения, например. Чтобы это проверить можно сделать так:
- Выполнить env >env.work вручную
- Добавить команду env >end.broken в скрипт и выполнить из крона
- Сделать diff -u env.work env.broken и посмотреть есть ли отличия
>>Одна беда. У меня все настроено и работает при ручном запуске. А
>>из под Cron никак.
>
>Есть вариант, что на это влияют какие-то переменные окружения, например. Чтобы это
>проверить можно сделать так:
>
>- Выполнить env >env.work вручную
>- Добавить команду env >end.broken в скрипт и выполнить из крона
>- Сделать diff -u env.work env.broken и посмотреть есть ли отличияlab# diff -u env.work env.cron
--- env.work 2009-03-02 10:39:44.000000000 +0800
+++ env.cron 2009-03-02 10:34:00.000000000 +0800
@@ -1,47 +1,6 @@
-DESKTOP_SESSION=gnome
-no_proxy=localhost,127.0.0.0/8
-DESKTOP_STARTUP_ID=
-XAUTHORITY=/root/.Xauthority
-G_BROKEN_FILENAMES=yes
-GDM_XSERVER_LOCATION=local
-BLOCKSIZE=K
-GDM_GREETER_TYPE=PLAIN
-LOGNAME=root
-WINDOWPATH=9:9
-http_proxy=http://10.81.224.5:8080/
-GNOME_DESKTOP_SESSION_ID=Default
-GTK_RC_FILES=/usr/local/etc/gtk/gtkrc:/root/.gtkrc-1.2-gnome2
-GTK_MODULES=gnomebreakpad
-USERNAME=root
-PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/games:/usr/local/sbin:/usr/local/bin:/root/bin
-SSH_AUTH_SOCK=/tmp/ssh-tcgHodAIDW/agent.1278
-TERM=xterm
-PWD=/root
USER=root
-WINDOWID=27263029
-XDG_DATA_DIRS=/usr/local/share/:/usr/share/:/usr/local/share/gdm/
-COLORTERM=gnome-terminal
-DBUS_SESSION_BUS_ADDRESS=unix:path=/var/tmp/dbus-F8w2ip3MqP,guid=7a0fa522eb61f71e984d7e0049ab46d3
-GDMSESSION=gnome
-DISPLAY=:0.0
-RC_PID=49
-SSH_AGENT_PID=1287
-SHELL=/bin/csh
-GNOME_KEYRING_SOCKET=/var/tmp/keyring-qcuw4c/socket
-PAGER=more
-LANG=ru_RU.UTF-8
-GDM_LANG=ru_RU.UTF-8
-SESSION_MANAGER=local/lab.usi:/tmp/.ICE-unix/1278
-FTP_PASSIVE_MODE=YES
-LC_MESSAGES=
-HOME=/root
-MAIL=/var/mail/root
-HOSTTYPE=FreeBSD
-VENDOR=intel
-OSTYPE=FreeBSD
-MACHTYPE=i386
-SHLVL=1
-GROUP=wheel
-HOST=lab.usi
-REMOTEHOST=
-EDITOR=ee
+HOME=/var/log
+LOGNAME=root
+PATH=/etc:/bin:/sbin:/usr/bin:/usr/sbin
+SHELL=/bin/sh
+PWD=/var/log
Ну вот...>[оверквотинг удален]
>-no_proxy=localhost,127.0.0.0/8
>-DESKTOP_STARTUP_ID=
>-XAUTHORITY=/root/.Xauthority
>-G_BROKEN_FILENAMES=yes
>-GDM_XSERVER_LOCATION=local
>-BLOCKSIZE=K
>-GDM_GREETER_TYPE=PLAIN
>-LOGNAME=root
>-WINDOWPATH=9:9
>-http_proxy=http://10.81.224.5:8080/Я бы попробовал выставить эту переменную. Вполне может влиять на "хождение" почты.
>-GNOME_DESKTOP_SESSION_ID=Default
>-GTK_RC_FILES=/usr/local/etc/gtk/gtkrc:/root/.gtkrc-1.2-gnome2
>-GTK_MODULES=gnomebreakpad
>-USERNAME=root
>-PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/games:/usr/local/sbin:/usr/local/bin:/root/binВыставить $PATH, в такую как у вас в работающем варианте -- тоже можно попробовать.
>-SSH_AUTH_SOCK=/tmp/ssh-tcgHodAIDW/agent.1278
>-TERM=xtermПеременная $TERM в некоторых случаях тоже может влиять. Если совсем ничего не помогает, то и её можно "подёргать".
>[оверквотинг удален]
> USER=root
>-WINDOWID=27263029
>-XDG_DATA_DIRS=/usr/local/share/:/usr/share/:/usr/local/share/gdm/
>-COLORTERM=gnome-terminal
>-DBUS_SESSION_BUS_ADDRESS=unix:path=/var/tmp/dbus-F8w2ip3MqP,guid=7a0fa522eb61f71e984d7e0049ab46d3
>-GDMSESSION=gnome
>-DISPLAY=:0.0
>-RC_PID=49
>-SSH_AGENT_PID=1287
>-SHELL=/bin/cshОбратите внимание что шеллы различаются. Причем весьма -- sh и csh это два берега одной реки.
>-GNOME_KEYRING_SOCKET=/var/tmp/keyring-qcuw4c/socket
>-PAGER=more
>-LANG=ru_RU.UTF-8
>-GDM_LANG=ru_RU.UTF-8
>-SESSION_MANAGER=local/lab.usi:/tmp/.ICE-unix/1278
>-FTP_PASSIVE_MODE=YES
>-LC_MESSAGES=
>-HOME=/root
>-MAIL=/var/mail/rootНачните с установки этой переменной. Наиболее вероятно, что проблема именно в том, что она у вас не установлена.
>[оверквотинг удален]
>-SHLVL=1
>-GROUP=wheel
>-HOST=lab.usi
>-REMOTEHOST=
>-EDITOR=ee
>+HOME=/var/log
>+LOGNAME=root
>+PATH=/etc:/bin:/sbin:/usr/bin:/usr/sbin
>+SHELL=/bin/sh
>+PWD=/var/logHTH
>Коллеги помогите советом.
>Есть скрипт sender.sh содержащий одну строку:
>cat mess.txt | mutt -x -s "Тема" -a "file" user@host.ru
>Отправляет почту на указанный адрес через консольного почтового клиента mutt+msmtp(для отправки через
>smtp сервер).
>при запуске sender.sh письмо уходит, при настройке запуска по cron скрипт запускается,
>но письмо не уходит. на sender.sh права полные. В которую сторону
>покопать можно?1) убить лишние пробелы в конце строки. которые в редакторе как правило не видны
2) нажать кнопицу "ввод". возврат каретки на последней строке crontab-a - вот сила! (100% - тут ты лоханулся)
Пробелов нету. крон таб отчитывается в лог файле что все было запущено. Но писмо не ушло. Я уж писал выше лог который mutt выдает.
>Пробелов нету. крон таб отчитывается в лог файле что все было запущено.
>Но писмо не ушло. Я уж писал выше лог который mutt
>выдает.Ну и дальше что ?
Проблему решил ?
у меня сейчас такая же только с клиентом email
>Ну и дальше что ?
>Проблему решил ?
>у меня сейчас такая же только с клиентом emailПока не решил...проблема отложена на время. С коммутаторами и роутерами бьюсь пока(приоритетней задача). Но вернусь к проблеме как только смогу.
Все решилось переносом в пользовательский crontab, Специалисты и так поняли, а другим поясню,
создал файл /usr/home/user/test c тремя строками:
SHELL=/bin/sh
MAILTO=lab
*/1 * * * /home/user/mail/tarifsender.shДалее (из под user):
crontab -l - проверяем есть у пользователя свой кронтаб.
crontab -u user /usr/home/user/test - создаем crontab из файла test.
размещаем файл /usr/home/user/tarifsender.sh c единственной строкой:
/bin/echo "Text pisma"|/usr/local/bin/mutt -x -a /tmp/mess.txt -s "tema" user@host.ru
Все работает