---

Jeg har i nogle måneder anvendt et centralt Exchange spamfilter som
anvender greylisting - mailsessionen afbrydes ved første modtagelse -
og det har gjort at det kun er promiller af spam der ryger igennem.

Tidligere var vi tilfredse når vi ved hjælp af sindrige pointsystemer og
databaser der kunne skrues på i det uendelige fangede 95%, så brugerne
er selvsagt lykkelige.

Men hvor længe varer successen ved?

Der må da komme et modtræk, hvor spammerne gensender mail ved fejl i
første transaktion?

Ole Thomsen

---

Ole Thomsen wrote in <news:dhigr9$fcn$1@news.net.uni-c.dk>:

> Men hvor længe varer successen ved?

Umiddelbart er greylisting kommet for at blive. Det er meget effektivt
til spambekæmpelse, men det er desværre også meget 'dyrt' for
mailsystemet, både for afsender og modtager, i kraft af større delays
og større krav til storage (spool).

Af samme grund egner metoden sig primært til små og mellemstore sites,
og giver forholdsmæssigt større problemer for de store sites, uanset om
de selv anvender metoden eller ej.

> Der må da komme et modtræk, hvor spammerne gensender mail ved fejl i
> første transaktion?

Både og. Nogle spammere gør det allerede, men hvis man kombinerer
greylisting med rapid-response RBL lister, kan man også sikre sig mod
den taktik -- og det kan typisk ikke 'betale' sig for spammere at prøve
den samme addresse flere gange i forhold til simpelthen at prøve en
frisk.

--
Niels Callesøe - dk pfy @work
pfy[at]nntp.dk - http://www.t29.dk/~nica/disclaimer.php
Catapultam habeo. Nisi pecuniam omnem mihi
dabis, ad caput tuum saxum immane mittam.

---

I dk.edb.sikkerhed, skrev Niels Callesøe:
> Ole Thomsen wrote in <news:dhigr9$fcn$1@news.net.uni-c.dk>:
>
> > Men hvor længe varer successen ved?
>
> Umiddelbart er greylisting kommet for at blive. Det er meget effektivt
> til spambekæmpelse, men det er desværre også meget 'dyrt' for
> mailsystemet, både for afsender og modtager, i kraft af større delays
> og større krav til storage (spool).

Hvad er prisen for modtager? .. der kan jeg ikke se at det er specielt
dyrt. Delays rammer kun "første mail", hvis eller greylistningen
benytter en fornuftig auto-whitelist.

Prisen er relativ dyr for afsendere, med mindre det er folk du har på
whitelisten. Men over 50% af mailen er spam, så den dyre pris betales
primært af spammere.

> Af samme grund egner metoden sig primært til små og mellemstore sites,
> og giver forholdsmæssigt større problemer for de store sites, uanset om
> de selv anvender metoden eller ej.

Kan du uddybe? Jeg har svært ved at se at et "lille" delay i modtagelsen
er et større problem end:
1) Cpu-mæssig dyr efterbehandling af spamassassin eller lignende.
2) Større risiko for falske positive.

> Både og. Nogle spammere gør det allerede, men hvis man kombinerer
> greylisting med rapid-response RBL lister, kan man også sikre sig mod
> den taktik -- og det kan typisk ikke 'betale' sig for spammere at prøve
> den samme addresse flere gange i forhold til simpelthen at prøve en
> frisk.

Ja.. greylistning er faktisk uhyre effektivt..

Jesper

--
../Jesper Krogh, jesper@krogh.cc, Jabber ID: jesper@jabbernet.dk

---

Jesper Krogh wrote in <news:dhiksm$4lk$1@shrek.linuxnews.dk>:

>> Umiddelbart er greylisting kommet for at blive. Det er meget
>> effektivt til spambekæmpelse, men det er desværre også meget
>> 'dyrt' for mailsystemet, både for afsender og modtager, i kraft
>> af større delays og større krav til storage (spool).
>
> Hvad er prisen for modtager? .. der kan jeg ikke se at det er
> specielt dyrt. Delays rammer kun "første mail", hvis eller
> greylistningen benytter en fornuftig auto-whitelist.

