LINUX.ORG.RU
ФорумAdmin

Посоветуйте парсер log почты Postfix в базу

 ,


1

3

Всем доброго времени. После перехода на Linux почту встал вопрос как просматривать инфу о том кому какие письма была отправлены и конечный результат отправки send/error. Все это конечно есть в Log но к сожалению есть люди которые читать его не умеют да и лучше их не пускать на сервер.

Поэтому собственно вопрос.

Хочется найти скрипт или готовое решение который обрабатывает Log Postfix и заносит в базу данных информацию кто, когда кому и что отправил и конечный код операции. Ну и соответственно такая-же статистика по полученной почте.

В идеале наличие Web интерфейса для просмотра собранных данных но не обязательно если что сам напишу.

Если ничего готового нет то второй вопрос есть ли возможность заносить в лог файл тему письма?

при учете что вы пишите " если что сам напишу."
bash, grep, sed, awk вобшем_что_больше_по_вкусу, работы то совсем немного. к сэндмылу я такое прифигачивал.

anc ★★★★★
()

Пиши сам, нет такого.

Если ничего готового нет то второй вопрос есть ли возможность заносить в лог файл тему письма?

Вроде нет, я в свое время делал парсер почты который принимал через адрес в always_bcc и заносил в базу параметры писем.

blind_oracle ★★★★★
()
Ответ на: комментарий от anc

при учете что вы пишите " если что сам напишу."

Тогда второй вопрос можно ли как-то заставить писать в лог тему письма?

wer_wolf
() автор топика
Ответ на: комментарий от leave

Следующий сеанс гугления будет платным.

Огромное спасибо, реально не мог найти.

wer_wolf
() автор топика

Инфа о письме размазана по логу. В частности, from и to в разных строках находятся. Нужно парсить по ID очереди.

#!/usr/bin/perl

my %ids;

open LOGF, '/var/log/mail.log';

