Одминский блог

Ошибка SMTP сессии на Exim

День начался радостно, с того, что по каким то причинам перестала доставляться почта от одного из клиентов, а на почтовом сервере Exim, пошли отлупы в виде сообщения “unexpected disconnection while reading SMTP command from smtp.xxxx.xx”

По сложившейся традиции, вражеский админ ушел в несознанку, постановив,  что это проблемы на нашей стороне исходя из того, что у них со всем миром все отлично, так что видимо это затыки спамфильтра на нашей. Так что получить от него более полную информацию по логу с его стороны, не получилось, так что пришлось копаться у себя.

(more…)

Рубрика: Почтовые системы | Ваш отзыв »

Снижение нагрузки на почтовый сервер через DKIM

Столкнулся тут с интересной технологией DKIM (DomainKeys Identified Mail), служащей для верификации почтовых отправлений между почтовыми серверами на уровне доменных ключей. То есть фактически аналог SPF, который в свое время достаточно агрессивно навязывали мелкомягкие, да так, что не имея его, невозможно было отослать письмо на Hotmail.

(more…)

Рубрика: Почтовые системы | Ваш отзыв »

Управление автоповторами в Exim

На одном из почтарей под управлением exim возникала постоянно ситуация, когда при отправке письма на широковещательный внутренний адрес компании alloffice@odminblog.ru, в случае переполнения ящиков одного или нескольких пользователей, письмо ничинало отсылаться каждые 15 минут, после чего количество забитых ящиков еще больше увеличивалось и почтарь впадал в ступор. Возникало не из-за того что я первоначально криво все настроил, а из-за того что пользователи имея ящики по 200 метров не запаривались на их очистку, в добавок к чему сыпали мейлами по 15-20 мегабайт.

В этой связи возникла задача переписать стандартное правило автоповторов для exim. Для этого открываем конфигурационный файл и идем в самый его конец, в секцию RETRY. Там мы видим следующие строки:

########################################
#                      RETRY CONFIGURATION                           #
########################################
begin retry
# Domain               Error       Retries
*                 refused_A   F,2h,20m;
*                      *           F,2h,15m; G,16h,1h,1.5; F,4d,6h

Это стандартное правило автоповторов для exim, и оно всегда имеет две звездочки, для того чтобы описать общее правило для всех доменов и ошибок, не описанных отдельным полем. Об этом описании мы поговорим позже, а в данной записи получается что в случае любой ошибки для любого домена повтор отправки будет осуществляться каждые 15 минут в течении двух часов, после чего с интервалами от одного часа до 16 часов, с множителем в 1,5, после чего в течении 4 дней попытка будет осуществляться каждые 6 часов. После истечения времени автоповтора exim отбивает адрес доставки и скитывает отправителю отлуп.

Само правило автоповтора создается по следующему шаблону:
<Domain><Error><Retries>
Первым пункт может включать как имя домена, так и, для сужения задачи, адрес получателя.
Второй пункт описывает специфическую ошибку, которые бывают следующих типов:
auth_failed – при неудачной аутентификации в случае отправки на хост из списка  hosts_require_auth
data_4xx   – при ошибке которая получается для команды smtp диалога DATA, или сразу же после команды
mail_4xx   – при ошибке которая получается для команды smtp диалога MAIL.
rcpt_4xx    – которая получается для команды smtp диалога RCPT
Также в этих трех ошибках, ошибка может задаваться полным номером, для сужения правила применения автоповтора.
lost_connection – при неожиданном закрытии SMTP-сессии со стороны сервера
refused_MX – при отказе в соединении к хосту определенному как почтовый сервер по данным из MX записи
refused_A – при отказе в соединении к хосту полученному не из MX записи
refused – при любом отказе в соединении
timeout_connect_MX – при таймауте попытки соединения с хостом определенномв MX-записи
timeout_connect_A – при таймауте попытки соединения с хостом полученным не из MX-записи
timeout_connect – при таймауте любой попытки соединения
timeout_MX – при таймауте во время соединения или в процессе SMTP-сессии с хостом, полученным из MX-записи
timeout_A – при таймауте во время соединения или в процессе SMTP-сессии с хостом, полученным не из MX-записи
timeout – при таймауте во время соединения или в процессе SMTP-сессии
tls_required – в сессии соединения сервер должен был использовать TLS (сервер определен в списке  hosts_require_tls), но либо TLS не был предложен, либо сервер прислал ответ 4xx на команду STARTTLS
quota  – при локальной доставке транспортом “ appendfile ” была превышена квота почтового ящика пользователя
quota_<time> – при локальной доставке транспортом “ appendfile ” была превышена квота почтового ящика, и к почтовому ящику не обращались время равное <time>
Также после этого поля возможно определить отправителя, тем самыв сузив правило автоповтора, например для приоритезации руководства компании:
senders=<address list>
Тогда правило автоповтора будет выглядеть
kremlin.ru  rcpt_452  senders=”mainperson@odminblog.ru”  G,8h,10m,