Det kommer an på setup og sitets størrelse. For små sites er den eneste
nævneværdige pris, udover administrationsomkostninger, det delay du
ikke mener er vigtigt (for mig er det for høj en pris at betale, så der
er vi ikke enige).

For større sites stiger prisen på databaseopslag eksponentielt efter en
vis størrelse, hvilket gør langtidslagring af triplets uholdbart og
dermed skaber endnu yderligere delay. Derudover kan større sites
normalt slet ikke tillade sig at have delay udover nogle få sekunder på
indkommende mail.

> Prisen er relativ dyr for afsendere, med mindre det er folk du har
> på whitelisten. Men over 50% af mailen er spam, så den dyre pris
> betales primært af spammere.

Nej, nej. Spammere betaler stadig (næsten) ingenting. Deres software
bruger ikke spool og er ligeglad med tabt post.

>> Af samme grund egner metoden sig primært til små og mellemstore
>> sites, og giver forholdsmæssigt større problemer for de store
>> sites, uanset om de selv anvender metoden eller ej.
>
> Kan du uddybe? Jeg har svært ved at se at et "lille" delay i
> modtagelsen er et større problem end:
> 1) Cpu-mæssig dyr efterbehandling af spamassassin eller lignende.
> 2) Større risiko for falske positive.

Hvad er det du gerne vil have mig til at uddybe? De problemer
greylisting skaber for de store sites, eller en cost/benefit-vurdering
i forhold til andre spambekæmpelsesformer?

Det sidste kræver nok lidt mere tid og flere ord end jeg er villig til
at ofre på Usenet -- men hvis nogen skulle have lyst til at betale for
min tid, skal jeg gerne udarbejde et whitepaper. På den anden side er
du velkommen til at fortsætte med at stille spørgsmål, måske ender vi,
med andres hjælp, med en brugbar analyse alligevel.

>> Både og. Nogle spammere gør det allerede, men hvis man
>> kombinerer greylisting med rapid-response RBL lister, kan man
>> også sikre sig mod den taktik -- og det kan typisk ikke 'betale'
>> sig for spammere at prøve den samme addresse flere gange i
>> forhold til simpelthen at prøve en frisk.
>
> Ja.. greylistning er faktisk uhyre effektivt..

Ingen tvivl om det. Det er bare ærgeligt at spam-problemet er så grelt,
at nogle ser sig nødsaget til at gribe til den slags, for selvom det er
et stærkt våben i kampen, så er det også at skyde gråspurve med
kanoner.

--
Niels Callesøe - dk pfy @work
pfy[at]nntp.dk - http://www.t29.dk/~nica/disclaimer.php
Catapultam habeo. Nisi pecuniam omnem mihi
dabis, ad caput tuum saxum immane mittam.

---

"Niels Callesøe" <pfy@nntp.dk> wrote:

>> Ja.. greylistning er faktisk uhyre effektivt..
>
>Ingen tvivl om det. Det er bare ærgeligt at spam-problemet er så grelt,
>at nogle ser sig nødsaget til at gribe til den slags, for selvom det er
>et stærkt våben i kampen, så er det også at skyde gråspurve med
>kanoner.

Alle filtermekanismer har en pris og en bagside. F.eks. er der en
række problemstillinger ved at filtrere mail EFTER man har accepteret
mailen i SMTP sessionen - eller afvise mail i SMTP sessionen baseret
på RBL opslag f.eks.

Andre systemer baserer sig på og registrering og opslag i DNS - men
det har også sine åbenlyse svagheder.

Greylisting er nok den teknik der rammer spammere hårdest med den
mindste risiko for at danne falske positive. Det øger måske
ressourcekravene - især hvis man er ISP størrelse, men på den anden
side er hardwaren jo også blevet meget kraftigere.

Det største problem er at det skaber en forsinkelse i udvekslingen.
Noget som mange sikkert godt kan acceptere - men jeg kan godt forstå
at en ISP kan have svært ved det, da de leverer en service.

