Posts Tagged ‘ Mail

Проверить корректность отработки SSL в postfix/dovecot/courier

Както давненько был куплен сертификат для mail сервера, я его закинул на сервак, прописал путь к нему и к CA что предоставил центр сертификации где покупали, и усе. При этом outlook при первом обращении на него всетаки ругнулся, но достаточно было один раз ткнуть чтото типа «Доверяю и не спрашивать больше» и все прекрасно заработало. Времени копать дальше не было, как обычно, проехали-забыли. Но осадок остался … вот выдалось время разобраться в этом деле поглубже, для начала пара полезных команд:

openssl s_client -CApath /etc/ssl/certs/ -connect mail.nixcraft.net:443
openssl s_client -CApath /etc/ssl/certs/ -connect mail.somadomain.com.ua:995
openssl s_client -CApath /etc/ssl/certs/ -connect mail.somedomain.com.ua:587 -starttls smtp

А теперь по существу «моей проблемы». Чтобы все работало верно сертификат со стороны сервера должен состоять из сертификатов CA (очень желательно всех до корня) и сертификата выданого на данный сервер. Как проверить что у нас есть в данный момент? Просто!
Например:
Запускаем тест соединения с SMTP сервером с поддержкой TLS

openssl s_client -CApath /etc/ssl/certs/ -connect mail.somedomain.com.ua:995

Читать полностью

FreeBSD — exim4 в режиме smarthost

Итак, задача, на неком хосте настроить чтобы почта локального root и на внешние адреса работала через учетку на другом почтовом сервере, который для отправки требует авторизацию и TLS шифрование
Поскольку мне лично среди различный MTA более всего нравится exim, сначала собрал его из портов, потом чуток подправил конфиг:

В Main Configuration

primary_hostname = srv1.somedomain.com.ua
local_interfaces = 127.0.0.1

Тут же заремил:

#never_users = root

Читать полностью

dnsbl.njabl.org is DOWN

Postfix стал обильно сыпать в логи подобные записи:

Jul 24 09:49:13 mail postfix/smtpd[91569]: warning: 133.90.151.193.dnsbl.njabl.org: RBL lookup error: Host or domain name not found. Name service error for name=133.90.151.193.dnsbl.njabl.org type=A: Host not found, try again
Jul 24 09:49:13 mail postfix/smtpd[91569]: F2031763CFD: client=s1.hosting.uplink.net.ua[193.151.90.133]

Пошел на их сайт … и что я вижу?
March 1, 2013: NJABL is in the process of being shut down. The DNSBL zones have been emptied. After “the Internet” has had some time to remove NJABL from server configs, the NS’s will be pointed off into unallocated space (192.0.2.0/24 TEST-NET-1) to hopefully make the shutdown obvious to those who were slower to notice.
Печалька 🙁 Пришлось закоментить параметр в main.cf чтобы не засорять лог.

reject_rbl_client dnsbl.njabl.org

Поправьте и у себя 🙂

MS Outlook 2007/2010/2012 — Ошибка «На сервере отсутствует поддержка указанного типа шифрования»

На некоторой части машин под виндой начала появляться ошибка при отправке почты:
«Отправка тестового сообщения: На сервере отсутствует поддержка указанного типа шифрования подключений. Попробуйте изменить способ шифрования. За дополнительными сведениями обратитесь к администратору почтового сервера или к поставщику услуг Интернета.»
Ни обновление Outlook, ни переустановка ничего не давала. Решение нагуглилось на зарубежных форумах и оказалось довольно неожиданным — нужно удалить обновление Windows KB980436
Для этого идем в «Панель Управления -> Программы-> Программы и компоненты -> Установленные обновления» ищем данный апдейт, правой кнопкой на нем и «Удалить». После этого reboot и все прекрасно начинает работать.
Также, вполне возможно, глюк порождал кривой конфиг Fortigate-а. В процессе поиска решения его настройки тоже ковыряли 🙂

Updated: также в одном случае помогло выключение антивируса касперского. Так что думаю сперва убедитесь что работу почты не блокирует антивирус/фаервол, а потом уже ищите глючные апдейты!

Мдяяяя … реально был удивлен!

Postfix и особенности прикручивания SSL сертификата

Попытался прикрутить к postfix сертификат для работы с TLS шифрованием, но сходу незаработало! В логе /var/log/maillog нашел вот такую ошибку:

