У нас есть адрес электронной почты пользователя, который, по нашему мнению, подвергся атаке с использованием обратного рассеивания. Мы не можем найти доказательств взлома учетной записи. Пользователь также заявляет, что он не отправлял ни одного письма, которое ему возвращают. В нашей системе, когда электронное письмо доставляется в почтовый ящик пользователя, в журналах будет отображаться такая строка:
LOCAL(username) delivered: Delivered to the user mailbox
Что мне интересно, так это то, что исходя из количества возвратов, о которых они говорят, что они получают, это не совпадает с тем, сколько из вышеперечисленных строк появляется в журналах, что соответствует количеству писем, возвращаемых в почтовый ящик. Есть мысли по этому поводу?
Сообщения о недоставке должны содержать Received заголовки, показывающие хотя бы некоторые серверы, через которые прошло сообщение. Заголовки писем - ценный ресурс при расследовании подобных проблем. Метод доступа к заголовкам зависит от почтового клиента, некоторые из которых облегчают доступ к источнику сообщения.
Настройка сильной политики SPF, заканчивающейся на -all лайк v=spf1 a mx -all должно уменьшить обратное рассеяние. Однако для этого требуется соответствующая политика. Вы можете просмотреть моя политика как пример.
Спамеры часто используют вымышленный адрес отправителя в исходящих сообщениях. Вполне возможно, что они собирали адрес электронной почты вашего пользователя где-то в последнее десятилетие или два.
Если сообщения имеют обратное рассеяние, вы можете попытаться связаться с администраторами, которые отправляют обратное рассеяние. Однако возможно, что это электронное письмо имеет вид обратного рассеивания. Содержание Received заголовки должны помочь в определении, что есть что.
Полученные заголовки добавляются в верхнюю часть заголовка каждым хостом, который обрабатывает сообщение. IP-адрес в первом заголовке всегда будет правильным. Если нет поддельного заголовка, IP-адрес, если он есть, будет правильным. Заголовки над поддельным заголовком также будут иметь правильные IP-адреса. Помимо IP-адреса должно быть доменное имя отправляющего сервера. В зависимости от того, правильно ли настроен хост-отправитель, в команде EHLO / HELO может использоваться дополнительное доменное имя.
Эти заголовки взяты из недавно полученного сообщения от Facebook. Они используют в команде HELO другое доменное имя, отличное от того, которое определяется проверкой rDNS. Второй заголовок - с сервера facebook, который сгенерировал сообщение. (Получатель запутан, но остальное содержимое не изменилось.)
Received: from 66-220-155-140.outmail.facebook.com ([66.220.155.140] helo=mx-out.facebook.com)
by mail.systemajik.com with esmtps (TLS1.0:ECDHE_RSA_AES_128_CBC_SHA1:128)
(Exim 4.86_2)
(envelope-from <notification+y4krssa@facebookmail.com>)
id 1bdfwX-0005HR-Mp
for someone@example.com; Sat, 27 Aug 2016 11:54:51 -0400
Received: from facebook.com (c4xYYmwT/TJ03btpEcY4vvyPTWZL08E+gbfjjvUwuTSB8dW6JOUncubaoppFzCkE 10.224.41.31)
by facebook.com with Thrift id 915685ca6c6e11e69a620002c9da3c98-2a7fcaa0;
Sat, 27 Aug 2016 08:54:42 -0700 Эти заголовки взяты из недавно полученного спам-сообщения. У этого хоста неверная запись PTR, поэтому проверка rDNS не проходит. Домен в команде HELO действительно проходит проверку rDNS. Второй заголовок - это сообщение, доставленное программой на сервере, отправившей спам. Отсутствующий домен для IP-адреса явно указывает на спам-сообщение.
Received: from [96.30.32.176] (helo=host.sareesbazaar.in)
by mail.systemajik.com with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.86_2)
(envelope-from <bonitto@host.sareesbazaar.in>)
id 1bdgds-0005gm-C8
for someone@example.com; Sat, 27 Aug 2016 12:39:58 -0400
Received: from bonitto by host.sareesbazaar.in with local (Exim 4.87)
(envelope-from <bonitto@host.sareesbazaar.in>)
id 1bdgdg-0004rU-4n
for someone@example.com; Sat, 27 Aug 2016 11:39:24 -0500