Men de kunne vælge at lave et alternativ - f.eks. en filtrerer
mailservice som man købte for en mer-pris. Aner ikke om det er en
fornuftig forretningsmodel, men jeg gætter på at det var en ydelse
nogle gerne ville betale for.

--
Lars Kim Lund
http://www.net-faq.dk/

---

I dk.edb.sikkerhed, skrev Lars Kim Lund:
> Det største problem er at det skaber en forsinkelse i udvekslingen.
> Noget som mange sikkert godt kan acceptere - men jeg kan godt forstå
> at en ISP kan have svært ved det, da de leverer en service.

Man kan alligevel ikke garantere direkte levering i SMTP-protokollen, så
hvis man ønsker et instant-messagingsystem, så burde man sætte et op der
var beregnet til formålet. (XMPP eksempelvis).

Jesper
--
../Jesper Krogh, jesper@krogh.cc, Jabber ID: jesper@jabbernet.dk

---

Jesper Krogh wrote:

>> Det største problem er at det skaber en forsinkelse i
>> udvekslingen. Noget som mange sikkert godt kan acceptere - men
>> jeg kan godt forstå at en ISP kan have svært ved det, da de
>> leverer en service.
>
> Man kan alligevel ikke garantere direkte levering i
> SMTP-protokollen, så hvis man ønsker et instant-messagingsystem,
> så burde man sætte et op der var beregnet til formålet. (XMPP
> eksempelvis).

Der er milevid forskel på, hvad du og jeg ved at man teknisk kan, eller
ikke kan, garantere, og så hvad brugerne forventer. Brugerne forventer
næsten-nu levering af post, uanset hvordan verden i øvrigt er skruet
sammen.

Min personlige erfaring siger i øvrigt, at som tommelfinggeregel er
brugere villige til at acceptere forsinkelser på mail der kan tælles i
minutter, men ikke i timer.

--
Niels Callesøe - dk pfy
pfy[at]nntp.dk - http://www.t29.dk/~nica/disclaimer.php

Apathy is Death

---

Niels Callesøe wrote:
>
> Min personlige erfaring siger i øvrigt, at som tommelfinggeregel er
> brugere villige til at acceptere forsinkelser på mail der kan tælles i
> minutter, men ikke i timer.

Det er osse min erfaring, men jeg har nu heller ikke oplevet eller fået
melding om forsinkelser på mere end nogle få minutter efter aktivering
af greylisting.

Jeg har derimod måttet whiteliste et par østeuropæiske og asiatiske
afsendere fordi deres server simpelthen ikke sendte mailen igen.

Ole Thomsen

---

Lars Kim Lund wrote:

>>> Ja.. greylistning er faktisk uhyre effektivt..
>>
>>Ingen tvivl om det. Det er bare ærgeligt at spam-problemet er så
>>grelt, at nogle ser sig nødsaget til at gribe til den slags, for
>>selvom det er et stærkt våben i kampen, så er det også at skyde
>>gråspurve med kanoner.
>
> Alle filtermekanismer har en pris og en bagside.

Ja. Det svære er at vurdere deres reelle omkostninger, og at vurdere
dem i forhold til hinanden.

> Greylisting er nok den teknik der rammer spammere hårdest med den
> mindste risiko for at danne falske positive.

Det er i hvert fald en af de stærkeste metoder på disse to parametre,
ingen tvivl om det. Desværre er det samtidig en af de mest kostbare
metoder på delay og ressourcer[0], som nævnt.

> Det øger måske ressourcekravene - især hvis man er ISP størrelse, men
> på den anden side er hardwaren jo også blevet meget kraftigere.

Den kraftigere hardware betyder helt sikkert noget, men på den anden
vægtskål er stigningen i trafik, der bestemt heller ikke er ubetydelig.
Hvilken der er størst af de to, tør jeg ikke sige.

Men ganske uanset, betyder større ressourceforbrug, alt andet lige,
større pris per leveret meddelelse.


[0]: Egentlig redundant. Tid er i denne sammenhæng også en ressource.

--
Niels Callesøe - dk pfy
pfy[at]nntp.dk - http://www.t29.dk/~nica/disclaimer.php

Apathy is Death

---