warning: TLS library problem: 83613:error:0906D064:PEM routines:PEM_read_bio:bad base64 decode:/usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/pem/pem_lib.c:757

Оказывается формат сертификата pem должен быть такой:

-----BEGIN RSA PRIVATE KEY-----
YOUR_KEY
-----END RSA PRIVATE KEY-----
-----BEGIN CERTIFICATE-----
YOUR_CRT
-----END CERTIFICATE-----

Притом что записи ключа и сертификата должны быть 64 символа в ширину, иначе поймаете ошибку такую же как у меня. В моем случае сертификат был написан одной строчкой 🙂
Исправить это можно любым текстовым редактором который показывает номер символа в строке, я использовал mcedit.
После такого переформатирования postfix прекрасно заработал с сертификатом.

MS Outlook 2010 на Windows XP — Error 0x800CCC13

Долго ковырялся пытаясь решить данную ошибку и в конце-концов победил ее! Об этом и хочу вкратце рассказать, ато русскоязычного решения нагуглить не удалось 🙁
Итак, что произошло — у пользователя перестала отправляться электронная почта в клиенте Outlook который установлен вместе с пакетом MS Office 2010 Professional. После собственного обследования прояснились симптомы — созданные на отправку письма, так и остаются в папке «Исходящие» не отправляются и не перемещаются в «Отправленные». Если полностью удалить ВСЕ сообщения из «Исходящие» при попытке «Получить-Отправить» получаем сообщение что задача «Получение» отработала, а «Отправка» подвисает на отправке второго из семи сообщений (од куда????? если в исходящих пусто?????) Висит долго (около 10-30 минут) после чего отправка валится с ошибкой Error 0x800CCC13 Читать полностью

Icedove BUG — /usr/lib/icedove/icedove-bin: symbol lookup error: /usr/lib/icedove/components/libdbusservice.so: undefined symbol: NS_Alloc

После вчерашнего обновления системы перестал запускаться почтовый клиент icedove. Debian squeeze на борту. На ярлычек реакции никакой. Попробовал запустить в консоли icedove, на что получил ошибку /usr/lib/icedove/icedove-bin: symbol lookup error: /usr/lib/icedove/components/libdbusservice.so: undefined symbol: NS_Alloc
Чтение обсуждения баги на официальном багтрекере Debian немного просветило суть проблемы. Решение нашлось там же (очень надеюсь что проблема временная и решится следующими обновлениями, так как нижеописанный костыль решением назвать трудно).
В файл /usr/lib/icedove/icedove добавил строчки
### elibc BUG ###
export LD_PRELOAD=/usr/lib/icedove/components/libmailcomps.so
export LD_LIBRARY_PATH=/usr/lib/icedove
### elibc BUG end ###
После этого icedove чудесно заработал. Но все равно надеюсь что в дальнейших обновлениях все починят 🙂

FreeBSD & ISP. Проблема SASL авторизации

На FreeBSD стоит ISP Manager в котором настроена почта для предприятия. В качестве MTA — Postfix. Все бы хорошо да только авторизация SMTP чегото нивкакую работать нехотела без галочки в MTU «Авторизироваться сначала на POP а потом на SMTP», которой почемуто нету в Thunderbird.
Если тундру настроить на простую авторизацию по паролю то отправка не проходит, а в логах сервера вижу:

Aug  5 11:40:23 srv postfix/smtpd[10934]: warning: SASL authentication failure: no user in db
Aug  5 11:40:23 srv postfix/smtpd[10934]: warning: SASL authentication failure: no user in db
Aug  5 11:40:23 srv postfix/smtpd[10934]: warning: SASL authentication failure: Password verification failed
Aug  5 11:40:23 srv postfix/smtpd[10934]: warning: firma.com.ua[62.24.38.12]: SASL PLAIN authentication failed: authentication failure
Aug  5 11:40:23 srv postfix/smtpd[10934]: warning: SASL authentication failure: no user in db
Aug  5 11:40:23 srv postfix/smtpd[10934]: warning: SASL authentication failure: no user in db
Aug  5 11:40:23 srv postfix/smtpd[10934]: warning: firma.com.ua[62.24.38.12]: SASL LOGIN authentication failed: authentication failure

Как это глобально исправить незнаю. Для конкретного пользователя нашел решение. В консоли ручками задаем пароль который задан на чтение почты через админку ISP:

[black@srv:~]$ sudo saslpasswd2 -c user@my-domain.com.ua