Третий пункт отпределяет само правило автоповтора:
<letter>,<cutoff time>,<arguments>
Буквой задает алгоритм вычисления правила автоповтора:
F – повторять автоповтор с определенным интервалом. Первое число определяет в течении какого периода осуществлять автоповтор, второе задает интервал.
G -  повторять автоповтор в геометрически увеличивающихся интервалах. Первое число определяет максимальное значение для интервала, второе начальное значение интервала, третье число множитель, используемый для увеличения интервала при каждом повторении.Если первое число не задано, то интервал увеличивается до значения параметра retry_interval_max, который не может быть больше 24h.
H – повторять отправку повтора со случайными интервалами. Используемые аргументы – такие же как для  G. Для каждого повтора, предыдущий интервал умножается на фактор, для получения максимума следующего интервала. Минимальный интервал – первый аргумент параметра, и актуальный интервал выбирается случайным образом из диапазона между ними.
Если в поле правила автоповтора ничего не задано, то сразу после неудачной попытки отправки, генерируется рикошет и уходит в сторону отправителя.

Исходя из всего вышеописанного создаем новое правило автоповторов:
####################################################
#                      RETRY CONFIGURATION                           #
####################################################
begin retry
# Domain               Error       Retries
alloffice@odminblog.ru    *
odminblog.ru    quota
*                 refused_A   F,2h,20m;
*                      *           F,2h,15m; G,16h,1h,1.5; F,4d,6h

По этому правилу на все ошибки препятствующие доставки на адрес alloffice@odminblog.ru будет генерироваться рикошет, а при переполнении ящика кого либо из пользователей домена odminblog.ru также будет генерироваться рикошет

Рубрика: Почтовые системы | 1 отзыв »

Организация глобального внутреннего алиаса средствами exim

Очень часто возникает необходимость создать некоторое количество внутренних почтовых адресов, например по отделам и административным группам (sales@ , acct@) или безусловную рассылку на все почтовые адреса компании, что нибудь вроде all@ или office@. Этот алиас мы присваиваем всем имеющимся почтовым пользователям, но через пару недель использования, а то и сразу на него начинает сыпаться дикое количество спама, ибо за день на стандартные потовые адреса может приходить до нескольких сотен сообщений, которые в ситуации с глобальным алиасом будут падать на все конторские ящики, выводя пользователей из себя и портя нервы админу. Естественно, что лучшим выходом в данной ситуации будет закрыть это адрес для внешней пересылки, оставив его только для внутреннего общения компании. Но как это сделать?

Если для внутренней пересылки используется внутренний почтовый сервер, то это одно дело, но если сервер у нас один и на нем необходимо завести этих пользователей, запретив отправку на них почты извне?

Тут нам в очередной раз приходит на помощь такой гибкий инструмент управления почтовым сервером Exim, как его конфигурационный файл exim.conf

В разделе MAIN CONFIGURATION SETTINGS у  нас уже должны быть заданы IP адреса для которых разрешена отправка через наш почтовый север. Обычно в этот список включается только localhost для того чтобы сервер мог пересылать сам через себя, но можно также включить и пользователей локальной сети, например:

hostlist relay_from_hosts = 127.0.0.1 : 192.168.16.0/24

В разделе  ACL CONFIGURATION создаем правило для нашего глобального алиаса, по которому использование данного адреса будет разрешено только для хостов указанных в списке relay_from_hosts или прошедших аутентификацию.