"Niels Callesøe" <pfy@nntp.dk> wrote:

>> Det øger måske ressourcekravene - især hvis man er ISP størrelse, men
>> på den anden side er hardwaren jo også blevet meget kraftigere.
>
>Den kraftigere hardware betyder helt sikkert noget, men på den anden
>vægtskål er stigningen i trafik, der bestemt heller ikke er ubetydelig.
>Hvilken der er størst af de to, tør jeg ikke sige.

Det er en svær formel. For der indgår også at man afviser en del spam
allerede i SMTP sessionen inden DATA sendes, hvilket jo også sparer
båndbredde.

>Men ganske uanset, betyder større ressourceforbrug, alt andet lige,
>større pris per leveret meddelelse.

Alt vil jo repræsentere en udgift i forhold til den mest simple
løsning. At det koster er egentlig ikke så relevant. Spørgsmålet er om
varen / ydelsen er prisen værd. Lige som når man køber ind i
supermarkedet ..

--
Lars Kim Lund
http://www.net-faq.dk/

---

Lars Kim Lund <lkl@fabel.dk> wrote:

>>> Det øger måske ressourcekravene - især hvis man er ISP størrelse, men
>>> på den anden side er hardwaren jo også blevet meget kraftigere.
>>
>>Den kraftigere hardware betyder helt sikkert noget, men på den anden
>>vægtskål er stigningen i trafik, der bestemt heller ikke er ubetydelig.
>>Hvilken der er størst af de to, tør jeg ikke sige.
>
>Det er en svær formel. For der indgår også at man afviser en del spam
>allerede i SMTP sessionen inden DATA sendes, hvilket jo også sparer
>båndbredde.

Og man skal jo også huske at greylisting som udgangspunkt jo
filtrerere i DATA.

--
Lars Kim Lund
http://www.net-faq.dk/

---

I dk.edb.sikkerhed, skrev Niels Callesøe:
> For større sites stiger prisen på databaseopslag eksponentielt efter en
> vis størrelse, hvilket gør langtidslagring af triplets uholdbart og
> dermed skaber endnu yderligere delay. Derudover kan større sites
> normalt slet ikke tillade sig at have delay udover nogle få sekunder på
> indkommende mail.

Den datalog der ikke kan klare et ipadresse opslag i en liste, der ikke
vokser eksponentielt burde tage sin uddannelse om. En almindelig
database med et index løser problemet.

Hvis de fleste bliver stillet overfor det valg de bør tage..
Større risiko for falske positive eller et delay på et par minutter, så
tror jeg gdt jeg ved hvad de fleste vælger.

> > Prisen er relativ dyr for afsendere, med mindre det er folk du har
> > på whitelisten. Men over 50% af mailen er spam, så den dyre pris
> > betales primært af spammere.
>
> Nej, nej. Spammere betaler stadig (næsten) ingenting. Deres software
> bruger ikke spool og er ligeglad med tabt post.

Det er da også den dyreste pris. De har lavet et forsøg og brugt tid på
det og mister de 0.00000...01% sandsynlighed for at mailen når frem og
bliver læst. Hvis alle brugte greylistning, så ville spammeren miste
"alt".

> > 1) Cpu-mæssig dyr efterbehandling af spamassassin eller lignende.
> > 2) Større risiko for falske positive.
>
> Hvad er det du gerne vil have mig til at uddybe? De problemer
> greylisting skaber for de store sites, eller en cost/benefit-vurdering
> i forhold til andre spambekæmpelsesformer?

At greylistning giver problemer for større sites er en skrøne, indtil at
du har uddybet hvorfor det rammer større sites mere end mindre.
Problemet med delays er lige stort for alle der benytter greylistning.

> > Ja.. greylistning er faktisk uhyre effektivt..
>
> Ingen tvivl om det. Det er bare ærgeligt at spam-problemet er så grelt,
> at nogle ser sig nødsaget til at gribe til den slags, for selvom det er
> et stærkt våben i kampen, så er det også at skyde gråspurve med
> kanoner.

Vi har da også løsninger på markedet der er fuldstændigt ude i hampen:
1) Email bekræftelse af afsenderadresse.. med eksplicit email.
2) At folk skal maskere/skifte emailadresser pga. spam.

