Zwarte & witte lijst, TLD blokkeren

[ufosyno]

Ik zit met een klein probleempje, waar volgens mij wel meer gebruikers mee torsen: doodgegooid worden met ongevraagde emails die afkomstig zijn uit een .icu domein.

De eerste slag, die hier al veel van blokkeerde was de SPF verificatie ook de softtail te laten blokkeren. Maar nog steeds komen er ".icu"-mailtjes doorheen. Ik zou graag dat hele TLD laten blokkeren via (nu dan) de zwarte lijst.

Alleen: als ik daar invoer "Email van: *.icu" en dan "weigeren" komen ze er gewoon door. Dit lijkt mij te komen doordat dat niet juist vertaald wordt naar de config van Postfix, want ik heb ergens op het web gelezen, dat Postfix het wel moet kunnen.

Zou iemand mij kunnen vertellen óf, en zo ja hoe, ik inderdaad een heel TLD kan blokkeren? Ik ben alleen niet zo'n held met Linux...

Terzijde, en er toch een klein beetje mee samenhangend: in de helpfile staat dat de mogelijkheden zijn: accepteren, weigeren of negeren. Bij het invoeren zegt het uitklaplijstje: accepteren, weigeren en verwijderen. Wat is nou precies het verschil tussen weigeren en (negeren/)verwijderen?

Alvast dank!

[Briolet]

Je hebt twee witte en zwarte lijsten. Ik heb er ook al eens mee lopen stoeien en het dieper uitgespit. Dat topic is inmiddels ondergesneeuwd. Ik heb hem nu stikcky gemaakt zodat hij beter vindbaar blijft.

De eerste slag, die hier al veel van blokkeerde was de SPF verificatie ook de softtail te laten blokkeren.

Daar moet je er mee oppassen. Heel veel bedrijven hebben hun spf niet in orde. Meestal hebben ze een softfail ingesteld en die mail zal dan nooit aankomen. Meestal betreft het kleine bedrijven, maar ik krijg nu al een jaar mailings uit het "info.bmw.nl" domein waarbij het spf record fout is. Het loopt al een jaar en van een technisch bedrijf als BMW valt me dat tegen. In elk geval een reden om geen BMW meer te kopen want daar zit nog veel complexere techniek in dan een simpel SPF record opstellen.

Bedrijven die een hardfail instellen weten doorgaans beter wat ze doen.

[ufosyno]

Dank Briolet, en ik had twee van de drie ook al gevonden, maar de inhoud overschreed een beetje mijn bevattingsvermogen.

Dat SPF-verificatie riskant is had ik elders ook al opgepikt, maar het begon op mijn mailservertje echt uit de hand te lopen en mijn vrouw en kinderen (de cliënts) begonnen toch te klagen over tientallen junkmails per uur.

Ik probeerde eerst het TLD .icu (en ook .top) te blokkeren via de zwarte lijst, maar daaruit kwam geen verbetering, alleen SPF bracht een paar per uur minder, en toen ik in trial and error dan ook maar de softtail blokkeerde werd het (zelfs: angstig) stil, wat de junk betrof.

Diverse testjes vanuit de zaak en hotmail kwamen allemaal wel over, dus in dat vertrouwen deze instelling even gehandhaaft.

Liever zou ik dat dus via de zwarte lijst doen. En dat kan ik niet uit jouw artikeltjes herleiden hoe ik dat dan zou moeten invullen. En ook het verschil daar tussen weigeren en verwijderen is mij niet helemaal duidelijk

Mijn vermoeden is, dat bij weigeren een bericht naar de afzender gaat, wat ik eigenlijk niet wil, want ook die afzender is vaak een niet bestaand email-adres wat dan een hele bounce-explosie op zou kunnen leveren. En dat is vaak voor providers weer een reden om de boel maar helemaal af te sluiten.

Ik las dit artikel op het web, waaruit ik afleidde dat het wel zou moeten kunnen, maar mijn vraag is dan hoe ik dat dan in de zwarte lijst op moet geven. Mijn kennis van linux is ontoereikend om het via de prompt in het config te schrijven. En daarbij: als er dan weer een update van Synology komt zal het wel weer weg zijn...

Vandaar mijn verzoek om "noodhulp".

[Briolet]

Eigenlijk wist ik niet waar je het over had met weigeren en verwerpen. Dus heb ik zelf even gekeken en zie die opties ook. Volgens mij is die 'verwerpen' optie nieuw.

Maar toch lijkt het me duidelijk. Bij weigeren, dan weigert de mailserver de mail aan te nemen. Bij verwerpen, wordt hij wel aangenomen, maar daarna direct weggegooid.

Ik heb het zelf ook eens getest door mijn ziggo adres op die lijst te zetten. Als ik hem weiger, dan geeft ziggo mij een mailtje terug om te melden dat de mail geweigerd is. Als ik hem verwerp, dan weet ziggo dat niet en gaat er gewoon vanuit dat hij afgeleverd is.

Het maillog geeft dat ook aan:

Verwerpen:
2019-07-26T15:25:32+02:00  postfix/smtpd[12608]: connect from smtpq3.tb.mail.iss.as9143.net[212.54.42.166]
2019-07-26T15:25:32+02:00  postfix/smtpd[12608]: NOQUEUE: discard: RCPT from smtpq3.tb.mail.iss.as9143.net[212.54.42.166]: <xxxx@ziggo.nl>: Sender address triggers DISCARD action; from=<xxxx@ziggo.nl> to=<xxxx@mijndomein.nl> proto=ESMTP helo=<smtpq3.tb.mail.iss.as9143.net>
2019-07-26T15:25:32+02:00  postfix/smtpd[12608]: disconnect from smtpq3.tb.mail.iss.as9143.net[212.54.42.166] ehlo=2 starttls=1 mail=1 rcpt=1 data=1 quit=1 commands=7

Weigeren
2019-07-26T15:28:34+02:00  postfix/smtpd[20594]: connect from smtpq4.tb.mail.iss.as9143.net[212.54.42.167]
2019-07-26T15:28:34+02:00  postfix/smtpd[20594]: NOQUEUE: reject: RCPT from smtpq4.tb.mail.iss.as9143.net[212.54.42.167]: 554 5.7.1 <xxxx@ziggo.nl>: Sender address rejected: Access denied; from=<xxxx@ziggo.nl> to=<xxxx@mijndomein.nl> proto=ESMTP helo=<smtpq4.tb.mail.iss.as9143.net>
2019-07-26T15:28:34+02:00  postfix/smtpd[20594]: disconnect from smtpq4.tb.mail.iss.as9143.net[212.54.42.167] ehlo=2 starttls=1 mail=1 rcpt=0/1 data=0/1 quit=1 commands=5/7

[ufosyno]

Bij mij staat niet "verwerpen" maar "verwijderen" (toch heb ik de laatste updates staan). Maar dat verschil is me nu duidelijk. Wederom dank.

Resteert dan dat wat eigenlijk mijn hoofdvraag was: het blokkeren van een hele TLD, dus van alle domeinen met - in dit geval - .icu op het eind. Want wat daar allemaal vandaan komt wil je niet weten.

Gewoon invoeren bij "Van adres bevat" van bijv.   .icu, *.icu of alleen icu geeft geen blokkerend resultaat. Er zit dus of iets in het doorzetten naar de config, of er is een syntax-vereiste, die ik niet ken.

Als we er dus achter kunnen komen wat DSM met het ingevoerde doet richting config (tekens ervoor en/of erachter) én het verhaal waar ik al naar verwees, dan kunnen we misschien ook via de zwarte lijst een heel TLD blokkeren. En dat is wat ik hoop...


 

[Briolet]

Misschien mag een TLD niet.

Als ik "gmail.com" blokkeer, dan komen geen gmail mailtjes binnen.
Als is dan ".com" of "*.com" blokkeer komen de gmailtjes wel binnen.

[ufosyno]

Het niet mogen blokkeren van een TLD zou dan een Synology-beslissing zijn... want ook bij Postfix.org lees ik dat het zou moeten kunnen. Met als syntax  /\.tld$/

Als ik er nu vanuit ga, dat de beide slashes frondt and tail door syno worden toegevoegd... ik heb een testje gestart waar is \.tls$ invoer bij adres van bevat. Dan de softtail blokkade weer uit en gaan afwachten. Dat kan nu wel even een uurtje duren, denk ik.

Ik kom er (na het eten  ) op terug!

[ufosyno]

Eten op... 

"\.icu$" bij "van: adres bevat" doet 't niet goed, de eerste waren alweer binnen.

Nu dit ingevoerd bij "van: adres bevat dit domein" en weer afwachten.

[Briolet]

Uren wachten hoeft niet als je het aandurft om even een gewoon TLD te blokkeren. Je kunt ook "\.com$" blokkeren, dan jezelf een mail sturen van een .com adres, even wachten en dan direct weer terug zetten.

In theorie kan er een regulier mailte bouncen in die ene minuut, maar in het log kun je de afzender zien.

In elk geval is het plaatsen bij "adres bevat" fout. Zie mijn reactie in het sticky topic. De nas interpreteert dat als: ".icu$@mijndomijn.nl". Het beste zie je dat door de instellingen te exporteren. Dat is een platte tekstfile waarin je ziet hoe het aan postfix aangeboden wordt.

Als ik bij "Van adres bevat dit domein" de tekst "\.com$" invul, dan staat dit ook letterlijk in de file "regels voor afzenders exporteren. As ik mezelf iets van gmail.com stuur, komt het gewoon aan. Invullen van "gmail.com" blokkeert die mail wel.

[Briolet]

Ik heb nog even verder gezocht. Ik denk dat deze post relevant is. Daar staat dat als "smtpd_sender_restrictions" een hash file is, hij geen wildcards kent, alleen exacte matches.

En in mail.cf heeft synology gedefinieerd:

smtpd_client_restrictions = check_client_access hash:/var/packages/MailServer/target/etc/access/client_access, permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination

Die limitering lijkt me dus ook hier van toepassing. Als je het wilt blokkeren moet je direct in postfix editen en niet via de GUI van synology.

