Anti spam, greylists!?

[Bob2]

http://projects.puremagic.com/greyli...hitepaper.html

http://forum.plesk.com/showthread.ph...highlight=spam

Iemand ervaring met het gebruik hiervan?

[InfInIte]

Ik heb het al geruime tijd draaien en tot nu toe zijn er maar enkele spam emails doorheen gekomen. Werkt super hier.

[wonko]

Greylisting werkt enorm goed! Zeker doen als je dit kan toevoegen aan je mail setup!

[XBL]

Ik heb het even snel doorgelezen. Zoals ik het nu begrijp, werkt het als volgt:

Verstuurder stuurt mail. Bestaat de comibnatie: verstuurder/ontvanger/versturende server nog niet, krijgt de versturende server een temporary failure te zien. Deze server verstuurd het mailtje nogmaals en nu komt hij wel aan, om de 'triplet'-combinatie nu wél bestaat.

Klopt bovenstaande?

Jochem

[DiedX]

bijna. Het is meestal verzendend en ontvangend mailadres. Ik maak er al een jaartje gebruik van op mijn prive-servers en het werkt prima. Voor grotere servers minder met verbindingen uit Belgie, dit omdat grote Belgen (planet.be) meerdere mailservers hebben welke greylisting niet snappen.

Verder ben ik 200% voor

[Sander-]

Kijk en daar heb je gelijk een nadeel van deze hele methode, op het moment dat de server het niet snapt, of vet lang wacht met retryén is elke eerste mail die iemand je stuurt vele langer onderweg. Dit kan leiden tot frustraties bij gebruikers, maar ook tot informatie die te laat aankomt en daardoor zijn doel mist.

Stel je voor een klant wil ZSM iets geregeld hebben en belt je "Ik mail het je nu..." en jij moet dan vervolgens een kwartier gaan wachten. Of misshien nog langer voor je zo'n mail binnen hebt.

Verder moet je om dit in een productieomgeving te kunnen gebruiken gelijk dus al een exception kunnen maken voor bijvoorbeeld planet.be. En zo zullen er nog een aantal zijn.

Het idee is mooi, de werking ervan ook, maar de kans dat je bepaalde providers buiten sluit is gewoon te groot en die kan en wil je als provider niet lopen lijkt mij?

[CharlieRoot]

Origineel geplaatst door WE-Create!
Kijk en daar heb je gelijk een nadeel van deze hele methode, op het moment dat de server het niet snapt, of vet lang wacht met retryén is elke eerste mail die iemand je stuurt vele langer onderweg. Dit kan leiden tot frustraties bij gebruikers, maar ook tot informatie die te laat aankomt en daardoor zijn doel mist.

Stel je voor een klant wil ZSM iets geregeld hebben en belt je "Ik mail het je nu..." en jij moet dan vervolgens een kwartier gaan wachten. Of misshien nog langer voor je zo'n mail binnen hebt.

Verder moet je om dit in een productieomgeving te kunnen gebruiken gelijk dus al een exception kunnen maken voor bijvoorbeeld planet.be. En zo zullen er nog een aantal zijn.

Het idee is mooi, de werking ervan ook, maar de kans dat je bepaalde providers buiten sluit is gewoon te groot en die kan en wil je als provider niet lopen lijkt mij?

Die wachttijd zou ik me als provider echt niet druk om maken.. ik zou er niet wakker van liggen in elk geval.

[DiedX]

Andere inval: JA. Het is zeer vervelend om te moeten wachten. Met sommige sites wil je direct verder, maar nee, dan moet je wachten op een registratiemail.

99% van de spam valt direct weg he? Je mailbox is *SCHOON*. De laatste keer dat ik een mailtje heb gehad is 2 dagen geleden, en daarvoor een week. Soms zijn de middelen wat zwaar, maar het werkt wel

[Randy]

Is dit te vergelijken met de SPF records?

[DiedX]

Totaal niet. SPF werkt met DNS & Tekst files en gaat uit van mailservers waar mail vandaan zou moeten komen. SPF wordt bijna nergens ondersteund.

Greylisting werkt daarentegen gegarandeerd: mits de verzender zich aan de SMTP Standaard houdt. Zo zou je NIET vanuit een script moeten mailen welke 4xx codes niet begrijpt. Gewoon naar mail() droppen en sendmail af laten handelen (of Postfix, nog beter ). Dan werkt dit *PRIMA*

[Wido]

Ik kick hier misschien een wat oud topic, maar ok.

Wij draaien nu (nog) Qmail en daarvoor is ook een greylisting patch, zie: http://www.shupp.org/

Nu vroeg ik me alleen af, wij hebben ook klanten die via onze SMTP versturen, die krijgen u uiteraard ook deze "450" melding, of worden accounts die zich netjes aanmelden met username + pass buiten deze greylisting gelaten?

Ik zou het graag even uitgebreid gaan testen, maar ik heb nu even geen Qmail bak tot mijn beschikking, vandaar.

Heeft iemand er ervaring mee?

[davinci]

Is het niet afwachten tot spammers het greylisting doorkrijgen? (of is dat al het geval?)

Ik zit te denken om het e.e.a. te implementeren, maar baal ervan dat de 'eerste' mail altijd met vertraging aankomt...