Greylistning gør at jeg uden problemer kan benytte min emailadressse
frit, ganske som systemet i sin natur var tiltænkt.

Jesper
--
../Jesper Krogh, jesper@krogh.cc, Jabber ID: jesper@jabbernet.dk

---

Jesper Krogh wrote:

>> Hvad er det du gerne vil have mig til at uddybe? De problemer
>> greylisting skaber for de store sites, eller en
>> cost/benefit-vurdering i forhold til andre spambekæmpelsesformer?
>
> At greylistning giver problemer for større sites er en skrøne,
> indtil at du har uddybet hvorfor det rammer større sites mere end
> mindre. Problemet med delays er lige stort for alle der benytter
> greylistning.

Jeg kan ikke helt forstå hvorfor du kalder min påstand for opspind, når
jeg nu har tilbudt at underbygge den hvis du er interesseret.

Helt kort forklaret, hænger det primært sammen med at udgifterne til
storage og traffik stiger ikke-linært[0] efter et vist punkt. Og, kort
fortalt, skal et stort site slås med nogle ret store tekniske problemer
hvis deres post ikke kan leveres hurtigt.

Der opstår flaskehalse omkring spool (cache, IO, access-tider,
størrelse, krav til redundans), antal mulige outbound SMTP-sessions per
sekund, throttling, etc. der kun kan løses med komplicerede og/eller
dyre clusterede løsninger. Og samtidig stiger omkostninger til support
mv. stjelt, hvis de gennemsnitlige leveringstider overstiger brugernes
forventninger.


[0]: Det er, for eksempel, meget billigere at have 100 100GB
redundante storage-arrays end at have et redundant 10TB array.

--
Niels Callesøe - dk pfy
pfy[at]nntp.dk - http://www.t29.dk/~nica/disclaimer.php

Apathy is Death

---

Niels Callesøe wrote:
>>At greylistning giver problemer for større sites er en skrøne,
>>indtil at du har uddybet hvorfor det rammer større sites mere end
>>mindre. Problemet med delays er lige stort for alle der benytter
>>greylistning.
>
>
> Jeg kan ikke helt forstå hvorfor du kalder min påstand for opspind, når
> jeg nu har tilbudt at underbygge den hvis du er interesseret.

Snakker i ikke blot forbi hinanden?

Jeg gætter på Jesper snakker om modtagelse og du snakker om levering i
det tilfælde at resten af verden kører med greylisting.

> Helt kort forklaret, hænger det primært sammen med at udgifterne til
> storage og traffik stiger ikke-linært[0] efter et vist punkt. Og, kort
> fortalt, skal et stort site slås med nogle ret store tekniske problemer
> hvis deres post ikke kan leveres hurtigt.

Er ovestående et større problem end spam?

---

I dk.edb.sikkerhed, skrev Christian E. Lysel:
> Niels Callesøe wrote:
> >>At greylistning giver problemer for større sites er en skrøne,
> >>indtil at du har uddybet hvorfor det rammer større sites mere end
> >>mindre. Problemet med delays er lige stort for alle der benytter
> >>greylistning.
> >
> >
> > Jeg kan ikke helt forstå hvorfor du kalder min påstand for opspind, når
> > jeg nu har tilbudt at underbygge den hvis du er interesseret.
>
> Snakker i ikke blot forbi hinanden?
>
> Jeg gætter på Jesper snakker om modtagelse og du snakker om levering i
> det tilfælde at resten af verden kører med greylisting.

Jeg snakker om modtagelse. Jeg har og vil aldrig få nogen mulighed for
at påvirke hvordan modtagerens mailservere er konfigureret, derfor er
det uinteressant at diskutere det for mig.


> > Helt kort forklaret, hænger det primært sammen med at udgifterne til
> > storage og traffik stiger ikke-linært[0] efter et vist punkt. Og, kort
> > fortalt, skal et stort site slås med nogle ret store tekniske problemer
> > hvis deres post ikke kan leveres hurtigt.
>
> Er ovestående et større problem end spam?

