Onderwerp: postfix & spamruns

De laatste tijd heb ik op een ukraine lokatie ontzettend veel last van spamruns op mijn postfix install, dit is een install voor fallback-mx.

De eerste keer dat ik aanpassing gedaan had was de helo restrictie:

smtpd_require_helo = yes

Dit ging redelijk oke totdat de laatste tijd er weer heel veel geprobeerd wordt om de mail er door hene te duwen.

Volgende aanpassing waren de rbl toevoegen aan de setup:

smtpd_client_restrictions = permit_mynetworks,
reject_rbl_client relays.ordb.org,
reject_rbl_client sbl.spamhaus.org,
permit

Het lijkt aardig te werken, maar kan iemand mij vertellen hoe ik kan testen of bovenstaand ook echt werkt ? En wat ik verder nog kan doen, filters like spamassasin zijn geen optie omdat de mail schoon (af)geleverd moet worden.

Normaal zieje in postfix daar (vaak) heel veel entries van. Wat me wel opvalt is dat je best weinig blocklists gebruikt. Deze gebruiken wij:


smtpd_recipient_restrictions =
permit_mynetworks,
reject_rbl_client zombie.dnsbl.sorbs.net,
reject_rbl_client relays.ordb.org,
reject_rbl_client opm.blitzed.org,
reject_rbl_client list.dsbl.org,
reject_rbl_client sbl.spamhaus.org,
reject_rbl_client flowgoaway.com,
reject_rbl_client dailups.visi.com,
reject_rbl_client blackholes.easynet.nl,
reject_rbl_client multihop.dsbl.org,
reject_rbl_client dnsbl.njabl.org,
reject_rbl_client combined.njabl.org,
reject_rbl_client dnsbl.sorbs.net,
reject_rbl_client dsn.rfc-ignorant.org,
reject_rbl_client sbl-xbl.spamhaus.org,
reject_rbl_client virbl.dnsbl.bit.nl,
reject_unauth_destination,
permit

Werkt best goed eigenlijk!

Ja, kan wel heel veel blocklist gana gebruiken, maar als er een gebruiker is die het platform de lijst in jaagt werkt de fallback-mx ook niet , dat is ook hetgeen wat me tegenhoud om hem compleet uit te gaan rusten mbt anti spam.

hmmjah, vervelende situatie. Of je moet juist selectief wat blacklists gaan gebruiken. Spamcop is iig niet een goede optie want die zet volgens mij echt ALLES op zn lijst.

Hier nog een aantal dingen die je kan proberen (postfix 2.2) :
(edit: de SASL entries kan je weglaten als je users niet via die server mail kunnen sturen)

strict_rfc821_envelopes = yes

smtpd_helo_required = yes
smtpd_helo_restrictions =
permit_mynetworks,
permit_sasl_authenticated,
reject_unauth_pipelining,
# de volgende 3 blocken te veel non-spam, is mijn ervaring
# reject_non_fqdn_hostname,
# reject_unknown_hostname,
# reject_invalid_hostname,
permit

smtpd_sender_restrictions =
permit_mynetworks,
permit_sasl_authenticated,
reject_non_fqdn_sender,
reject_unknown_sender_domain,
reject_rhsbl_sender dsn.rfc-ignorant.org,
permit

smtpd_recipient_restrictions =
permit_mynetworks,
permit_sasl_authenticated,
reject_unauth_destination,
# de volgende entry houdt best een hoop tegen, maar is strict genomen
# NIET RFC compliant. Het veroorzaakt voor zover ik weet geen problemen
reject_multi_recipient_bounce,
reject_non_fqdn_recipient,
reject_unknown_recipient_domain

disable_vrfy_command = yes
smtpd_etrn_restriction = reject
bounce_size_limit = 65536
header_size_limit = 32768
smtpd_recipient_limit = 128
smtpd_timeout = 180

allow_untrusted_routing = no
smtpd_soft_error_limit = 10
smtpd_hard_error_limit = 20
smtpd_error_sleep_time = 1s


En of 't werkt, zie je uiteraard in de logfile, (bijv /var/log/mail.log), er staan dan entries zoals deze (ip's/hostnamen deels vervangen door *):

postfix/smtpd[pid]: NOQUEUE: reject: RCPT from unknown[194.185.*]: 554 Service unavailable; Client host [194.185.*] blocked using bl.spamcop.net; Blocked - see http://www.spamcop.net/bl.shtml?194.185.*; from=<*> to=<*> proto=ESMTP helo=<*>

hmmmz zal met bovenstaand eens gaan experimenteren. In ieder geval dusver bedankt !

Geen probleem!

Vergeet niet om je logfile goed in de gaten te houden als je met dit soort filters aan de gang gaat, want filters die bij de 1 perfect werken, kunnen bij een ander soms ongewenste effecten hebben

