- A hozzászóláshoz be kell jelentkezni
- 2973 megtekintés
Hozzászólások
Nagy Attila wrote:
> Az előadás rövid áttekintést nyújt az amavis szövevényes múltjáról és
> benchmarkok segítségével ad némi információt arra nézve, hogy mire képes a
> program és mit érdemes átnézni, ha komolyabb helyen szeretnénk használni.
Ez a 4 levél per másodperc sajnos eléggé beszűkíti a felhasználási
lehetőségeket... :(
- A hozzászóláshoz be kell jelentkezni
SOHO/SME. De ezt mindenki tudta :)
- A hozzászóláshoz be kell jelentkezni
Ago wrote:
> SOHO/SME. De ezt mindenki tudta :)
Két kérdés:
- mi az, ami open source, hasonló hatásfokkal/képességekkel rendelkezik
és gyorsabb?
- milyen skálázhatóbb, nem open source megoldás van, amellyel pozitív
tapasztalataid vannak?
Magyarul: mik a lehetőségek? :)
- A hozzászóláshoz be kell jelentkezni
Ugyan csak spam ellen jó, de a dspamet [dspam.nuclearelephant.com] próbálta már valaki?
- A hozzászóláshoz be kell jelentkezni
mi az, ami open source, hasonló hatásfokkal/képességekkel rendelkezik
és gyorsabb?
exim4+exiscan. 4.5x-től kezdve a main része az exiscan.
Tisztán C.
Egyébként jobb mint egy postfix + amavis-ng páros, illetve azt mondom nem összemérhető, mert másra való.
Amugy szvsz majd minden opensource smtp szerver jól skálázható. Magas rendelkezésreállás is biztosítható shared disk segítségével.
balsa
- A hozzászóláshoz be kell jelentkezni
In article <42.47717@c.hup.hu>, Nagy Attila wrote:
> - mi az, ami open source, hasonló hatásfokkal/képességekkel rendelkezik
> és gyorsabb?
exim :)
- A hozzászóláshoz be kell jelentkezni
Adi wrote:
> Ugyan csak spam ellen jó, de a dspamet [0] [dspam.nuclearelephant.com]
> próbálta már valaki?
Nem sokat próbálkoztam vele, de sqlite backenddel meglehetősen lassú
(annyi, vagy több ideig scannel egy levelet, mint egy spamassassin
hálózati tesztekkel teletűzve). Azt mondják SQL-lel jobb, ha próbálod,
feltétlenül úgy tedd. :)
- A hozzászóláshoz be kell jelentkezni
balsa wrote:
> _ mi az, ami open source, hasonló hatásfokkal/képességekkel rendelkezik
> és gyorsabb?_
> exim4+exiscan. 4.5x-től kezdve a main része az exiscan.
> Tisztán C.
Tudom, hogy te nagy exim rajongó vagy, de azért azt elmondhatnád, hogy
ettől hogy lesz gyorsabb a spamszűrés. :)
Nem azzal van bajom, hogy mondjuk egy postfix-amavisd-new esetében a
postfix, vagy az amavisd lassú lenne, hanem az, hogy a spamassassin
molyol sokat a levéllel.
Tudok olyat csinálni, hogy kikapcsolom az erőforrás intenzív teszteket
(hálózati pld), de ezekkel jelentősen romlik a hatásfok, viszont
természetesen felgyorsul (200-500 ms egy levélre).
A kérdés arra vonatkozott, hogy hasonló hatásfokú, de nagyságrendileg
gyorsabb spamszűrő megoldást ki tud.
Az exiscan lehet, hogy kevesebbet pattogtatja a levelet, de itt nem az a
szűk keresztmetszet, meg aztán lehet, hogy amennyi system időt elvisz az
exim a forkolással, abban a postfix+amavis leadja a levelet. De az is
lehet, hogy az elmúlt pár évben megváltozott az exim és már nem
monolitikus, "minden kapcsolatra egy processzt indítok" elven működik. :)
> Egyébként jobb mint egy postfix + amavis-ng páros, illetve azt mondom nem
> összemérhető, mert másra való.
Nyilván van olyan, amit az egyik tud, meg olyan is, amit a másik és
persze a felépítés is különbözik. Az exim+exiscan majdnem ugyanaz, mint
a sendmail+milterek, annyi különbséggel, hogy ez utóbbihoz valószínűleg
sokkal több milter van. :)
> Amugy szvsz majd minden opensource smtp szerver jól skálázható. Magas
> rendelkezésreállás is biztosítható shared disk segítségével.
A rendelkezésreálláshoz nem kell osztott diszk, csak sok gép. :)
- A hozzászóláshoz be kell jelentkezni
balsa wrote:
> exim4+exiscan. 4.5x-től kezdve a main része az exiscan.
> Tisztán C.
Ha már itt tartunk, a Brigthmailről van valakinek tapasztalata? Külföldi
listákon szokták dícsérni, de nem tudom, hogy mióta megvette a symantec,
milyen az open source támogatásuk (a 6.0-ásra windows, slowaris és
linux, de ki tudja)...
Számomra az sem teljesen egyértelmű, hogy mi alapján licenszelhető. Per
szerver, per mailbox/e-mail/stb...
- A hozzászóláshoz be kell jelentkezni
On 2005-07-13, Nagy Attila <bra@fsn.hu> wrote:
>
> Ago wrote:
>> SOHO/SME. De ezt mindenki tudta :)
> Két kérdés:
> - mi az, ami open source, hasonló hatásfokkal/képességekkel rendelkezik
> és gyorsabb?
> - milyen skálázhatóbb, nem open source megoldás van, amellyel pozitív
> tapasztalataid vannak?
>
> Magyarul: mik a lehetőségek? :)
Mailscanner + clamav + spamassasin
(Kozvetlen tapasztalatom nincs...)
- A hozzászóláshoz be kell jelentkezni
Tudom, hogy te nagy exim rajongó vagy, de azért azt elmondhatnád, hogy
ettől hogy lesz gyorsabb a spamszűrés. :)
Ja hogy a spamszűrés. Sajnos szerintem a spamassassin nem használható, mert:
1. ma már egyre kifinomultabbak spam-ek, és egyre rosszabb a felismerés hatásfoka.
2. szvsz a spamassassin nem egy jó minőségű program, és ez nagyban csökkenti a használhatóságát.
Pl. van úgy, hogy felzabálja az összes RAM-ot, a legutolsó finomhangolás után is.
A kérdés arra vonatkozott, hogy hasonló hatásfokú, de nagyságrendileg
gyorsabb spamszűrő megoldást ki tud.
Én ma rbl-t, sender verification-t/callback-et, és graylistinget használnék együtt. Főleg az utóbbi kettő ma egy jól használható eszköz. Persze lehet, hogy egy év múlva már nem lesz az, mert ezek a spammerek olyan találékonyak.
Az említett dspamet nem ismerem.
[...]exim és már nem monolitikus[...]
Ez nem bug hanem feature, mert rugalmas smtp szervert nem lehet másként csinálni.
Lehet csinálni rugalmatlant és akkor egy előre felvázolt, bebetonozott logika alapján fel lehet szabdalni a funkciókat
processekre.
A rendelkezésreálláshoz nem kell osztott diszk, csak sok gép. :)
Én is erre gondoltam a skálázhatóságnál. Azért írtam shared disket, hogy ne érjen a vád, hogy nem gondolok a queue-ban levő, esetleg elvesző levelekre. És az opensource smtp szerver zöme alkalmas erre, mert amúgy is független processekben gondolkodnak disken történő fájl alapú adatmegosztással (értsd nem memóriában). Persze hozzáteszem a shared disk single point, hol kisebb, hol nagyobb. Itt kisebb.
- A hozzászóláshoz be kell jelentkezni
In article <42.47728@c.hup.hu>, balsa wrote:
> 2. szvsz a spamassassin nem egy jó min?ség? program, és ez nagyban
> csökkenti a használhatóságát.
> Pl. van úgy, hogy felzabálja az összes RAM-ot, a legutolsó finomhangolás
> után is.
1.1Gb-nal meg szokott allni :)
- A hozzászóláshoz be kell jelentkezni
balsa wrote:
> Ja hogy a spamszűrés. Sajnos szerintem a spamassassin nem használható,
> mert:
> 1. ma már egyre kifinomultabbak spam-ek, és egyre rosszabb a felismerés
> hatásfoka.
Azért azt nem állítanám, hogy nem használható. Elég sok spamet meg lehet
vele fogni, ha jól be van állítva.
> 2. szvsz a spamassassin nem egy jó minőségű program, és ez nagyban
> csökkenti a használhatóságát.
> Pl. van úgy, hogy felzabálja az összes RAM-ot, a legutolsó finomhangolás
> után is.
Ezt én is csak megerősíteni tudom, igaz ez a probléma engem nem érint,
mert azon a kisforgalmú gépen (1-3 levél perc másodperc), amin használom
amavisd-new-val fut, ami adott üzenetszám után új childet indít.
> Én ma rbl-t, sender verification-t/callback-et, és graylistinget használnék
> együtt. Főleg az utóbbi kettő ma egy jól használható eszköz. Persze lehet,
> hogy egy év múlva már nem lesz az, mert ezek a spammerek olyan
> találékonyak.
A callback jó dolog, csak nagyüzemben az sem használható, mert magadat
zárod ki vele. A yahoo (vagy az AOL, hirtelen nem is tudom, de lehet,
hogy mindkettő) például feketelistára tesz egy időre, ha túl sok nem
létező címre próbálkozol nála... A graylistingnek is lehetnek problémái,
találkoztam már olyan IP-vel, amely mögött nyilván egy 10-15-ös számú
géppark lehetett és az idióták nem osztott graylistet csináltak (vagy
csak erősen limitálták a maximális bejegyzések számát) és így
előfordult, hogy 4-5 óra volt, míg átment egy levél.
Ugyanez fordítva, mikor neked van 10-15 géped és nem tudod őket egy
IP-re NAT-olni, de ezt könnyebb megoldani. :)
A feladó ellenőrzés, illetve azonosítás (SPF/DomainKeysre gondolok)
pedig megint nem feltétlenül szimpatikus, mert önmagában nem oldja meg a
spam problémát, az SPF pedig még inkább másokat hoz be a képbe.
> Az említett dspamet nem ismerem.
Én is csak ránéztem 10 perc alatt, volt, amit megfogott, és rohadt lassú
volt sqlite-tal. :)
Ahhoz, hogy érvényesülni tudjon, kell valami SQL szerver mögé.
> Ez nem bug hanem feature, mert rugalmas smtp szervert nem lehet másként
> csinálni.
Na majd a sendmail X. :)
> Én is erre gondoltam a skálázhatóságnál. Azért írtam shared disket, hogy ne
> érjen a vád, hogy nem gondolok a queue-ban levő, esetleg elvesző levelekre.
Az már adatintegritás és nem rendelkezésreállás, nem? =)
> És az opensource smtp szerver zöme alkalmas erre, mert amúgy is független
> processekben gondolkodnak disken történő fájl alapú adatmegosztással (értsd
> nem memóriában). Persze hozzáteszem a shared disk single point, hol kisebb,
> hol nagyobb. Itt kisebb.
Hát a postfixet pld. nem igazán célszerű osztott diszkre tenni, már ami
a queue-ját illeti, de ez is by design.
- A hozzászóláshoz be kell jelentkezni
Gabucino wrote:
>>Pl. van úgy, hogy felzabálja az összes RAM-ot, a legutolsó finomhangolás
>>után is.
> 1.1Gb-nal meg szokott allni :)
Processzlimit? :)
spamd-ben nem lehet korlátozni egy-egy instance felhasználhatóságát?
- A hozzászóláshoz be kell jelentkezni
In article <42.47732@c.hup.hu>, Nagy Attila wrote:
>> 1.1Gb-nal meg szokott allni :)
> Processzlimit? :)
Az mukodik.
> spamd-ben nem lehet korlátozni egy-egy instance felhasználhatóságát?
Nem.
- A hozzászóláshoz be kell jelentkezni
A Symantec Brightmail-t hasznaljuk Exchange szerveren. Szinte 0 konfiggal megfogja a spam-ek 60-70%-at. Allitja a rendszergazda aki mukodteti. Szerinte jo.
- A hozzászóláshoz be kell jelentkezni
Gabucino wrote:
>>spamd-ben nem lehet korlátozni egy-egy instance felhasználhatóságát?
> Nem.
Az elég szar ügy. :(
- A hozzászóláshoz be kell jelentkezni
Micskó Gábor wrote:
> A Symantec Brightmail-t hasznaljuk Exchange szerveren. Szinte 0 konfiggal
> megfogja a spam-ek 60-70%-at. Allitja a rendszergazda aki mukodteti.
> Szerinte jo.
Ha küldök nektek 260 ezer spamet, küldtök logokat? :)
Meg tudnád kérdezni, hogy per micsoda kerül pénzbe? Bár nyilván ez
függhet (függ?) a cég méretétől, a felhasználás típusától is.
- A hozzászóláshoz be kell jelentkezni
> A kérdés arra vonatkozott, hogy hasonló hatásfokú, de nagyságrendileg gyorsabb spamszűrő megoldást ki tud.
Nem gondolod, hogy ha lenne, akkor mar hallottunk volna rola / hasznalnak spamassassin helyett? :-)
- A hozzászóláshoz be kell jelentkezni
> Ha küldök nektek 260 ezer spamet, küldtök logokat? :)ű
Jon igy is rendesen.
> Meg tudnád kérdezni, hogy per micsoda kerül pénzbe? Bár nyilván ez függhet (függ?) a cég méretétől, a felhasználás típusától is.
Per mailbox. Olyan 5-6k. Ha pontosan kell reggel meg tudom mondani.
- A hozzászóláshoz be kell jelentkezni
Micskó Gábor wrote:
> Nem gondolod, hogy ha lenne, akkor mar hallottunk volna rola / hasznalnak
> spamassassin helyett? :-)
De, pont ezért kérdeztem. Mert azt is lazán elképzelhetőnek tartom, hogy
ti ismeritek, de én nem. :)
Az érdekes az, hogy millió mindenféle pénzbe kerülő megoldás van, amely
azt mondja magáról, hogy ő aztán mennyivel jobb és gyorsabb is. De ha ez
tényleg így van, hogy lehet, hogy nem igen használják?
Vagy csak mi magyarok vagyunk ilyen elvakult, kommunista open source
buzik? Najó, ez rátok nem vonatkozik, mert ti Exchange-et használtok
Brightmaillel. :-D
Apropó, mennyi spamet is kapsz naponta? :)
- A hozzászóláshoz be kell jelentkezni
Micskó Gábor wrote:
> Per mailbox. Olyan 5-6k. Ha pontosan kell reggel meg tudom mondani.
Yikes. Az a legjobb. Mondjuk ezen mindig gondolkoztam. Mi a mailbox
definíciója és ezt hogy ellenőrzi (vagy csak bemondásra megy?) a szoftver?
Elvégre ő csak közvetítő, így legfeljebb a mailcímekből spekulálhat.
Ilyen esetben kifejezetten jó, ha az ügyfél catchall címet kér:
ügyfél: szeretnék egy olyat, hogy akármi@faszadomain.hu-t megkapjak
mi: hány különböző címre is kapott levelet a múlt hónapban?
ügyfél: tattara tattara (grep | sort | uniq -c :) harmincnégyezerre
mi: rendben, 28 millió forint lesz. Kérem fáradjon a kasszához és küldje
be a következőt.
:)
- A hozzászóláshoz be kell jelentkezni
Szerintem:
az a 60-70% nagyon alacsony. Miért jobb ha 50 helyett 20 spamet kapok? Az ügyfél nem ezt szeretné. 50 helyett max. 5 az elfogadható.
- A hozzászóláshoz be kell jelentkezni
In article <42.47738@c.hup.hu>, Nagy Attila wrote:
>>>spamd-ben nem lehet korlátozni egy-egy instance felhasználhatóságát?
>> Nem.
> Az elég szar ügy. :(
annak aki hasznalja, biztos.
- A hozzászóláshoz be kell jelentkezni
clamsmtp-vel voltak jó tapasztalatok, de időhiány miatt nem volt bővebb teszt. Ami borzasztó tud lenni: postfix before-queue szűrés, de ahol GBit-tel esik be a vonal nem gáz :) Vagy sok gép esetén. ami működőképes, de az elején törődést igényel:
- postfix szigorúan beálíltva + dspam MySQL backenddel (igen, itt nem postgres kell, ami nem is tetszik, de ez van) + clamsmtp (itt nagyobb levelekben nem mindig sikeresen keresett vírus, két összetarolt és bzippelt linux kernel forrásba berakott eicar átcsúszott egyszer, de elég extrém tesztek mentek akkor a gép méretéhez képest).
Kereskedelmi: kereskedelmi spamszűrőt nem próbáltam. De láttam olyan kereskedelmit, ami gyak spamassassin volt, csak egy dobozban.
- A hozzászóláshoz be kell jelentkezni
Gabucino wrote:
>>Az elég szar ügy. :(
> annak aki hasznalja, biztos.
Valami infód csak van róla, ha azt állítod, hogy 1,1 GB-nál megáll a
processz.
- A hozzászóláshoz be kell jelentkezni
Ago wrote:
> clamsmtp-vel voltak jó tapasztalatok, de időhiány miatt nem volt bővebb
> teszt. Ami borzasztó tud lenni: postfix before-queue szűrés, de ahol
> GBit-tel esik be a vonal nem gáz :) Vagy sok gép esetén. ami működőképes,
> de az elején törődést igényel:
Ezt segíts már értelmezni. A postfix before queue szűrés gáz, de ha
Gbites kapcsolata van az embernek, ott nem.
Ezt kicsit nehezen értem. :)
Valahogy pont fordítva gondolnám.
> Kereskedelmi: kereskedelmi spamszűrőt nem próbáltam. De láttam olyan
> kereskedelmit, ami gyak spamassassin volt, csak egy dobozban.
Kár, azt gondoltam, hogy összefutottál párral.
Eddig Trey írt csak közvetett véleményt, jó lenne ha más is jelentkezne. :)
- A hozzászóláshoz be kell jelentkezni
In article <42.47764@c.hup.hu>, Nagy Attila wrote:
>>>Az elég szar ügy. :(
>> annak aki hasznalja, biztos.
> Valami infód csak van róla, ha azt állítod, hogy 1,1 GB-nál megáll a
> processz.
Van egy szerver amire ezt raktam anno. Es persze ezen is tortentek az esetek.
--
Bérczi Gábor
/Gabu/
- A hozzászóláshoz be kell jelentkezni
Minden konfiguralas nelkul. A megfelelo simogatasok utan sokkal jobb lett a helyzet. Viszont 0 spamszures utan kerdezd meg az ugyfeleidet, hogy hogy erzik magukat ha a 60-70% spamuk eltunik. Napokig csak mosolygo embereket latsz. A jokedv meg fokozodott, mikor ez a szam feljebb emelkedett.
- A hozzászóláshoz be kell jelentkezni
> Apropó, mennyi spamet is kapsz naponta? :)
En? En postfix+amavis+spamassassin kombot hasznalva heti 1-2-t. Ennyi csuszik at. Vagy az a kerdes, hogy mennyit szurok ki?
> Vagy csak mi magyarok vagyunk ilyen elvakult, kommunista open source buzik? Najó, ez rátok nem vonatkozik, mert ti Exchange-et használtok Brightmaillel. :-D
Nemtom. En felajanlottam, hogy csinalok valami nyilt izet, de egyszerubb volt a cegnek a penzes. Igaz meg csak tesztuzemben hasznaljuk, de szerintem a vezetes meg fogja venni veglegesre.
- A hozzászóláshoz be kell jelentkezni
Gabucino wrote:
> Van egy szerver amire ezt raktam anno. Es persze ezen is tortentek az
> esetek.
Máshol mit használsz spamszűrésre?
- A hozzászóláshoz be kell jelentkezni
In article <42.47807@c.hup.hu>, Nagy Attila wrote:
> Gabucino wrote:
>> Van egy szerver amire ezt raktam anno. Es persze ezen is tortentek az
>> esetek.
> Máshol mit használsz spamsz?résre?
bogofiltert mert az kisebb gannyal felmegy mint spamd :)
- A hozzászóláshoz be kell jelentkezni
Micskó Gábor wrote:
>>Apropó, mennyi spamet is kapsz naponta? :)
> En? En postfix+amavis+spamassassin kombot hasznalva heti 1-2-t. Ennyi
> csuszik at. Vagy az a kerdes, hogy mennyit szurok ki?
Utóbbi. :)
Az a heti 1-2 nagyon jó. :)
- A hozzászóláshoz be kell jelentkezni