Men omkostningerne ved et processere den større mængde spam genne
cpu-intensive mekanismer som spamassassing stiger dermed også
"ikke-lineært".

Jesper
--
../Jesper Krogh, jesper@krogh.cc, Jabber ID: jesper@jabbernet.dk

---

Jesper Krogh wrote:
>> Jeg gætter på Jesper snakker om modtagelse og du snakker om levering i
>> det tilfælde at resten af verden kører med greylisting.
>
>
> Jeg snakker om modtagelse. Jeg har og vil aldrig få nogen mulighed for
> at påvirke hvordan modtagerens mailservere er konfigureret, derfor er
> det uinteressant at diskutere det for mig.

Det passer ikke helt. Niels får da udtrykt sit synspunkt omkring
afsendelsen...dette kan jo påvirke mig, dig og andre i hvordan vi
konfigurer vores mail servere ved modtagelsen.

>> Er ovestående et større problem end spam?
> Men omkostningerne ved et processere den større mængde spam genne
> cpu-intensive mekanismer som spamassassing stiger dermed også
> "ikke-lineært".

Endvidere skal spam jo håndteres, i værste tilfælde af brugerne, eller
endnu værre bliver brugerens post genkendt som spam, således brugeren
ikke ser det.

Som jeg husker SMTP protokollen, gør man alt for at mails ikke skal
kunne gå tabt.

---

Christian E. Lysel wrote in
<news:433e4372$0$1782$edfadb0f@dread11.news.tele.dk>:

>> Jeg kan ikke helt forstå hvorfor du kalder min påstand for
>> opspind, når
>> jeg nu har tilbudt at underbygge den hvis du er interesseret.
>
> Snakker i ikke blot forbi hinanden?
>
> Jeg gætter på Jesper snakker om modtagelse og du snakker om
> levering i det tilfælde at resten af verden kører med greylisting.

Jeg tror du har ret -- bortset fra at jeg hverken snakker om levering
eller modtagelse separat, men om begge dele. Men det er selvfølgelig
klart at det eneste brugeren kan mærke direkte, er forsinkelsen på
modtagelse.

Det understreger efter min mening rimeligt klart at det er en mere
kompliceret problemstilling end man måske kan fristes til at tro.

>> Helt kort forklaret, hænger det primært sammen med at udgifterne
>> til
>> storage og traffik stiger ikke-linært[0] efter et vist punkt. Og,
>> kort
>> fortalt, skal et stort site slås med nogle ret store tekniske
>> problemer
>> hvis deres post ikke kan leveres hurtigt.
>
> Er ovestående et større problem end spam?

Det kan jeg ikke forestille mig. I hvert fald er spam (og til en vis
grad virus) roden til stort set alle de problemer man løber ind i som
e-mail-udbyder, så der kan ikke være meget diskussion om at spam er
"fjenden".

Men det betyder jo ikke, at det ikke er værd at nøje overveje
konsekvenserne af de mange, mange forskellige anti-spam ideer. Som med
så meget andet, er der jo både gode, dårlige og /virkeligt tåbelige/
ideer. Greylisting hører efter min mening til de bedre af slagsen, men
har, desværre, nogle ubehagelige konsekvenser.


Noget helt andet: Er du klar over at din klient ombryder citeret tekst
helt forfærdeligt, for klienter der ikke forstår format=flowed? (Jeg
har manuelt rettet i ovenstående så det er nogenlunde læseligt...)

--
Niels Callesøe - dk pfy @work
pfy[at]nntp.dk - http://www.t29.dk/~nica/disclaimer.php
Catapultam habeo. Nisi pecuniam omnem mihi
dabis, ad caput tuum saxum immane mittam.

---

"Niels Callesøe"
> [0]: Det er, for eksempel, meget billigere at have 100 100GB
> redundante storage-arrays end at have et redundant 10TB array.

Niels;

Problemet må vel andet lige, udjævne sig lidt...
Som skrevet i et tidligere indlæg af Jesper Krogh, så er det jo kun den
første mail fra et givent domæne, som skal gensendes.. Korrekt?

