Почему пустой адрес MAIL FROM можно отправить по электронной почте?

Мы используем систему Smarter Mail. Недавно мы обнаружили, что хакер взломал некоторые учетные записи пользователей и разослал много спама. У нас есть брандмауэр для ограничения скорости отправителя, но для следующего письма брандмауэр не может сделать это из-за пустого адреса FROM. Почему пустой адрес ОТ считается ОК? На самом деле, в нашем MTA (surgemail) мы можем видеть отправителя в заголовке письма. Есть идеи?

11:17:06 [xx.xx.xx.xx][15459629] rsp: 220 mail30.server.com
11:17:06 [xx.xx.xx.xx][15459629] connected at 6/16/2010 11:17:06 AM
11:17:06 [xx.xx.xx.xx][15459629] cmd: EHLO ulix.geo.auth.gr
11:17:06 [xx.xx.xx.xx][15459629] rsp: 250-mail30.server.com Hello [xx.xx.xx.xx] 250-SIZE 31457280 250-AUTH LOGIN CRAM-MD5 250 OK
11:17:06 [xx.xx.xx.xx][15459629] cmd: AUTH LOGIN
11:17:06 [xx.xx.xx.xx][15459629] rsp: 334 VXNlcm5hbWU6
11:17:07 [xx.xx.xx.xx][15459629] rsp: 334 UGFzc3dvcmQ6
11:17:07 [xx.xx.xx.xx][15459629] rsp: 235 Authentication successful
11:17:07 [xx.xx.xx.xx][15459629] Authenticated as hackedaccount@domain1.com
11:17:07 [xx.xx.xx.xx][15459629] cmd: MAIL FROM:
11:17:07 [xx.xx.xx.xx][15459629] rsp: 250 OK <> Sender ok
11:17:07 [xx.xx.xx.xx][15459629] cmd: RCPT TO:recipient@domain2.com
11:17:07 [xx.xx.xx.xx][15459629] rsp: 250 OK <recipient@domain2.com> Recipient ok
11:17:08 [xx.xx.xx.xx][15459629] cmd: DATA

Пустой MAIL FROMиспользуется для уведомлений о статусе доставки. Почтовые серверы должны поддерживать его ( RFC 1123 раздел 5.2.9 ).

Он используется в основном для отказов сообщений, чтобы предотвратить бесконечный цикл. Когда MAIL FROMиспользуется с пустым адресом (представленным как <>), принимающий сервер знает, что не следует генерировать сообщение о сбое, если сообщение отправляется несуществующему пользователю.

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

Что произойдет, если вы заблокируете сообщения с пустым MAIL FROM:?

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

Пустые MAIL FROM:сообщения, которые вы видите, вероятно, не приходят от спаммера.

Вместо этого спамер подделал адрес в вашем домене и использовал его в качестве обратного адреса для сообщения в другой домен. Допустим, вы yourdomain.comи мой домен mydomain.net. Спамер отправляет сообщение johnq@mydomain.net, подделывая обратный адрес как johnq@yourdomain.com. Поскольку нет ни одного пользователя johnqв моем домене, мой почтовый сервер посылает сообщение о недоставке ( MAIL FROM:<>) для явного отправителя johnq@yourdomain.com. Это то, что вы, вероятно, видите.

На MAIL FROMмой взгляд, блокировка пустых сообщений принесет больше вреда, чем пользы. Спаммеры, по моему опыту, редко используют пустые, MAIL FROM:поскольку они могут легко подделать реально выглядящий адрес. Когда сообщение является фактическим спамом, существуют гораздо лучшие способы его обнаружения и блокировки, включая RBL, байесовские фильтры и SpamAssassin.

И, наконец, вы можете предотвратить использование некоторых подделок yourdomain.com, настроив соответствующие записи SPF для своего домена.

Обновление. После тщательного изучения вашего журнала кто-то смог AUTHиспользовать действительные имя пользователя и пароль для вашего сервера. Это ставит его в совершенно другую категорию проблем. Однако все, о чем я говорил, MAIL FROM:все еще остается в силе. 99% времени это будет результатом отказов сообщений.

Вы можете найти опцию для своего почтового сервера, чтобы ограничить MAIL FROM электронной почтой, прошедшей аутентификацию. Многие почтовые системы применяют это ограничение.

И так, заставить взломанных пользователей сменить пароль.