Onderwerp: dubbele mx records tegen spam

Hi All,

In het kader van spambestrijding het volgende. Omdat wij onze mailfallback buiten ons eigen netwerk laten afhandelen hebben we weinig invloed op de acceptatie van e-mail op deze machines. Omdat we recentelijk constateerder dat spammers op steeds grotere schaal gebruik gaan maken van MX-records met een hogere preference, om blacklisting tegen te gaan heb ik de volgende breinbreker voor de echte guru's.

Mijn idee was om meerdere MX-records aan te leggen met het zelfde doel als het MX record met de laagste preference. Normaliter zou een smtp-server het record gebruiken met de laagste preference. Nu denk ik dat de spammers alle mx-records uitlezen. In de RFC's ben ik nergens tegen gekomen dat het niet mag, voorts geeft named-checkzone ook geen foutmeldingen.

Mijn vraag aan jullie, denken jullie dat dit zou helpen om te voorkomen dat de fallbackserver zo vaak wordt aangesproken of moeten we van de week maar gewoon een eigen fallback server gaan plaatsen?

Gr,

Almar

Vind het bepaald geen fraaie oplossing, denk ook dat het op termijn geen oplossing is..

Wij draaien eigen fallback mx servers die toevallig wat gemener voor spam zijn dan de normale.. Valsspelen kan ik ook

Oorspronkelijk geplaatst door crazycoder

Vind het bepaald geen fraaie oplossing, denk ook dat het op termijn geen oplossing is..

Wij draaien eigen fallback mx servers die toevallig wat gemener voor spam zijn dan de normale.. Valsspelen kan ik ook

Ook hier is de fallback ingesteld dat deze contacten stalled als de helo/ehlo niet kloppen e.d. (lees een bericht bezorgen kan dan gerust +1minuut duren ). Verder draaien op de fallback ook de rbl's mee. Het enige dat echt mist is SpamAssassin.

Ik kwam pas ook al iemand tegen die dit gebruikte... alleen die liet de boel verwijzen naar een hostname die op zijn buurt verwees naar een niet-gebruikt / niet bestaand ip-adres...

Niet netjes, maar technisch geen probleem lijkt me: als er wel een mailserver op zou draaien zou die ook onbereikbaar kunnen worden... en echte mail zal toch eerst proberen op de echte mailserver te connecten.

Ik denk dat ik het eens ga proberen op een domeintje om te testen... iemand nog een voorstel voor een leuk ip-adres? 127.0.0.1 lijkt me problemen geven, net als de reeksen die gereserveerd zijn voor intern gebruikt.

Oorspronkelijk geplaatst door jurrian

Ik kwam pas ook al iemand tegen die dit gebruikte... alleen die liet de boel verwijzen naar een hostname die op zijn buurt verwees naar een niet-gebruikt / niet bestaand ip-adres...

Niet netjes, maar technisch geen probleem lijkt me: als er wel een mailserver op zou draaien zou die ook onbereikbaar kunnen worden... en echte mail zal toch eerst proberen op de echte mailserver te connecten.

Ik denk dat ik het eens ga proberen op een domeintje om te testen... iemand nog een voorstel voor een leuk ip-adres? 127.0.0.1 lijkt me problemen geven, net als de reeksen die gereserveerd zijn voor intern gebruikt.

Dat soort mail stuur je toch gewoon door naar een concurrent die je normaliter de bloed onder je nagels weghaalt

Oorspronkelijk geplaatst door Mikey

Dat soort mail stuur je toch gewoon door naar een concurrent die je normaliter de bloed onder je nagels weghaalt

Leuk idee, maar dan zal de server van je concurent zeggen dat hij geen mail accepteert voor dit domein... en dan gaat evt. echte mail die daar terrecht komt dus ook retour afzender...

Ik zit nu te denken aan een leuk programmatje dat aan 'bezigheidsterapie voor spammers' doet... dus lekker traag reageren op de commando's die binnenkomen enzo... en uiteindelijk zeggen dat het hele boeltje mislukt is... dan heeft het de spammer ondertussen een hoop kostbare tijd gekost (zeker als je 'm een aantal minuten weet bezig te houden).

Oorspronkelijk geplaatst door jurrian

Ik kwam pas ook al iemand tegen die dit gebruikte... alleen die liet de boel verwijzen naar een hostname die op zijn buurt verwees naar een niet-gebruikt / niet bestaand ip-adres...

Niet netjes, maar technisch geen probleem lijkt me: als er wel een mailserver op zou draaien zou die ook onbereikbaar kunnen worden... en echte mail zal toch eerst proberen op de echte mailserver te connecten.

Ik denk dat ik het eens ga proberen op een domeintje om te testen... iemand nog een voorstel voor een leuk ip-adres? 127.0.0.1 lijkt me problemen geven, net als de reeksen die gereserveerd zijn voor intern gebruikt.

Jouw klanten gaan blij met je zijn

Vooral spammers schijnen het leuk te vinden om een ip in de private range op te geven.

Bedenk dat echte mail soms ook op de fallback binnen komt, als die niet af te leveren is gaat het niet goed komen..

Oorspronkelijk geplaatst door jurrian

Ik zit nu te denken aan een leuk programmatje dat aan 'bezigheidsterapie voor spammers' doet... dus lekker traag reageren op de commando's die binnenkomen enzo... en uiteindelijk zeggen dat het hele boeltje mislukt is... dan heeft het de spammer ondertussen een hoop kostbare tijd gekost (zeker als je 'm een aantal minuten weet bezig te houden).