Ergo, vil alle andre mails imellem disse to servere på dette domæne, ryge
igennem i første forsøg..

Og der må da være en grænse for hvor mange forskellige domæner en given
bruger skriver til...?
Jeg mener, nok har jeg skrevet x antal tusinde mails, men det er jo til lige
så mange forskellige domæner..

Er jeg helt ved siden af?

--
/Stoltze
Har du husket at klippe i dit indlæg? Og læst det igennem en ekstra gang?
Husk at læse http://www.usenet.dk/netikette/citatteknik.html
Kig forbi http://blomstertid.dk

---

> Og der må da være en grænse for hvor mange forskellige domæner en given
> bruger skriver til...?
> Jeg mener, nok har jeg skrevet x antal tusinde mails, men det er jo til
> lige så mange forskellige domæner..

UPS!!
Jeg mente, at jeg jo IKKE har skrevet til lige så mange forskellige
domæner... Men at mange af mine mails, går til de samme domæner...

--
/Stoltze
Har du husket at klippe i dit indlæg? Og læst det igennem en ekstra gang?
Husk at læse http://www.usenet.dk/netikette/citatteknik.html
Kig forbi http://blomstertid.dk

---

I dk.edb.sikkerhed, skrev Niels Stoltze:
> "Niels Callesøe"
> > [0]: Det er, for eksempel, meget billigere at have 100 100GB
> > redundante storage-arrays end at have et redundant 10TB array.
>
> Niels;
>
> Problemet må vel andet lige, udjævne sig lidt...
> Som skrevet i et tidligere indlæg af Jesper Krogh, så er det jo kun den
> første mail fra et givent domæne, som skal gensendes.. Korrekt?

De greylistning systemer jeg har arbejdet med arbejder på denne tripel
(afsender-adresse,modtager-adresse,afsender-ip)

Og whitelister på grund af dennne. Det er envelope-adresserne og
ipadressen i den anden ende af smtp-sessionen vi snakker om.

Kommer der så tilstrækkeligt mange mails med fra sammen afsender-domæne,
med samme afsender-ip, så bliver hele domænet whitelistet fra den
ip-adresse.

Jesper
--
../Jesper Krogh, jesper@krogh.cc, Jabber ID: jesper@jabbernet.dk

---

Jesper Krogh <jesper@krogh.cc> wrote:

>> Problemet må vel andet lige, udjævne sig lidt...
>> Som skrevet i et tidligere indlæg af Jesper Krogh, så er det jo kun den
>> første mail fra et givent domæne, som skal gensendes.. Korrekt?
>
>De greylistning systemer jeg har arbejdet med arbejder på denne tripel
>(afsender-adresse,modtager-adresse,afsender-ip)
>
>Og whitelister på grund af dennne. Det er envelope-adresserne og
>ipadressen i den anden ende af smtp-sessionen vi snakker om.
>
>Kommer der så tilstrækkeligt mange mails med fra sammen afsender-domæne,
>med samme afsender-ip, så bliver hele domænet whitelistet fra den
>ip-adresse.

Der er andre tricks til at gøre det mere fleksibelt. F.eks. at
auto-whiteliste baseret på udgående trafik i en eller anden
tidsperiode, således at (hurtige) svar på udgående mail også undgår
filtret.

--
Lars Kim Lund
http://www.net-faq.dk/

---

Jesper Krogh wrote:
>
> De greylistning systemer jeg har arbejdet med arbejder på denne tripel
> (afsender-adresse,modtager-adresse,afsender-ip)

På vores system har man så valgt at begrænse det så for afsenderen
er det kun domænet og de tre mest betydende bytes af IP adressen,
der registreres. (Dog med den undtagelse, at hvis afsender og
modtager domæne er det samme kigges på hele adressen). Dermed undgår
man en del forsinkelser hvis man får flere mails fra samme domæne,
samt hvis afsenderen har dynamisk IP. Og jeg tror ikke man får ret
meget mere spam ind på den bekostning. Hvis en afsender var i stand
til at komme igennem greylistningen første gang, så er han nok i
stand til at gøre det igen. Og hvis både domæne og netværk er det
samme som tidligere, så er det overvejende sandsynligt, at det er
samme afsender.