[edit]
Bedenk me net nog iets:
Wij maken gebruik van een fallback mx, draait bij provider. We zien veel spam via deze relay komen. Dan zal greylisting bij ons voor deze mails ook niet helpen, want de relay blijft het toch wel aanbieden
[/edit]

[crazycoder]

Greylisting werkt bij de gratie van spammers die domweg hun zooi versturen zonder iets van een queue aan te houden. Het is voor een spammer werkelijke een eitje om hierop te anticiperen en de rommel gewoonweg nog een keer te sturen

Ik ben tegen het idee van greylisting omdat je problemen met een aantal providers zal krijgen. Niet iedere server snapt het even goed, sommige providers zetten retries naar een aparte smtp server.. Jouw greylist heeft dan het oude ip waardoor het nog wat langer duurt.

Ik betwijfel of mailinglists van greylisting houden. Je zal dus een fors aantal IP's moeten whitelisten.

SPF is een aardig hulpmiddel, wat mij echter opvalt is dat spammers momenteel zelden of nooit meer domeinen zoals aol.com, hotmaill.com of microsoft.com gebruiken. Zij pakken nu speciaal voor dit doel geregistreerde domeinen of domeinen die geen SPF geconfigureerd hebben.
Stellen dat SPF niet werkt zou ik mede om die reden niet durven..

[almar]

Wido en de rest,

Misschien een idee om wat QMAIL anti-spam maatregelen met elkaar te delen? Ik denk dat we allemaal de laatste tijd constateren dat de hoeveelheid spam de spuigaten uitloopt. Ik heb al een gekeken naar een eigen rbl, dat is eenvoudig te implementeren, maar helaas is dat geen effectieve oplossing gebleken.

Edit: Met de spuigaten uit, bedoel ik dat we nu op 99 % zitten in plaats van zo'n 95 %.

[Digiover]

Ik kick hier misschien een wat oud topic, maar ok.

Wij draaien nu (nog) Qmail en daarvoor is ook een greylisting patch, zie: http://www.shupp.org/

Nu vroeg ik me alleen af, wij hebben ook klanten die via onze SMTP versturen, die krijgen u uiteraard ook deze "450" melding, of worden accounts die zich netjes aanmelden met username + pass buiten deze greylisting gelaten?

Ik zou het graag even uitgebreid gaan testen, maar ik heb nu even geen Qmail bak tot mijn beschikking, vandaar.

Heeft iemand er ervaring mee?

Ik heb (met mijn zeer geringe kennis van c) de source aardig nauwkeurig bekeken (van de netqmail-greylisting-20060717 patch), maar ik kan nergens vinden dat je bestaande configuratie bestanden ingelezen worden. De greylisting-20060105 patch doet nog wat met je env. variabele relayclient, maar dat is volgens mij alleen een exit wanneer er niet voldoende geheugen beschikbaar is

+  if (!relayclient) {
+    if (!envelope_scanner()) return;
+  }

Evenals in de netqmail-greylisting-20060717 patch

if (!stralloc_cats(&addr,relayclient)) die_nomem();

links: http://shupp.org/patches/netqmail-gr...20060717.patch
http://shupp.org/patches/greylisting-20060105.patch

Het lijkt er dus op dat je bestaande klanten whitelisted moeten worden. Volgens mij gebeurt dit niet via de ENVIRONMENT variabele relayclient.

Wido en de rest,

Misschien een idee om wat QMAIL anti-spam maatregelen met elkaar te delen? Ik denk dat we allemaal de laatste tijd constateren dat de hoeveelheid spam de spuigaten uitloopt. Ik heb al een gekeken naar een eigen rbl, dat is eenvoudig te implementeren, maar helaas is dat geen effectieve oplossing gebleken.

Edit: Met de spuigaten uit, bedoel ik dat we nu op 99 % zitten in plaats van zo'n 95 %.

Quote uit een nieuwsbrief over spam die ik onlangs voor onze klanten heb verzonden

De afgelopen tijd komen er meer en meer virussen uit, waardoor meer en meer "nieuwe" PC's geinfecteerd raken, informatie over (nieuwe) virussen kunt u vinden op o.a. <http://www.virusalert.nl>. Het is ons opgevallen dat veel IP adressen waarvandaan nu spam verstuurd wordt, nog niet opgenomen zijn in DNSBLs. We kunnen er dus over spreken dat spammers beschikken over "verse IP adressen".

Zien jullie het zelfde, maw: Spam van verse (nog niet geblackliste) IP adressen?

Verder is de combinatie qmail - (anti-)spam erg K?T, naar mijn mening. Voor alles moet je een patch vinden, moet je de source patchen en weer compileren. Maar wij gebruiken ook geen zaken zoals Fehcom's SPAMCONTROL patch, wat vrij veel biedt qua anti-spam opties.
http://www.fehcom.de/qmail/spamcontrol.html

SPF is een aardig hulpmiddel, wat mij echter opvalt is dat spammers momenteel zelden of nooit meer domeinen zoals aol.com, hotmaill.com of microsoft.com gebruiken. Zij pakken nu speciaal voor dit doel geregistreerde domeinen of domeinen die geen SPF geconfigureerd hebben.
Stellen dat SPF niet werkt zou ik mede om die reden niet durven..

SPF is broken by design, denk bijvoorbeeld eens aan forwards... Waar ik wel toekomst in zie is Google's DomainKeys, wat ook door Yahoo! gebruikt wordt.