deny    message     = Go Away! This address not permitted for external use!
hosts              = !+relay_from_hosts
local_parts       = GLOBAL_ALIAS
!authenticated   = *

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

domains        = +local_domains

После этого для каждого создаваемого пользователя мы добавляем глобальный алиас, или же можно созрать список рассылки без добавления отдельных алиасов, для этого в раздел ROUTERS CONFIGURATION добавляем следующее выражение:

virtual_allusers:
driver = redirect
domains = +local_domains
allow_fail
allow_defer
condition = ${if eq {$local_part}{all|еще какие-нить алиасы}{yes}{no}}
data = ${lookup mysql{SELECT CONCAT(login,»@»,domain) FROM users}}

Также можно объявить разрешенных отправителей для этого адреса, если количество внутриофисных спамеров ограничено:
senders = localspammer@odminblog.ru

Рубрика: Почтовые системы | Отзывов: 2 »

Всякие полезности для exim

Ниже приводится вольный перевод статьи, посвященной хитростям работы с SMTP сервером Exim v. 4.  Эта статья является более подробным изложением материала который я приводил  в моем предыдущем посте о работе с очередью Exim.  Какие то вводные могут пересекаться, но по сути это более подробная и развернутая инструкция.
Естественно, что использование этих команд не исключает необходимости познаний о работе сервисов SMTP, MTA и знакомства с шеллом UNIX.
(more…)

Рубрика: Подсказки, Почтовые системы | Отзывов: 6 »

Дефрагментация и сжатие InnoDB

Есть у меня отличный почтарь, да не один, а несколько. Все они крутятся в связке Exim + DBmail + MySQL, конечно там есть много чего еще, но это основная связка, и нас из неё интересует последняя составляющая mySQL. Дело в том, что база пользователей и всего имеющегося мусора крутится по мускулем и хостится в базе типо InnoDB, которую необходимо постоянно сжимать и сканировать. Желательно каждую ночь, чтобы мусор скопившийся за день, не забивал место в табличном пространстве.

К большому сожалению база InnoDB работает по принципу ниппеля, т.е. туда дуй, оттуда х… Объясняя это доступным языком- табличное пространство может как расширяться так и уменьшаться, но физический размер базы при этом изменяется только в сторону увеличения. Проще говоря если у вас база была на максимуме 20гигов, и после этого вы её почистив освободили 90% пространства, внутри база у вас будет свободна на 90% (посмотреть свободное пространство можно командой в консоли управления сервером: mysql> show table status; ), но снаружи она так и будет занимать на диске 20 Гиг физического пространства диска. Так вот у меня, на одном из серверов, она успела разрастись, пока я прочухал тот факт, что забыл установить чистящий скриптик, до 250 Гигов, которые конечно работают как часы, но самой цифрой действуют мне на нервы. В этой связи надо что то делать. Но делать можно только одним способом, а именно перегнать базу в дамп sql и затянуть его обратно, предварительно дропнув имеющегося монстра. В этой связи, ровно как и для дефрагментации табличного пространства, нашим лучшим другом является системная утилита mysqldump, входящая в стандартный комплект поставки сервера mySQL.

*** Для дефрагментации InnoDB также можно использовать способ двойной перегонки базы, с помощью команды ALTER преобразовать её в тип MyISAM, а затем обратно в тип InnoDB.
(more…)

Рубрика: Базы данных | Ваш отзыв »

Борьба со спамом в MTA EXIM на основе ACL

Как говорят знающие люди, хуже спама может быть только борьба со спамом. Но тем не менее с тем ужасным потоком, что обрушивается на незащищенного пользователя, необходимо что то делать, т.к. иначе конечному пользователю приходится тратить часы на разборы тех словесных завалов, что валятся ему в ящик.
Можно сколь угодно долго рассуждать относительно этичности использования RBL листов, но внедрение их автоматически снижает нагрузку спама в разы, тем более что для рассылок последнее время очень часто используются бот-сети, полностью иммулирующие нормальное соединение.
(more…)

Рубрика: FreeBSD, IT безопасность, Почтовые системы | Отзывов: 4 »