while (defined (my $line = <LOGF>)) {
	if ($line =~ /postfix\/(?:smtp|qmgr)\[[^\s]+(?:\s\[[^\]]*\])?\s(?<id>[0-9a-f]+):\s(?:(?<removed>r)emoved|from=<(?<from>[^>]+\@[^>]+)>|to=<(?<to>[^>]+\@[^>]+)>,\srelay=[^\[,]+\[(?<relay>[\d.]+)\][^\(]+status=sent)/i) {
		if (defined $+{removed}) {
			delete $ids{$+{id}};

		} elsif (defined $+{from}) {
			$ids{$+{id}} = $+{from};

		} elsif (defined $ids{$+{id}}) {
        		# from, to, relay
        		print ($ids{$+{id}}, lc($+{to}), $+{relay});

		}
	}
}

close LOGF;

- это выдрано из postpals-taillog (http://mailfud.org/postpals/), см. sub _parse_logline и переделано под себя.

rubic
()
Ответ на: комментарий от rubic

Это понятно что инфа размазана, но вот есть вопрос по поводу ID Вот строка лога

May  7 17:10:03 mail postfix/cleanup[10223]: 56820C81F03: message-id=<63E2937A2AC844A18BA6BBC1D0C069FD@dom.com>

Есть у нас письмо у него два ID первый ID очереди 56820C81F03 второй message-id 63E2937A2AC844A18BA6BBC1D0C069FD

Я правильно понимаю что анализировать нужно оба ID потому что инфа по ID 56820C81F03 заканчивается вот такой строкой

status=sent (250 2.0.0 from MTA(smtp:[127.0.0.1]:10025): 250 2.0.0 Ok: queued as 98448C821A6)
May  7 17:10:03 mail postfix/qmgr[8942]: 56820C81F03: removed

И дальше обработка этого же письма уже идет под ID 98448C821A6 и уже эта обработка заканчивается строкой

May  7 17:10:03 mail postfix/pipe[10231]: 98448C821A6: to=<user@mydom.com>, relay=dovecot, delay=0.32, delays=0.04/0.01/0/0.27, dsn=2.0.0, status=sent (delivered via dovecot service)
May  7 17:10:03 mail postfix/qmgr[8942]: 98448C821A6: removed

И еще вопрос из того что нашел в сети пишут что ID очереди формируется так что его повторение возможно только раз в несколько лет в зависимости от нагрузки на сервер, это так? Другими словами если будет анализироваться лог скажем за месяц можно ли использовать ID очереди как ключ и быть уверенным что он не повторится?

wer_wolf
() автор топика
Ответ на: комментарий от wer_wolf

И еще может быть случайно у кого-то завалялся пример hook скрипта для Postfix в идеале на php? Просто из того что нашел в инете ничего пока что не заработало. Или кто то посоветует как правильно подключить? На данный момент сделал так в файл master.cf в самый конец добавил

myhook unix - n n - - pipe
  flags=F user=root argv=/etc/postfix/myhook.php ${sender} ${size} ${recipient}
а в начале файла
smtp      inet  n       -       -       -       -       smtpd
postscreen
submission inet n       -       -       -       -       smtpd
  -o content_filter=myhook:dummy
  -o syslog_name=postfix/submission
  -o smtpd_tls_wrappermode=no
...
Но скрипт даже не вызывается хотя пока не добавил пользователя root в логе была ошибка о том что недостаточно прав.

wer_wolf
() автор топика
Ответ на: комментарий от anonymous

Да он не то что бы не устраивает просто я о таком не слышал спасибо почитаю. Но из того что увидел он просто грубо-говоря выкидывает из лога все лишнее и группирует, а душа просит базу данных с хранением как минимум за год и быстрым поиском.

wer_wolf
() автор топика
Ответ на: комментарий от wer_wolf

Это понятно что инфа размазана, но вот есть вопрос по поводу ID

Приведите весь кусок лога - от первой строки с искомым ID, до последней. У меня в строке со «status sent» содержится вся необходимая инфа.

rubic
()

postfix умеет в syslog. rsyslog умеет писать логи в sql. в качестве вебморды можно использовать phplogcon.

Lavos ★★★★★
()
Ответ на: комментарий от wer_wolf

Тогда попробуй еще pflogsumm. Тоже хороший парсер логов для Postfix.

anonymous
()
Ответ на: комментарий от anc

Ну Вы бы еще «танк» в виде php посоветовали.

Поколение пепси не в курсе, как расшиыровывается perl, и для чего этот язык предназначен ? В данном случае - перл, как раз, оптимальный инструмент

ovax ★★★
()
Ответ на: комментарий от wer_wolf

Сори, не дочитал до конца твое сообщение)

anonymous
()
Ответ на: комментарий от ovax

Поколение пепси как раз в курсе и даже в курсе в чем он связан с php. Но когда есть инструменты позволяющие выполнять задачу быстрее (а если сервак высоко нагружен логи там должны быть ой как не маленькие) то логичнее использовать их.
ЗЫ Не совсем в тему, но... Когда-то давно сел я писать на перле парсер логов сквида с записью в БД, вроде задача вообще простая, но не взлетело, логи росли быстрее. Причина была не в парсинге текста а в модуле работы с БД, был он ну очень тормозной да и машинки не те что сейчас.

anc ★★★★★
()

трэд не читал. Можно слепить Logstash + Kibana + Elasticsearch.

Если мне память не изменяет, logstash имеет готовые правила для postfix'a

snaf ★★★★★
()
Ответ на: комментарий от rubic

Приведите весь кусок лога - от первой строки с искомым ID, до последней

Вот вырезка двух кусков лога

cat ./mail.log |grep 20160508142401.DFADC2069AF86
May  8 17:24:04 mail postfix/cleanup[10733]: E5975C8097A: message-id=<20160508142401.DFADC2069AF86@smtp11.professionali.ru>
May  8 17:24:08 mail postfix/cleanup[10733]: 67EF2C821AC: message-id=<20160508142401.DFADC2069AF86@smtp11.professionali.ru>

/var/log$ cat ./mail.log |grep E5975C8097A
May  8 17:24:04 mail postfix/smtpd[10730]: E5975C8097A: client=fallback8.mail.ru[94.100.181.110]
May  8 17:24:04 mail postgrey[1350]: E5975C8097A: action=pass, reason=client AWL, client_name=fallback8.mail.ru, client_address=94.100.181.110, sender=info5-noreply@professionali.ru, recipient=inetuser@mydom.com
May  8 17:24:04 mail postfix/cleanup[10733]: E5975C8097A: warning: header Subject:  =?UTF-8?B?W9Ch0LzQtdC70L7RgdGC0Ywg0LHRi9GC0Ywg?=? =?UTF-8?B?0LHQvtCz0LDRgtGL0Lwg0Lgg0YHRh9Cw0YHRgg==?=? =?UTF-8?B?0LvQuNCy0YvQvCAyLjBdINCa0L7Qs9C0?=? =?UTF-8?B?0LAg0JXQs9C+0YAg0L3QsNC/0LjRgdC from fallback8.mail.ru[94.100.181.110]; from=<info5-noreply@professionali.ru> to=<inetuser@mydom.com> proto=ESMTP helo=<fallback8.mail.ru>
May  8 17:24:04 mail postfix/cleanup[10733]: E5975C8097A: message-id=<20160508142401.DFADC2069AF86@smtp11.professionali.ru>
May  8 17:24:05 mail postfix/qmgr[10387]: E5975C8097A: from=<info5-noreply@professionali.ru>, size=175557, nrcpt=1 (queue active)
May  8 17:24:08 mail postfix/smtp[10734]: E5975C8097A: to=<luser@mydom.com>, orig_to=<inetuser@mydom.com>, relay=127.0.0.1[127.0.0.1]:10024, delay=3.8, delays=0.46/0.02/0.03/3.3, dsn=2.0.0, status=sent (250 2.0.0 from MTA(smtp:[127.0.0.1]:10025): 250 2.0.0 Ok: queued as 67EF2C821AC)
May  8 17:24:08 mail postfix/qmgr[10387]: E5975C8097A: removed

cat ./mail.log |grep 67EF2C821AC
May  8 17:24:08 mail postfix/smtpd[10738]: 67EF2C821AC: client=localhost[127.0.0.1]
May  8 17:24:08 mail postfix/cleanup[10733]: 67EF2C821AC: message-id=<20160508142401.DFADC2069AF86@smtp11.professionali.ru>
May  8 17:24:08 mail postfix/qmgr[10387]: 67EF2C821AC: from=<info5-noreply@professionali.ru>, size=176146, nrcpt=1 (queue active)
May  8 17:24:08 mail postfix/smtp[10734]: E5975C8097A: to=<luser@mydom.com>, orig_to=<inetuser@mydom.com>, relay=127.0.0.1[127.0.0.1]:10024, delay=3.8, delays=0.46/0.02/0.03/3.3, dsn=2.0.0, status=sent (250 2.0.0 from MTA(smtp:[127.0.0.1]:10025): 250 2.0.0 Ok: queued as 67EF2C821AC)
May  8 17:24:08 mail postfix/pipe[10739]: 67EF2C821AC: to=<luser@mydom.com>, relay=dovecot, delay=0.19, delays=0.05/0/0/0.13, dsn=2.0.0, status=sent (delivered via dovecot service)
May  8 17:24:08 mail postfix/qmgr[10387]: 67EF2C821AC: removed
Скорее всего на одно письмо приходится два запроса потому что все пользователи виртуальные.

И еще вопрос при работе Greylisting какой будет ID письма при повторной отправке?

wer_wolf
() автор топика
Ответ на: комментарий от snaf

Если мне память не изменяет, logstash имеет готовые правила для postfix'a

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

Но вообще поддерживаю предложение ELK stack. Оно сгодится для всех мыслимых и немыслимых логов, в том числе и для postfix.

Deleted
()
Ответ на: комментарий от snaf

logstash имеет готовые правила для postfix'a

Спасибо.

Интересная штука, как минимум на ней можно готовить лог для заливки в БД

wer_wolf
() автор топика
Ответ на: комментарий от wer_wolf

Ну и чем вас не устраивает /var/log$ cat ./mail.log |grep E5975C8097A? Вся инфа в нем есть, скриптом она ловится. 67EF2C821AC к этой информации ничего не добавляет. Проблема только в том, что из-за фильтра на 10024 порту в результатах работы скрипта на входящих все будет двоиться, но это ерунда, дедупликация тривиально делается.

rubic
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.