Názory k článku
SpamAssasin a jeho divotvorné pravidlo

Vůbec nechápu, koho mohlo napadnout takové záškodnické pravidlo, a propašovat ho do široce užívaného systému ?
A hlavně: proč fix tohoto pravidla znamená jen odstunutí o 10 let dopředu ? Nechcete radši napsat, jak ho vymazat navždy ?
Kdyby mělo platit, že e-maily psané s daleko-budoucím timestampem jsou podvodné, proč to není řešeno porovnáním relativně s dneškem (aktuální čas), ale je místo toho jakési magické číslo, které každých 10 let způsobí mnoha uživatelům problémy…
Dělají to lidé hloupí, nebo zlí, nebo to má nějaký tajemný důvod ?

Pracovat na pozici mail administrator by potom nebylo perspektivní? :-)

nejlepsi pravidlo by bylo jeste ten desetilety interval skratit na min. vzdyt normalni mail je dorucen jeste tu hodinu, ostatni je spam. jenomze to bychom pak resili prechody kazdy den.

Nejde o to, kdy je mail doručen, ale jaké je uvedené datum odeslání.

Spameři často nastavují datum odeslání v budoucnosti, aby jejich mail byl zobrazen jako první.

Tomu takovéto pravidlo vůbec nezabrání, neboť neodfiltruje i maily napsané „zítra“. Naproti tomu zahodí platný mail od člověka, kterému se zrovna zbláznil RTC.

Mimochodem, už se mi stalo, že mail šel 7 let. V roce 1997 jsem poslal mail to konference cstex. V roce 2004 mi došly maily o tom, že se některým lidem v konferenci mail nepodařilo doručit.

> Nejde o to, kdy je mail doručen, ale jaké je uvedené datum odeslání.

To spolu souvisí, víme?

Dělají to lidé hloupí, nebo zlí, nebo to má nějaký tajemný důvod ?

Takovéhle kiksy jsou většinou výsledkem lhostejnosti a nevědomosti.

je to řádově rychlejší, když porovnáváš direct constant oproti porovnání vůči reálnému času.

Spamassasin sice neznam a nevim jak funguje, ale za vterinu se dokazu zeptat systemu na cas asi milionkrat. Pochybuju, ze by to na beznem serveru mohlo delat potize.

Tiscali.cz pořád ještě spí :) … asi mají všichni admini dovolenou :D


Received: from mx2.i.tiscali.cz (88.86.109.157) by mail71.tiscali.cz (7.3.121)
id xxxxxxxxxxxx for xxxxxxxx@tiscali.cz; Wed, 6 Jan 2010 00:09:05 +0100
…
…
…
X-Virus-Scanned: by amavisd-new at tiscali.cz
X-Spam-Flag: YES
X-Spam-Score: 5.498
X-Spam-Level: *****
X-Spam-Status: Yes, score=5.498 tag­ged_above=2.5 re­quired=4 tests=[AWL=-1.038,
FH_DATE_PAST_20XX=2­.075, HTML_MESSAGE=0.501,
HTML_MIME_NO_HTML_T­AG=1.661, MIME_HTML_ONLY=2­.299]

X-Spam-Report

2.1 FH_DATE_PAS­T_20XX The date is grossly in the future.

…
…

To bude tim, ze Tiscali uz v CR neni, stahli se pred asi dvema lety a jejich sit prevzala CDT Telematika, asi tam v tom maji stale jeste zmatek nedavno jim prestal fungovat reverz a trvalo to vice nez jeden den nez to spravili.

zajímavé, to pravidlo tam asi mám:

header FH_DATE_PAST_20XX Date =~ /20[1–9][0–9]/ [if-unset: 2006]

ale vůbec mi to nikam žádné body nepřidává, pořád se vše boduje jak má. OS: ArchLinux.

No protoze updaty by meli koncit ve /var/lib/spamas­sassin/__verze__/up­dates.spamassas­sin.org a nikoliv v /usr/share/spa­massassin

jo to bude tím, dík za info :)

staci v /etc/spamassas­sin/local.cf nastavit:
score FH_DATE_PAST_20XX 0­.0

pak jeste restartovat spamd a amavisd

To neni reseni, jen jsi to pravidlo vyradil, zjevne si nepochopil smysl toho pravidla. :)

Jestli někdo máte regulérní diff(1), tak ho sem pošlete, ať si to opatchujeme…
Představoval bych si to tak, že když bude datum emailu „v budoucnosti“ o více než X
hodin, tak si vyslouží ty zmíněné 3 body score.

To, že autor článku tento patch neposkytl považuji za jeho naprostou lajdáckost !

– red zulu –

Autor článku řešení nabídnul:

„a administrátory, kteří mají na aktualizaci pravidel ve SpamAssasinu nástroj sa-update.“

Sice si myslím, že vymlátit prázdnou slámu z materiálu na zprávičku na celý článek, je docela velké umění, ale také si nemyslím, že by článek podobného druhu v sobě měl obsahovat manuál ke spamassassinu. Pokud pro vás údržba poštovního serveru znamená „apt-get install XXX“, tak pak máte mnohem větší problém…

prosel jsem poslednich 5 let mailu, ktere spadly do spamu a zadny (krome poslednich dni ;) toto pravidlo nespustil, tudiz nevidim zadny smysl tohoto pravidla :)

tak to se neda svitit

Zajimalo by mne proc to pravidlo rovnou nevyhodili, kdyz existuji pravidla:

describe DATE_IN_FUTURE₀₃_06 Date: is 3 to 6 hours after Received: date
describe DATE_IN_FUTURE₀₆_12 Date: is 6 to 12 hours after Received: date
… atak dale az do …
describe DATE_IN_FUTURE₉₆_XX Date: is 96 hours or more after Received: date

Ty by mely poresit stejny typ spamu a nejsou fixovane na konkretni letopocet.

Stačí se podívat na komentáře k chybě #6269 a #5852. Pravidlo FH_DATE_PAST_20XX sice už bylo opraveno v červnu minulého roku, nicméně tato oprava nikdy nepronikla do žádné stabilní verze (verze 3.2.5 vyšla ještě předtím) a vývojáři ji také zapomněli zařadit do sa-update kanálu. Ke skutečné opravě došlo až cca 2010–01–01 12:54:15 UTC.

Takže v tomto případě zodpovědnost opravdu neležela na distribucích a/nebo adminech serveru.

Musím říct, že mě dost mrzí, že na root.cz vycházejí články, které obsahují takto zásadní bludy :(.

Zdroje:
https://issues.apache.org/…show_bug.cgi?…
https://issues.apache.org/…show_bug.cgi?…

Odstavec kterého se to týká jsem přepsal a mělo by to být ok. Díky za upozornění.

Jo potvrzení objednávky z nějakého eshopu mi skončilo ve spamboxu, skóre 9, chce to hlídat.

proč mi byl označen jeden mail na VŠE 3.1. za spam. No naštěstí tam už to taky opravili.