Отслеживание журналов электронной почты с помощью журналов Postfix для обеспечения возможности доставки электронной почты

Отслеживание журналов электронной почты с помощью журналов Postfix для обеспечения возможности доставки электронной почты

У меня запущено приложение rails, которое отправляет письма, используя postfix в качестве ретранслятора. Вот поток

Rails -> Resque workers -> Postfix -> SES -> электронная почта клиентам

Моя проблема в том, что я хочу найти связь между журналами rails и postfix, чтобы гарантировать, что ни одно электронное письмо не будет потеряно и будет правильно отправлено получателю.

например, если отображаются логи rails, электронное письмо отправляется на адрес "[email protected]"тогда я могу проверить в журналах, куда отправляется электронное письмо[email protected], и я хочу проверить то же самое письмо в postfix тоже. Конечно, там будет запись, но чтобы быть точным и аккуратным, найдите, было ли отправлено это конкретное письмо с помощью postifx или нет? например, получатель может отправить 100 писем[email protected], или может быть 50, с разным интервалом времени, так как я могу добавить какой-либо специальный ТЭГ, ID или что-нибудь еще в приложение rails, чтобы я мог отслеживать это в журналах postifx?

Надеюсь, проблема ясна.

Спасибо

решение1

Если ваш Rails использует SMTP для подключений к Postfix, вас интересует ответ 250:

250 2.0.0 Ok: queued as 41F1A40412

Если вы заставите Rails регистрировать этот идентификатор, то в журналах Postfix будет легко узнать, что с ним произошло дальше:

$ grep 41F1A40412 /var/log/mail.log

postfix/smtpd[1900]: 41F1A40412: client=localhost[127.0.0.1]
postfix/cleanup[1903]: 41F1A40412: message-id=<[email protected]>
postfix/qmgr[29213]: 41F1A40412: from=<[email protected]>, size=299, nrcpt=1 (queue active)
postfix/smtp[1904]: 41F1A40412: to=<[email protected]>, 
    relay=example.net[198.51.100.51]:25, delay=14, delays=13/0.07/0.26/0.71, dsn=2.0.0, 
    status=sent (250 2.0.0 OK 5D47140412)
postfix/qmgr[29213]: 41F1A40412: removed

По крайней мере, deliver.now!метод показывает этот ответ, поскольку он заставляет немедленно отправить. Если этого не происходит с обычным deliverметодом, то, вероятно, это потому, что SMTP по своей конструкции недвусмысленно определяет, кто несет ответственность за доставку сообщения: оно должно удаляться из любой очереди только тогда, когда следующий узел принимает ответственность с самим 250 Okответом.

Связанный контент