Меня это немного беспокоит, поскольку я запускаю небольшой сервер, на котором размещено несколько веб-сайтов, и управляю электронной почтой для нескольких десятков человек.
Совсем недавно у меня было несколько уведомлений от spamcop, предупреждающих меня о том, что с моего сервера был отправлен спам, и когда я время от времени просматриваю журналы, я действительно вижу, что было много повторных попыток отправки почты. отправлено с моего сервера. В большинстве случаев он отбрасывается от серверов назначения, но иногда проходит.
К сожалению, я не эксперт по Linux или постфиксам, я могу обойтись, но, хотя моя машина была заблокирована довольно надежно, я не разрешаю ретрансляцию, когда я проверяю онлайн-инструменты DNS / MX, они, как правило, сообщают, что мой сервер Хорошо, поэтому я не уверен, где это сейчас взять, и надеюсь, что кто-то сможет дать мне несколько указаний.
Я получаю много таких записей в моем журнале MAIL.INFO
Jan 2 08:39:34 Debian-50-lenny-64-LAMP postfix/qmgr[15993]: 66B88257C12F: from=<>, size=3116, nrcpt=1 (queue active)
Jan 2 08:39:34 Debian-50-lenny-64-LAMP postfix/qmgr[15993]: 614C2257C1BC: from=<notice@tademe.co.nz>, size=2490, nrcpt=3 (queue active)
и
Jan 7 16:09:37 Debian-50-lenny-64-LAMP postfix/error[6471]: 0A316257C204: to=<notice@tademe.com>, relay=none, delay=384387, delays=384384/3/0/0.01, dsn=4.0.0, status=deferred (delivery temporarily suspended: host mx.fakemx.net[46.4.35.23] refused to talk to me: 421 mx.fakemx.net Service Unavailable)
Jan 7 16:09:37 Debian-50-lenny-64-LAMP postfix/error[6470]: 5848C257C20D: to=<notice@tademe.com>, relay=none, delay=384373, delays=384370/3/0/0.01, dsn=4.0.0, status=deferred (delivery temporarily suspended: host mx.fakemx.net[46.4.35.23] refused to talk to me: 421 mx.fakemx.net Service Unavailable)
то, как правило, возникают таймауты соединения, поэтому, судя по тому, что я вижу, даже если у меня отключена ретрансляция ... что-то проходит и пытается отправить ..
Так что, если вы можете помочь, я буду очень признателен, а также любую дополнительную информацию о журналах / конфигурации, которую я могу предоставить.
Несколько строк из Main.CF, которые, как мне показалось, были достаточными, выглядят следующим образом: возможно, я упускаю что-то важное:
# Requirements for the HELO statement
smtpd_helo_restrictions = permit_mynetworks, warn_if_reject reject_non_fqdn_hostname, reject_invalid_hostname, permit
# Requirements for the sender details
smtpd_sender_restrictions = permit_mynetworks, warn_if_reject reject_non_fqdn_sender, reject_unknown_sender_domain, reject_unauth_pipelining, permit
# Requirements for the connecting server
smtpd_client_restrictions = reject_rbl_client sbl.spamhaus.org, reject_rbl_client blackholes.easynet.nl, reject_rbl_client dnsbl.njabl.org
# Requirement for the recipient address
#smtpd_recipient_restrictions = reject_unauth_pipelining, permit_mynetworks, reject_non_fqdn_recipient, reject_unknown_recipient_domain, reject_unauth_destination, permit
smtpd_recipient_restrictions = reject_unauth_pipelining,reject_non_fqdn_recipient,reject_unknown_recipient_domain,permit_sasl_authenticated,permit_mynetworks,reject_unauth_destination,check_policy_service inet:127.0.0.1:60000,permit
# require proper helo at connections
smtpd_helo_required = yes
# waste spammers time before rejecting them
smtpd_delay_reject = yes
disable_vrfy_command = yes
Спасибо
Вы должны почти никогда использовать permit. Только использовать квалифицированный разрешительные директивы (т.е. permit_mynetworks, permit_sasl_authenticated, и т.д).
Имея permit в конце ваших ограничений причина неприятностей. Если это не разрешено заранее с permit_mynetworks тогда вы не хотите возиться с тем, что отправляется в вашу почтовую очередь. Удалите те permit записи с конца вашего *_restrictions линий, и вы увидите внезапное улучшение. Что происходит, так это то, что некоторые попытки ретрансляции спама «просто соответствуют», чтобы пройти через список ограничений (эти записи перед permit), поэтому, когда он проходит по списку тестов, которые нужно пройти в списке ограничений, он попадает в permit который дает команду postfix поставить "большой палец вверх", и он продолжает обработку и ретрансляцию отправляемого спама.
Я предполагаю (?), Что у вас есть permit заявления, чтобы предотвратить блокировку электронной почты законными клиентами. Не беспокойтесь о отключении вашей сети. Это то что mynetworks для: это список «доверенных» сетевых адресов, на которые вы будете автоматически принимать и пересылать почту. Вход permit_mynetworks в начале указывает postfix немедленно разрешить все, что определено в mynetworks и в этот момент он перестает обрабатывать шаги, перечисленные в вашем *_restrictions список. Это потому, что список тестов обрабатывается слева направо, пока не будет найдено совпадение. С помощью permit в конце каждой строки указывает системе разрешить отправку почты без ограничений, если она прошла все другие тесты перед permit настройка.
Вы думали, что у вас отключено реле, но так ли? Вам нужно будет опубликовать информацию из вашего конфигурационного файла или Google для чего-то вроде «отключить реле» и имени вашего MTA-приложения, чтобы найти образец информации о блокировке, чтобы укрепить вашу систему.
В противном случае либо кто-то, кому вы разрешаете отправлять почту через вашу систему, чем-то заражен и использует ваш сервер для рассылки спама, либо кто-то проник на ваш сервер и заразил его скриптами для рассылки спама.
Вы проверяли, не работают ли необычные службы? Проверить в логах руткиты или что-нибудь необычное? Какие еще службы у вас запущены на сервере? Вы проверяли необычные входящие TCP-соединения? Как вы блокируете систему только для авторизованных пользователей, например, из вашей собственной подсети, определенных паролей (которые могли быть взломаны), только авторизованных IP-адресов ...?