Neas <n...@n...invalid> wrote:

>> bezwarunkowe wycinanie za pomocą RBLi (a tym bardziej jednego,
>> należącego do nieznanych osób trzecich) to nie jest jedyne
>> rozwiązanie. RBLe mogą równie dobrze być częścią składową 'oceny',
>> czy dany mail jest spamem czy nie. na taką ocenę mogą się składać
>> analizy heurystyczne treści, struktury maila
>> (content-{disposition,type} i inne), filtry bayesa i inne.
> [...] priorytetem powinna być zwykła dbałość o nie umieszczanie
> własnego adresu bezpośrednio w usenecie, na stronach www i w podobnych
> miejscach.

to tylko 'security by obscurity'. niektóre spamtrapy mogą być
przetworzone przez regexpy i inne algorytmy, reszta może być z
łatwością 'rozszyfrowana' w bardzo krótkim czasie przez człowieka.

tak czy inaczej, nie podoba mi się taka wizja, chcąc odpisać komuś na
wiadomość news prywatnie, musiałbym czasem poświęcić chwilę na
zdekodowanie krzaków w spamtrapie, pozamieniać litery. a czasem nie móc
odpisać wcale, bo adres w żadnej formie nie jest podany.

według mnie trzeba walczyć 'ramię w ramię' ze spammerami. kiedy zaczęli
zniekształcać wyrazy w wiadomościach, trzeba było mieć wymyślniejsze
regexpy. kiedy podawali same linki, URIBL załatwiło sprawę, wspomagane
wykrywaniem ilości obrazków i hateemela w porównaniu do tekstowej
treści. to jest proces, nie ma satysfakcjonującego ostatecznego
rozwiązania.

w każdym razie, standardowe metody mają tę przewagę, że nie wymagają
aktywnego zaangażowania właściciela skrzynki i stosowania przez niego
metod prewencji, jedynie jego zgody na stosowanie tych metod.

oby nie doszło do paranoi typu 'nie podam ci mojego adresu email, bo
pewnie jesteś spammerem' :))

--
Salad a firm's own make; limpid red beet soup with cheesy dumplings in the
form of a finger; roasted duck let loose; beef rashers beaten up in the
country people's fashion.