Heb dus een paar aanpassingen overgenomen van Jurian en de sbl van rayden, config op platform ook aangepast zodat het geen probleem zou kunnen geven. Ben alleen al compleet verbluft wat het scheelt in de load van het systeem, alleen die 554's voorkomen al die smtp process die een relay access denieg terug zouden geven. Ik ga het nog verder aankijken maar ben hier al vrij tevreden mee

Oorspronkelijk geplaatst door Mikey

Ben alleen al compleet verbluft wat het scheelt in de load van het systeem, alleen die 554's voorkomen al die smtp process die een relay access denieg terug zouden geven. Ik ga het nog verder aankijken maar ben hier al vrij tevreden mee

554's? Je hebt toch een SMTP service draaien?!

554 Transaction failed (Or, in the case of a connection-opening
response, "No SMTP service here")

Mijns inziens moet je een 550 geven

550 Requested action not taken: mailbox unavailable
(e.g., mailbox not found, no access, or command rejected
for policy reasons)

Duik maar eens in RFC 2821 (zie o.a "3.1 Session Initiation" en "4.2.3 Reply Codes in Numeric Order"). Geen idee hoe je uberhaupt al aan die 554's komt, daar een reject op (bijvoorbeeld) een rbl sowieso al een 550 moet geven. Of een 450 om een tijdelijke foutmelding te genereren.

Afhankelijk van de reden waarom de mail niet geaccepteerd wordt, kan postfix wel degelijk een error 554 generen:

554 Service unavailable; <insert reden hier>

Stukje uit de postfix manual:

reject_rbl_client domain.tld
Reject the request when the reversed client network address is listed with an A record under domain.tld. The maps_rbl_reject_code parameter specifies the response code for rejected requests (default: 554), the default_rbl_reply parameter specifies the default server reply, and the rbl_reply_maps parameter specifies tables with server replies indexed by RBL domain.

Hij default dus naar 554 bij reject_rbl_client, waarom dit precies is weet ik niet, maar er zit vast een goede reden achter. Normaal zou je inderdaad een 550 verwachten.

Zie ook http://www.postfix.org/uce.html

Ik ben en blijf strikt volgens de RFC's en dan zou je toch echt geen 554 verwachten
RFC 2821

3.1 Session Initiation

An SMTP session is initiated when a client opens a connection to a
server and the server responds with an opening message.
[...]
The SMTP protocol allows a server to formally reject a transaction
while still allowing the initial connection as follows: a 554
response MAY be given in the initial connection opening message
instead of the 220. A server taking this approach MUST still wait
for the client to send a QUIT (see section 4.1.1.10) before closing
the connection and SHOULD respond to any intervening commands with
"503 bad sequence of commands". Since an attempt to make an SMTP
connection to such a system is probably in error, a server returning
a 554 response on connection opening SHOULD provide enough
information in the reply text to facilitate debugging of the sending
system.

Dus met andere woorden: Een SMTP server mag wel een 554 geven, maar moet dan een reden opgeven worden en moet de verbinding open blijven tot de client een QUIT commando stuurt. Dit blijft resources kosten en houdt verbindingen open (van het maximum aantal gelijktijdige verbindingen dat je kan verwerken).
En

554 Transaction failed (Or, in the case of a connection-opening
response, "No SMTP service here")

Zodra je een 554 code geeft bij het openen (door de client) van een SMTP verbinding, verklaart je SMTP server geen SMTP server te zijn (...).

Verder kan ik op http://www.postfix.org/uce.html geen reden ondekken waarom je een 554 code zou willen geven, enkel dat het de Postfix default is.

(en ik dram maar door en door )

Ik ben zelf ook pro conform rfc's , maar als een spammer zich er niet aan houdt waarom zou ik mij er dan aan houden door een connectie open te houden en wachten op een QUIT. Scum met scum bestreiden... Ik moet de resources en belasting drukken op het systeem, en als ik zo kijk dan werkt dit ondanks het niet de netste methode is wel goed. Van een gem. load 6 ~ 7 terug naar 2 ~ 3. Dus je snapt wel dat ik ondanks rfc, toch stiekum in mijn handjes klap

Dit zijn van die dingetjes die inderdaad niet volgens de RFC's gaan, maar daardoor vaak wel net iets beter werken. In dit geval zal je er (zo goed als) geen echte email mee blocken en puur spammers hinderen. Zoals Mikey als zegt, als de spammers zich niet aan de RFC houden bij 't bestoken van m'n mailserver, dan hoef ik me niet aan de RFC te houden bij 't verdedigen tegen die spammers.

Uiteraard betekent dit niet dat je dan zomaar de RFC's gaat negeren als 't maar even zo uitkomt, maar er zijn uitzonderingen (IMHO) en dit is er 1

Zolang er geen legitieme mail(servers) mee gehinderd worden, is deze afwijking van de RFC toelaatbaar (again, IMHO).