Leerzaam, want ik gebruik ook wildcards. Als ik de help van synology lees, staat er ook niets over wildcards.   Wildcards kun je zeker gebruiken in de zwarte en witte lijst bij spam. Maar die lijst wordt ook door een heel ander programma uitgelezen. Niet door Postfix.

[ufosyno]

Begint mijn "probleem"ook jou te interesseren? Het lijkt er in elk geval wel op. En ach.. ik ben blijkbaar minder slim door me alleen op die .icu te concentreren (zie dat als een compliment aan jou!). Respect voor je ervaringsniveau!

Intussen ben ik er ook achter, dat het via de zwarte en witte lijst niet werkt en dat vind ik jammer. Misschien maar 's een "wish-ticket" ingeven bij Synology, want zeker door de nieuw toegevoegde TLD's ontstaat deze wens. Ik denk daarbij ook aan .xyz en .zip en nog meer van zulke fancy TLD's waar ik nog nooit een normaal mailtje van binnen heb gekregen.

Maar je benoemt ook een andere plaats. Ik neem aan, dat je nu Spamassassin bedoelt. Daar heb ik ook al in zitten kijken en kwam daar "Aangepast spamfilter" tegen... zou daar dan wel via wildcards een heel TLD geblokkeerd worden? De help-info daarover is wel verschrikkelijk summier. Heb jij daar ervaring?

[Briolet]

Bij die andere blacklist kun je er alleen voor zorgen dat mail als spam gezien gaat worden en direct naar de spambox gaat.

Ik heb even op de postfixpagina gekeken bij het hoofdstuk "PCRE_TABLE".  De afkorting staat voor "Perl Compatible Regular Expression form". Alleen dan kun je de syntax uit je eerste link gebruiken. En de / aan het begin en eind horen er dan bij.

Voor de gemiddelde gebruiker is zo'n Perl syntax te hoog gegrepen en heeft Synlology voor lijsten in het HASH formaat gekozen. Je kunt dat wel allemaal overrulen en zelf alles rechtstreeks in postfix instellen. Dat vereist echter weer de nodige kennis hoe alles 'onder water' bij Synology werkt. En na elke update van mailserver kunnen je files overschreven worden. Daarom heb ik inmiddels een eigen script geschreven die ik na een update run en die mijn aanpassingen er weer in zet.

[ufosyno]

Het verschil begint me duidelijk te worden. Ik ging naar de SPAM-tab en koos daar "aangepaste instellingen" en dan op "maken".

Dan krijg je weer hetzelfde schermpje met in de kop notabene "Zwarte en witte lijsten". Daar bij "Van: adres bevat dit domein" heb ik nu "*.icu" ingevuld met als actie "markeren als spam".

De .icu emails gaan nu keurig als --spam-- gemarkeerd de junk-mailbox in. Hèhè, rust in Postvak in  .

Op dit punt nu nogmaals dank; voor je geduld, je tijd en voor je kennis!

[Briolet]

Ik ben er inmiddels uit hoe je een TLD moet blokkeren. Eigenlijk waanzinnig simpel. 

Ik zat hier in de postfix handleiding te lezen bij "EMAIL ADDRESS PATTERNS". Daarin las ik hoe hij subdomeinen meeneemt. Afhankelijk van een instelling elders doet hij dat juist wel of juist niet als de voorloop punt er staat. Blijkbaar staat het nu zo dat die punt er niet moet staan.

Dus bij afzenddomein bevat ".com" kijkt hij niet naar subdomeinen ervan. Dus is er nooit een match. Als je daarentegen "com" invult, dan neemt hij ook alle subdomeinen van com mee. Dus ik heb dat net ingesteld en mezelf een mail vanuit gmail gestuurd. Die komt niet aan en het mail-log geeft:

2019-07-27T12:09:48+02:00 postfix/smtpd[22711]: connect from mail-ed1-f54.google.com[209.85.208.54]
2019-07-27T12:09:48+02:00 postfix/smtpd[22711]: NOQUEUE: discard: RCPT from mail-ed1-f54.google.com[209.85.208.54]: <xxxx@gmail.com>: Sender address triggers DISCARD action; from=<xxxx@gmail.com> to=<xxxx@mijndomein.nl> proto=ESMTP helo=<mail-ed1-f54.google.com>
2019-07-27T12:09:48+02:00 postfix/smtpd[22711]: disconnect from mail-ed1-f54.google.com[209.85.208.54] ehlo=2 starttls=1 mail=1 rcpt=1 data=1 quit=1 commands=7

Hij wordt netjes verworpen. Dus als je de voorloop punt weglaat werkt het wel op TLD's.

Ik moet mijn lijst dus ook aanpassen en de * symbolen weghalen (Kent geen wildcards) en de voorloop punten wegdoen.

[ufosyno]

Waar doe je dit dan nu, in de "Zwarte en Witte lijst" of bij de Spamassassin-instellingen?

En hoe gaat hij dan om met het door mij bedachte voorbeeld-domein  telecom.nl? Daarin staat ook COM en dus lijkt hij mij die dan ook te weigeren. Voorlopig lijkt het bij de Spamassassin-instellingen met *.TLD te werken...