После задания корректного пароля — Thunderbird стал нормально авторизироваться по SMTP и почта стала отправляться на ура.
Глобальное решение пока ищем ….

Обновление Roundcube 3.1 до версии 4.2

Както в одной из предыдущих заметок я упоминал о том что на работе использую Roundcube в качестве почтового клиента. А что? Удобно! С любой машины в сети можно посмотреть почту 🙂 Короче клиент зачетный — рекомендую. Неоспоримой позитивной особенностью также является то что проэкт очень шустро розвивается. В результате, вроде, недавно ставил стабильный релиз 3.1, а вчера зашел на офсайт проэкта и увидел что уж давно стабильным считается четвертая версия 🙂 Ну чтож …. надо обновиться!

Первое что рекомендую сделать перед обновлением — бекап рабочей проги + дамп базы. Делается очень просто (у меня прога установлена в /opt/roundcube). Сначала бэкапим базу данных:

black:~# mysqldump -p rcmail |gzip -c > rcmail_SQL-`date +%F`.gz

После этого бекапим саму прогу:

black:~# tar -cjvf roundcube_backup-`date +%F`.tar.bz2 /opt/roundcube

Дальше можно браться за обновление. В случае если чтото накосячим, всегда сможем вернуться к тому что было используя сделанные бекапы 😉 Читать полностью

Проблема с базой писем в Seamonkey

Есть отличная програмка для чтения электронной почты Seamonkey. Хороша она прежде всего своей легковесностью и довольно большим функционалом. Также имеется возможность розширять возможности дополнительными плагинами и менять темы. Короче, это был небольшой приятный пиар для продукта мозиллы 🙂 А вот и ложка дегтя, на которую рано или поздно может нарваться каждый пользователь этой программы — переполнение базы сообщений. Описать сие явление могу примерно так: при достижении файла Inbox (именно в нем хранятся сами сообщения) размера в 2 гига байта seamonkey начинает вести себя странно. А точнее она просто неспособна нормально обработать файл базы сообщений и, как следствие, правильно построить индекс. В результате получаем тему письма которая совсем не соответствует телу и вложению 🙂 Такой вот клевый глючек 🙂

Дальше расскажу на своем примере о том как это исправить Пользователь в моей системе myuser

  • переходим в папку с сообщениями (6qdizk8d.slt — это уникальный симанковский какойто id, у вас будет другой) :
cd /home/myuser/.seamonkey/default/6qdizk8d.slt/Mail/pop3/
  • удаляем индексный файл базы входящих сообщений:
rm Inbox.msf
  • Теперь делаем такую клевую фишку,  которая во всей базе сообщений изменит x-status. Это позволит нам нормально проиндексировать базу. Исправленный таким образом файл назовем GoodInbox
sed -e 's/^X-Mozilla-Status: ....$/X-Mozilla-Status: 0011/' Inbox > GoodInbox
  • Теперь открываем seamonkey и в перечне папок (обычно слева) видим новую папку GoodInbox. Если попытаться ее открыть — скорее всего она начнет индексироваться, но не факт! Мне чтоб ее проиндексировать пришлось нажать на ней правой кнопкой мышки -> Свойства -> Перестроить Индекс

После постройки индекса этой папки мы увидем все наши сообщения в целости и сохранности 🙂 Все что теперь нужно сделать — не добавлять сюда сообщения. Тоесть эта папка останется нормально работающей до тех пор пока в нее не попадет какоето новое письмо. Такчто ее можно просто переименовать например в Archive и спокойно пользоваться.

Что касается входящих, то я бы рекомендовал их полностью удалить. И желательно не с программы, а ручками. Тоесть закрыть seamonkey и в консоли опять же перейти в /home/myuser/.seamonkey/default/6qdizk8d.slt/Mail/pop3/ и сделать rm Inbox && rm Inbox.msf

После этого запустить seamonkey и, убедившись что во входящих ничего нету, спокойно работать с программой дальше.

В результате получаем нормально работающие входящие и в папке Archive все старые сообщения.

P.S. Всего этого можно избежать если не скапливать во входящих тысячи сообщений. Если у вас действительно много сообщений и есть необходимость их хранить подумайте на досуге над тем чтобы сортировать их по какомуто критерию по разным папкам — это уменьшит риск нарваться на описанную мной неприятность. Темболее что в seamonkey есть возможность настроить фильтры для автоматической сортировки новой почты по заданным критериям в разные папки 😉