Wat trager reageren is zeker een mogelijkheid. Het zal zelfs een deel van de spam stoppen.. Alhoewel ik niet weet hoe bijvoorbeeld mailinglijsten hierop gaan reageren.. Denk dat klanten die lid zijn van een aantal yahoogroepen hier mogelijk problemen gaan ondervinden.

Beetje beter lezen he!

Deze "fake" server geef je op als mailhost met de laatste prioriteit (hoogste nummer dus). Daarnaast heb je 1 of 2 andere servers staan, die de mail eerst op zullen vangen (als de verzender zich keurig aan de standaarden houdt). Spammers beginnen meestal bij de fallback-servers, omdat deze vaak geen spam-filtering hebben.

Dat die fake-server geen mail-server heeft draaien (of helemaal geen server op dat ip) of een programma dat de andere server een tijdje bezig houdt en vervolgens de boel alsnog weigert kan geen kwaad als het echte mail is... het is alleen lastig voor de verzender.

Ik weet dat ze bij de UT alle eerste connecties van mailservers rejecten met 'too busy'. De spammers proberen het geen tweede keer maar gewone mailservers proberen het enkele minuten later gewoon nog eens. Dit zorgde bij hun voor een flinke daling in het aantal spam mailtjes.

Een niet bestaande MX opgeven lijkt me niet echt de netste oplossing.

Oorspronkelijk geplaatst door jurrian

Dat die fake-server geen mail-server heeft draaien (of helemaal geen server op dat ip) of een programma dat de andere server een tijdje bezig houdt en vervolgens de boel alsnog weigert kan geen kwaad als het echte mail is... het is alleen lastig voor de verzender.

Aaah.. okee.. dacht dat jij een van de prive ranges wilde gebruiken..

Tijdje bezig houden kan beslist geen kwaad, is zelfs beter dan geen mailserver draaien. Al was het alleen maar om de spammer te vertragen.

Mail bewust traag afhandelen zal hierin geen optie zijn, qmail timed out dacht ik bij 30 seconden of meer. En die spammer zal het een worst wezen, als je 1000 threads 30 seconden vertraagt, die vertraging is eenmalig waarna hij gevoelsmatig gewoon weer even hard gaat.

Ik zou de fallback uitrusten met wat controlles op rfc basis en rbl en het hierbij laten,

Oorspronkelijk geplaatst door crazycoder

Vind het bepaald geen fraaie oplossing, denk ook dat het op termijn geen oplossing is..

Wij draaien eigen fallback mx servers die toevallig wat gemener voor spam zijn dan de normale.. Valsspelen kan ik ook

Het idee is dat wij dit niet binnen het netwerk willen hebben draaien. Ik denk dat we een server op een derde locatie gaan plaatsen hiervoor.

Ik ben al een tijdje aan het testen met een derde "mailserver" die niets meer doet dan "too busy" terug geven en het ip van de verzendende parij op mijn eigen blacklist plaatsen. Deze blacklist wordt vervolgens weer op de normale servers gebruikt en dat werkt als een speer ;-) Ik heb het systeem nog niet kunnen betrappen op het onterecht blacklisten van echte mailservers.
Als een van mijn normale servers op zijn gat gaat wordt de blacklist automatisch gewiste en gaat deze pas weer in werking als alle servers draaien...

Het systeem is op dit moment nog expirimenteel maar het ziet er wel naar uit dat het binnekort in productie gaat

Oorspronkelijk geplaatst door mind

Ik ben al een tijdje aan het testen met een derde "mailserver" die niets meer doet dan "too busy" terug geven en het ip van de verzendende parij op mijn eigen blacklist plaatsen. Deze blacklist wordt vervolgens weer op de normale servers gebruikt en dat werkt als een speer ;-) Ik heb het systeem nog niet kunnen betrappen op het onterecht blacklisten van echte mailservers.
Als een van mijn normale servers op zijn gat gaat wordt de blacklist automatisch gewiste en gaat deze pas weer in werking als alle servers draaien...

Het systeem is op dit moment nog expirimenteel maar het ziet er wel naar uit dat het binnekort in productie gaat

Wil niet vervelend doen, maar bepaalde MTA's sturen grote mails bewust over een mx met een lagere prio. En in jouw geval zal dit niet meer werken....?!

Oorspronkelijk geplaatst door Mikey

Wil niet vervelend doen, maar bepaalde MTA's sturen grote mails bewust over een mx met een lagere prio. En in jouw geval zal dit niet meer werken....?!

Dit zou inderdaad een probleem kunnen zijn. Ik zou overigens wel graag willen weten welke MTA's dit gedrag hebben. Het is volgens mij nl. wel in strijd met de nodige RFC's om op deze manier mail af te leveren.
Het gebruik van welke blacklist dan ook heeft een prijs... Als dit in mijn geval de prijs is "so be it...." In de praktijk heb ik het in de afgelopen periode nog niet gezien, dus het zal wel mee vallen...
Daar komt nog bij dat de lijst pas gebruikt wordt in het spamfilter. Mail gaat dus niet verloren maar komt hooguit in de spambox terecht. Het is dus een kwestie van mail die "verkeerd" wordt aangeboden hoger laten scoren en niet blind rejecten...