--
Kasper Dupont
Note to self: Don't try to allocate
256000 pages with GFP_KERNEL on x86.

---

Niels Stoltze wrote:

> Problemet må vel andet lige, udjævne sig lidt...
> Som skrevet i et tidligere indlæg af Jesper Krogh, så er det jo
> kun den første mail fra et givent domæne, som skal gensendes..
> Korrekt?
>
> Ergo, vil alle andre mails imellem disse to servere på dette
> domæne, ryge igennem i første forsøg..

Kasper, Jesper og Jona^WLars har allerede givet dig nogle praktiske
eksempler på hvordan greylisting kan konfigureres, så det vil jeg ikke
bruge mere tid på.

Det, der er værd at bemærke er, at uanset hvordan man konfigurerer det,
så ender man i princippet med en database der indeholder alle afsendere
og modtagere i verden, hvis man venter længe nok. Det kan naturligvis
ikke lade sig gøre, og man er derfor nød til at bøje principperne lidt
for at få tingene til at glide, såsom kun at opbevare triplets i en
periode, eller et bestemt antal, eller udvidde kriterierne efterhånden
-- alle tre muligheder eksemplificerede i de ovennævnte forfatteres
indlæg.

Kernen er, at jo mere tid man kan ofre på administration af systemet,
des bedre virker det. Og omvendt. Man kan derfor godt få greylisting
til at virke rigtig godt for sine egne brugere, men man kan desværre
ikke forvente at greylisting virker rigtig godt i verden generelt.

Og så har vi igen kun kigget på modtagersiden af problemet. Men lad mig
lige understrege, for ikke at virke alt for mavesur, at jeg ikke synes
man er komplet idiot fordi man er tilhænger af greylisting. Jeg synes
blot heller ikke det er nogen mirakkelkur og at det er vigtigt at tage
diskussionen om fordele og ulemper, så administratorer ikke fristes til
at kaste sig over det uden yderligere omtanke.

--
Niels Callesøe - dk pfy
pfy[at]nntp.dk - http://www.t29.dk/~nica/disclaimer.php

Apathy is Death

---

"Niels Callesøe" wrote:
>
> Det, der er værd at bemærke er, at uanset hvordan man konfigurerer det,
> så ender man i princippet med en database der indeholder alle afsendere
> og modtagere i verden, hvis man venter længe nok.

Nej, man får kun de modtagere man har på sit eget domæne,
og de afsendere, de har modtaget fra. Det er småting i
sammenligning med den datamængde det løber op i, hvis
brugerne gemmer alle deres emails. Og det med at gemme
alle emails er vist enda noget udbyderne kan få pligt
til, hvis nogle personer får deres vilje.

>
> Og så har vi igen kun kigget på modtagersiden af problemet. Men lad mig
> lige understrege, for ikke at virke alt for mavesur, at jeg ikke synes
> man er komplet idiot fordi man er tilhænger af greylisting. Jeg synes
> blot heller ikke det er nogen mirakkelkur og at det er vigtigt at tage
> diskussionen om fordele og ulemper, så administratorer ikke fristes til
> at kaste sig over det uden yderligere omtanke.

Jeg synes du gør en stor indsats for at finde ulemper,
der ikke eksisterer i praksis.

--
Kasper Dupont
Note to self: Don't try to allocate
256000 pages with GFP_KERNEL on x86.

---

"Ole Thomsen" <ot@networks.dk> wrote:

>Jeg har i nogle måneder anvendt et centralt Exchange spamfilter som
>anvender greylisting

Hvilket?

Jeg synes ikke greylisting er så udbredt i mainstream / kommercielle
løsninger.

Jeg har lidt kig på xmail, der er noget open souce der også kan køre
på Win32. Og som både supportere DNSRBL, Greylisting osv.

Nogen der har erfaringer med hvordan xmail performer i lidt større
setups. Lad os sige ~ 10k mails / dag. - og også gerne erfaringer fra
andre OS'er?

XFUT: dk.edb.sysadmin

--
Lars Kim Lund
http://www.net-faq.dk/