SpamAssassin ziet legitieme e-mails als spam door 'Y2k10-bug'

Een bug in het SpamAssassin-filter zorgt ervoor dat legitieme e-mails sneller als spam worden aangemerkt. Het filter beschouwt mail die in 2010 is verzonden als 'ver in de toekomst', waardoor deze mail een hogere spamscore krijgt.

Een Engelse ontwikkelaar ontdekte het probleem, zo meldt H-Online. Mail uit de 'verre toekomst' krijgt van het filter 3,6 extra spam-punten. Standaard ligt het aantal punten dat een e-mail moet hebben om als spam te worden beschouwd op vijf, waardoor het filter de meeste e-mails uit de verre toekomst als spam aanmerkt. Het referentiejaar voor deze toekomstmails blijkt dit jaar nog steeds op 2010 te liggen, zodat alle mail sinds 1 januari 2010 veel extra punten krijgt toebedeeld en daardoor veel vaker als spam wordt gezien.

De 'Y2k10-bug' werd al in maart 2008 gemeld, en destijds werd het probleem al opgelost in nieuwe versies van SpamAssassin. De patch werd echter niet toegepast op eerdere versies van de software. Beheerders van een mailserver kunnen de software nu alsnog updaten om de bug te bestrijden, of de software zo instellen dat een datum in de toekomst de spamscore niet verhoogt. De patch zorgt ervoor dat de datum voor wat de software beschouwt als 'verre toekomst' wordt verlegd naar alle mail vanaf 1 januari 2020.

Reacties (87)

[CrankyGamerOG]

Deze bug is al in november erkend en opgelost.
Sysadmins die hier tegen aanliepen mogen zich schamen.......

een dagelijkse sa-update en restart van spamassassin zou dit opgelost hebben

[wildhagen]

een dagelijkse sa-update en restart van spamassassin zou dit opgelost hebben

Maar niet voor oudere versies, omdat die niet gebackport was, dat is pas afgelopen vrijdag gebeurd. Dit is nota bene door SpamAssasin zelf bevestigd.

Dus omdat SpamAssassin de update voor oudere versies niet beschikbaar stelt, moeten sysadmins zich schamen? Mag ik vragen wat hier de gedachtengang achter is? Als iets niet beschikbaar is, kan een sysadmin het toch ook niet toepassen, of wel dan?

[Reactie gewijzigd door wildhagen op 23 juli 2024 15:29]

[_JGC_]

De laatste versie is 3.2.5, en heeft deze bug ook gewoon. Verder trek je de bug elke keer weer binnen via sa-update. Toen ik het probleem zag op 1 januari heb ik mijn lokale rules gefixt, maar bleek dat die helemaal geen effect hadden omdat de dagelijkse sa-update run nog steeds de buggy rules binnenhaalde.
Inmiddels is het gefixt in rules via sa-update, dus is er nu niks meer aan de hand. Het heeft alleen wel tot 2 januari geduurd voordat dit probleem opgelost was.

[revertive]

Oftewel er was al een update voor maar mensen bleven de oude versie gebruiken dat is niet echt handig he

[wildhagen]

Right... je gaat niet zomaar even iets upgraden wat gewoon prima werkt en je eventuele nieuwe functies niet nodig hebt. If it ain't broken, don't fix it etc.

Daarnaast, als SpamAssassin al twee jaar van dit probleem wist, is het ook niet echt handig dat men het nu pas fixed, als de problemen al zijn opgetreden.

[Anoniem: 172410]

Software draaien zonder regelmatig te upgraden wordt in de softwarewereld sowieso als onverstandig gezien, als het met het net te maken heeft. Laat dit programma nou net iets met het internet te maken hebben.

Vaak worden dingen achteraf pas 'broken' als er exploits of vulnerabilities bekend worden. Tot die tijd is er niets mis met het programma, daarna is er iets mis mee. Terwijl er aan het programma helemaal niets veranderd is.

[Reactie gewijzigd door Anoniem: 172410 op 23 juli 2024 15:29]

[wildhagen]

Als er een nieuwe versie van Windows Server uitkomt zijn er maar weinig bedrijven die bestaande servers gaan upgraden, ook niet als dit webservers zijn. Vaak word dat pas gedaan als de machine afgeschreven is en vervangen word.

Idem voor veel andere software. Als iets geen (bekende) securitylekken heeft en nog prima functioneert, waarom zou je hem dan vervangen.

En zeker niet voor een zéér grondige test.

Maar SpamAssassin is imho hier de grootste veroorzaker van het probleem, door een bekend probleem twee jaar lang ongefixed te laten in oudere versies. Had men gewoon publiek die fix beschikbaar gemaakt vóór er problemen optraden was er niks aan de hand geweest.

Slechte support van SpamAssassin dus in dit geval imho.

[Reactie gewijzigd door wildhagen op 23 juli 2024 15:29]

[watercoolertje]

Heel slecht voorbeeld, een nieuwe server versie van Windows is geen update van de vorige versie het is een nieuw product (een nieuwe versie). De oude moet je echt wel updaten, je weet wel Windows update, niet Windows upgrade Doe je dat (updaten) alleen als je de machine vervangt ben je echt dom bezig helemaal als je beheerder bent met (lijkt me) verstand van zaken

Dus nee windows 2003 hoef je nog helemaal niet te vervangen met 2008 maar je dient er zekers UPDATES voor te installeren wil je het (tot op zekere hoogte) veilig willen houden

Het lek was gewoon bekend dus ik snap het probleem niet richting SpamAssissin
Hoewel als ze vandaag+10jaar zouden doen het probleem voor altijd verholpen zou zijn (tenzij we overnieuw beginnen met de jaartelling)

[Reactie gewijzigd door watercoolertje op 23 juli 2024 15:29]

[Mellow Jack]

Uuuuhm je doet het wel updaten maar je test elke update zeer grondig... en eerst in een test omgeving

Ook bij updates is het niet patchen en weer verder gaan Dan blijf je updates terug draaien enzo schiet je uiteindelijk niks mee op!!! Je test, test ,test en test en daarna ga je pas updaten!

Komt wel vaker voor dat bepaalde dll bestanden worden veranderd door een update waardoor andere programma's niet meer met dat dll bestand kan omgaan. (bijv iertutil.dll volgens mij, die de afhandeling van HTML regelt in bijv Acrobat Reader en Outlook)

[Mellow Jack]

Als je een server park beheerd is het verstandig om dit soort dingen heel erg goed te testen.
Tussen de patch release en de implementatie kan dus erg veel tijd zitten (zeker wanneer iemand dit project beheerd naast zijn normale taken)

[burne]

Er is een goede patch voor, al twee jaar, maar sommigen denken dat linux zo veilig is dat ze geen updates hoeven te installeren.

Uit het artikel blijkt overduidelijk dat alleen gebruikers van een versie uit februari 2008 of eerder last van het 'probleem' hebben gehad.

Dat krijg je nou eenmaal, als je niet patched. Ik dacht dat we daar vanaf waren nu slackware alles behalve dood is, maar blijkbaar zijn er nog een hoop Woody-gebruikers die 'apt-get' moeten ontdekken.

[wildhagen]

Er is een goede patch voor

Maar die was er alleen voor nieuwere versies, niet voor iets oudere, ze hadden hem namelijk niet gebackport, waardoor een sa-update hem dus niet installeerde.

Dat backporten is pas afgelopen vrijdag gedaan, zie dit bericht van één van hun developers.

[revertive]

Dus ze hebben deze patch nu gebackport naar een versie uit 2006, in 3 jaar hadden ze best wat moeite kunnen doen om de nieuwe versie te testen en uit te rollen.

Ik snap best dat je niet ieder half jaar een nieuwe versie wilt testen als de oude het goed doet, maar het lijkt me wel een verstandig idee om eens per jaar of per 2 jaar te updaten naar een nieuwere versie.

[.oisyn]

If it ain't broken, don't fix it etc.

Het punt is alleen, 't was dus wél broken.

[Reactie gewijzigd door .oisyn op 23 juli 2024 15:29]

[J.J.J. Bokma]

Zoals ik boven al schreef: als je SpamAssassin gebruikt moet je regelmatig de regels (waar dit over gaat) updaten omdat spammers niet liggen te slapen.

[Arnoud Engelfriet]

De bug was al veel eerder gefixt maar op een of andere manier toch weer opgedoken in de vorige versie.

[FiscBiker]

Mijn versie is up-to-date met de FreeBSD-ports, bovendien is een van mijn server vers geinstalleerd in november en ook die werd hier door getroffen.

[drZymo]

Ik moet zeggen dat ik anti-spam software zoals postgrey vele malen beter vind werken dan spamassassin.

Met postgrey wordt een mail die voor de eerste keer aankomt op een mail server tijdelijk geweigert. Als deze mail later nogmaals gestuurd wordt dan wordt hij wel geaccepteerd. De versturende mailserver zal het dus iets later nog een keer moeten proberen. Een valide mail server zal dit gewoon netjes doen. Spammers gebruiken scripts die het niet nog een keer proberen, waardoor deze mailtjes gewoon nooit aankomen in je mailbox. Werkt echt perfect. Er komen nu nog maar een paar spam mailtjes per dag door, en die worden weer netjes door thunderbird gefilterd. Ik kan het iedereen met een kleine mailserver aanraden. Veel minder gedoe dan een spamassassin installatie.

[Reactie gewijzigd door drZymo op 23 juli 2024 15:29]

[CAPSLOCK2000]

Greylisting is een leuke techniek, maar wel eentje die alleen werkt zolang het maar door een paar mensen gebruikt wordt. Als alle servers het zouden doen, dan zouden de spammers hun servers wel aanpassen om ook wat meer geduld op te brengen. Dat kost wel wat meer capaciteit, maar dat was toch al niet zo'n probleem voor botnets.

[watercoolertje]

TTot een spammer dat door heeft... en dan komt ie er net zo makkelijk in als elk ander willekeurig echt bedoelt mailtje, dus laat nou maar weinig mensen dit gebruiken dan hoeven de spammers ook geen truucjes te bedenken

[ppl]

Dat greylisting is iets wat vaak al onderdeel is van de mailserver zelf maar het filteren van mail op spam weer niet. Daar springt iets als Spamassassin handig op in. Hierbij kun je natuurlijk ook geheel je eigen regels aanmaken. Door het gebruik van greylisting kun je al een "voorselectie" maken (je maakt geen selectie omdat je mail weigert, bij een spamserver komt het dan niet meer terug) waardoor Spamassassin minder hoeft te scannen en dus ook minder resources in beslag neemt. Het is dan ook hetzelfde als wat jij doet met postgrey en Thunderbird.

[silentsnake]

Beetje appels met peren vergelijken. Postgrey doet niks anders dan een 451 genereren bij een onbekende mailserver, Spamassassin doet een daadwerkelijke scan van de e-mail in kwestie en kijkt of het overeenkomt met bepaalde patronen, en hangt vervolgens daar weer een score aan. Een goed getrainde spamassassin is veel meer waard dan een greylisting daemon.

En spammers zijn ook niet dom, het is een kwestie van tijd voordat botnetwerken gewoon vaker hun lijsje afgaan en voila, daar gaat je greylisting.

[Reactie gewijzigd door silentsnake op 23 juli 2024 15:29]

[TheLunatic]

Vreemde aanpak om daar een harde datum voor te nemen, in plaats van serverdatum+x aantal jaren.

[eamelink]

Zo vreemd is dat niet. SpamAssassin heeft (onder andere) een statische lijst met spam-rules. Daar kan je één regeltje aan toevoegen en je hebt deze functionaliteit erbij. Natuurlijk zou je die datum liever dynamisch nemen, maar dan moet je dus een variabelensubstitutiemechanisme gaan inbouwen in de spam-rules lijst met mogelijke performanceissues als resultaat of iets heel nieuws naast deze spam-rules lijst gaan gebruiken (óók met mogelijke performanceissues as resultaat ).

Echt chique is het natuurlijk niet, maar misschien wel de beste tradeoff tussen functionaliteit en performance (en zeg nou zelf; elke tien jaar even dat regeltje bijwerken is niet écht heel problematisch) en een gemakkelijke keuze als je toch al die statische lijst met regels hebt

[Bartjezz]

Idd, en als je server per ongeluk 10 jaar tever staat ingesteld, en er staat boven de mail 2029, dan wordt ie alsnog doorgelaten...

[Team-RiNo]

Als het een productie server is krijg je daardoor wel grotere problemen dan spam die wel doorkomt. Ik denk niet dat dit vaak voorkomt bij bedrijven, bij mij iig nog nooit gebeurd in 7 jaar tijd over 30 servers.

Verder is het gewoon slordig geprogrammeerd, ik programmeer zelf ook en zie de moeite/performance winst niet van het invoeren van een statisch gegeven i.p.v. een datum check + x aantal jaren/dagen. Daarbij geeft het statisch vastzetten van de datum een steeds minder effectieve spamfilter.

[oliveroms]

Het is ook niet zo moeilijk te programmeren, maar die datum check die je zo 'even' doet heeft wel performance consequenties.

Je moet namelijk ook rekening houden met verschillende locales etc etc. Dus die check kan wel een 10voud zwaarder uit komen dan een fixed date.

Als we het dan over een spamfilter hebben, die 1000 mailtjes per seconde checkt ... gaat dat wel een enorme inpakt hebben ...

[Anoniem: 236438]

Een stukje code die ff 1x per dag de datum update zou het probleem dus niet hoeven zijn?

[Team-RiNo]

Dat zou waarschijnlijk de beste oplossing zijn. Ik zie ook niet waarom de locales een probleem zijn, zelfs als je alles wat meer dan 2 dagen in de toekomst zit als spam aanmerkt dan maakt het locatie/tijd verschil niet uit.

[dtech]

Als je server zo staat ingesteld verdien je het niet eens om goede spamfiltering te krijgen...

Lijkt me echt een non-probleem. Performance lijkt me een veel belangrijker argument.

[cmegens]

Zo vreemd is dat niet. SpamAssassin heeft (onder andere) een statische lijst met spam-rules. Daar kan je één regeltje aan toevoegen en je hebt deze functionaliteit erbij. Natuurlijk zou je die datum liever dynamisch nemen, maar dan moet je dus een variabelensubstitutiemechanisme gaan inbouwen in de spam-rules lijst met mogelijke performanceissues als resultaat of iets heel nieuws naast deze spam-rules lijst gaan gebruiken (óók met mogelijke performanceissues as resultaat ).

Echt chique is het natuurlijk niet, maar misschien wel de beste tradeoff tussen functionaliteit en performance (en zeg nou zelf; elke tien jaar even dat regeltje bijwerken is niet écht heel problematisch) en een gemakkelijke keuze als je toch al die statische lijst met regels hebt

Het blijkt toch maar weer dat de 'quick and dirty' oplossing op de lange termijn meer kost dan de nette oplossing. Dit kost natuurlijk ongelofelijk veel geld, voor zowel SpamAssassin als mede de bedrijven die de filter gebruiken. Terwijl er ook 1 programmeur een half uurtje een dynamische regel had kunnen programmeren...

[J.J.J. Bokma]

Dat ligt dan echt aan de bedrijven. Omdat spam zelf dynamisch is, moet je regelmatig de regels updaten. De score van regels en nieuwe regels worden regelmatig bijgewerkt omdat spammers ook niet liggen te slapen.

Het is dus geen 'quick and dirty' oplossing, maar gewoon niet weten waar je mee bezig bent.

[MicGlou]

We hebben het hier niet over dynamische regels, termen, scripts etc etc waar rekening mee gehouden moet worden, het gaat om een regeltje waar een uiterste datum in staat... een regeltje wat 'simpel' mee zou kunnen groeien met de ingestelde tijd en datum van het systeem waar het op draait. Er zijn denk ik wel zo 20 oplossingen te verzinnen waarmee dit probleem voorkomen had kunnen worden.

Tis mijn inziens dus absoluut wel 'snel en vies' geweest, niet weten waar je mee bezig bent geweest gaat er bij mij niet in. Het is verdorie de 'core-business' van wat dat stukje software moet doen... plus dat ze al geruime tijd op de hoogte waren van dit probleem. Dit mag je als klant simpelweg niet pikken, het is pure nalatigheid.

[oliveroms]

Nee, je wilt niet dingen als server tijd gebruiken. Dit is niet zomaar een slordige bug oid.

Het is een nalatigheid in het updaten geweest.

[MicGlou]

Dat het in principe een kleinigheid is ben ik met je eens, maar niet problematisch? Klarblijkelijk wel iets waar niemand aan dacht, ook al was het een bug die al 2 jaar bekend was/is... dit zijn juist van die dingen die over het hoofd worden gezien, waarschijnlijk ooit geimplementeerd omdat het makkelijker programmeren was. Tegen de tijd dat de periode verlopen is denkt niemand er meer aan, al je klanten last van dezelfde bug... heel slordig beleid imao... dan had je beter iets meer moeite daarin kunnen steken zodat een dergelijke datum automatisch wordt bijgehouden.

Ik vind het een fout waar spamassasin zich goed voor zou moeten schamen, tis eigenlijk een soort beginnersfout...

[i-chat]

nog beter zou het zijn als die 'ver' in de toekomst gewoon in een ini / .conf of sql argument staat. zodat de beheerder zelf kan bepalen 'wat' ver in de toekomst is....

op 'mijn' server (als ik die had) - zou +3 maanden al ver. zijn. voor anderen is dan misschien 18 maanden.. en voor weer anderen 3+ weken of zelfs 3 dagen.... kortom.

in een config file zetten, en door een cronjob laten aanpassen.... als je dat wlt.
of statisch als je niet weet hoe cron werkt -of dit een tegroot risico vind.

[oliveroms]

het is een spam rule, dus is al makkelijk configureerbaar so to speak. dus wat je voorstelt kan allemaal al wel.

[Twisted.Strife]

Ik kan nog begrijpen dat voor performance redenen ze de datum niet elke keer er een mail binnenkomt opnieuw willen moeten ophalen en er x tijd bij optellen.

Maar dat weerhoudt hen er nog altijd niet van om om de zoveel tijd en/of bij het opstarten van SpamAssassin deze waarde alsnog te berekenen en de bijhorende regel aan te passen.

[Antipater]

Even een variabele datum inbouwen geeft echt geen performance issues. Huidige processoren voeren een paar miljard instructies per seconde uit, dit wijst gewoon op slordig programmeerwerk.

[praseodymium]

En de bug is ook al weer een paar dagen gefixed:
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6269

[Anoniem: 314471]

'al weer een paar dagen'
Vanaf wanneer stond alweer vast dat het pas 2010 zou worden?

[SKiLLa]

En sowieso had niet alleen de penalty-waarde via rules instelbaar moeten zijn, maar ook de jaar-waarde van de 'verre toekomst' zelf, i.p.v. hardcoded.

[dasiro]

of een dynamisch berekende jaarwaarde bvb DATE + 1YR

[thegve]

Dan kan je server dat steeds opnieuw berekenen... Of was SA stateful en kan je dat tijdens de initialisatie doen?

[NMe]

Datum van vandaag + x jaar is echt geen zware berekening hoor.

[praseodymium]

Hij was al eerder gefixed, maar nog niet in een release verwerkt.

[XIU]

De "rule" checked enkel of het jaar tusse 2020 en 2099 ligt, dus 2100+ wordt niet eens gechecked.

[wildhagen]

Ah, is dat de reden. Had de laatste paar dagen al tientallen berichten naar mijn @Home-mailbox als "Spam?" werden aangemerkt, ondanks dat er helemaal niks mee mis was, en sommigen zelfs op de 'trusted senders'-lijst stonden.

Beetje knullig dat SpamAssassin kennelijk oudere versies van het pakket pas patched als er problemen optreden, terwijl men al bijna twee jaar wist dat het zou gaan optreden. Ik snap best dat ze liefst iedereen willen laten upgraden naar de nieuwste versie, maar dit lijkt me toch niet helemaal de juiste methode...

[revertive]

Is dat niet juist de rede van een nieuwe versie? Nieuwe versie komen meestal een een x aantal bug-fixes, en als je dan de oude versie blijft updaten heeft het natuurlijk minder nut om een nieuwe versie uit te brengen.

[wildhagen]

Een fabrikant die zijn gebruikers serieus neemt zal ook iets oudere versies blijven ondersteunen met patches, gedurende een bepaalde tijd althans.

En dan bedoel ik geen stokoude versies van 5 jaar geleden, maar één of twee versies vóór de actuele lijkt me wel schappelijk.

Een bedrijf gaat een stuk software echt niet acuut vervangen op dezelfde dag dat er een nieuwe versie uitkomt, áls het al gebeurd. Dat moet namelijk eerst erg goed getest worden, en in een (middel)groot bedrijf kan dat rustig enkele weken tot zelfs maanden duren, zeker omdat de beheerders ook nog meer te doen hebben, en zeker als het zo'n kritiek (voor de bedrijfsvoering) stukje software betreft als hier.

[DeKuiper]

Ik vind 2 jaar geen upgrade uitvoeren ook beetje belachelijk.. lijkt wel debian

[deadinspace]

Ik vind 2 jaar geen upgrade uitvoeren ook beetje belachelijk.. lijkt wel debian

Debian biedt gewoon spamassassin updates aan via debian-volatile, dus dat je een 2 jaar oude Debian installatie draait wil nog niet zeggen dat je met 2 jaar oude spamassassin rules zit.

[_JGC_]

Ik was er redelijk snel achter op 1 januari. Kreeg eerst al mailtjes die door Ziggo als {spam} getagged waren, mijn eigen spamfilter sloeg niet aan vanwege AWL.
Ik draai elke nacht sa-update, waarmee de nieuwe ruleset nu ook eindelijk is binnengehaald. Sommige distributies hebben nieuwe pakketjes met gefixte rulesets uitgebracht, maar voor iedereen die ooit een keer sa-update heeft gedraaid doen die helemaal niks.

Ze hebben nu gewoon de check 10 jaar verder gezet. Lopen we in 2020 weer tegenaan, maar tegen die tijd is er wel een betere oplossing voor deze ruleset.

[HerrPino]

Oftewel: de Y2k10-bug is gefixed en er is een Y2k20-bug voor in de plaats gekomen.
Waarom niet, zoals in vele andere reacties al gezegd wordt 10 jaar bij de serverdatum optellen... of dit gewoon configurabel maken (1-2 jaar vind ik persoonlijk al ver genoeg).

Iets hardcoden waarvan je 100% zeker weet dat het ooit gewijzigd moet worden is een van de grootste fouten die je als ontwikkelaar kan maken. En waarvan je weet dat het ooit problemen op gaat leveren. Nu maar hopen dat het ff een quick-fix is en er binnenkort een goede oplossing komt.

[Dipsausje]

Inderdaad een rare oplossing, zeker omdat alle spammers hun mail nu op 2019 kunnen instellen in plaats van 2020. Alles wat meer dan een maand/jaar voor loopt op de huidige datum lijkt me een logischere oplossing, en dan de waarde voor maand/jaar uitlezen uit het systeem zodat die iedere dag weer een dag verder komt. Moet je alleen nog even de datum van je servers goed ingesteld hebben, maar dat moet toch wel kunnen lukken?

[eamelink]

Waarom niet, zoals in vele andere reacties al gezegd wordt 10 jaar bij de serverdatum optellen...

Er is nu een statische lijst met regels. Natuurlijk zou je liever de serverdatum daarin kunnen gebruiken, maar dan moet er wel een substitutiesysteem geprogrammeerd worden voor de lijst met regels, met mogelijke performanceproblemen.

of dit gewoon configurabel maken (1-2 jaar vind ik persoonlijk al ver genoeg).

Het ís al configurabel. Gewoon een plaintext rules bestandje dat je zo kan bewerken

[dwizzy]

Erg knullige fout. Winnaar van de Gouden Steeksleutel, XS4ALL, had hier ook last van. Blijkbaar voldoet een oude versie van SpamAssassin voor velen nog...

[DrClaw]

nah, op mn 2 maanden oude ubuntu server install was de fout ook nog aanwezig.

[Sleepkever]

Zou het niet veel slimmer zijn om de huidige datum met 10 jaar te verhogen, beetje raar om dit er opnieuw hardcoded in te zetten...

[jip_86]

Eerder CurrentYear+1 ben je er voor altijd vanaf.

[Mellow Jack]

Ja inderdaad dan kan je vanaf vandaag ook mailtjes ontvangen met 1 jan 2011 als datum
Dan is heel die beveiliging weer weg volgens mij, je kan beter mails blocken die volgend jaar (en later) als datum hebben waardoor alles vanaf 1jan 2011 geblokkeerd wordt!

[i-chat]

het bericht direct boven je legt anders prima uit waarom dat niet altijd wenselijk...
beheerbaar lijkt me beter. (dus door de beheerder in te stellen) tijd in dagen / uren / weken of maanden....

[weebl15]

heb je alleen problemen met jaarwisselingen als tijdzones niet goed worden omgerekend of er geen rekening mee gehouden wordt.

[Rannasha]

Wat vreemd dat er bij het ontwerp van de software niet rekening wordt gehouden met dit soort dingen. 2010 is nooit echt "ver weg" geweest in het internet-tijdperk.

De datum verleggen naar 10 jaar later is in weze het probleem uitstellen. Als over 10 jaar de software nog steeds in gebruik is, krijg je precies dezelfde ellende. Waarom kiest met niet voor een optie waarbij email de "verre toekomst" punten krijgt wanneer de datum 3 jaar (om maar iets te noemen) verder in de toekomst ligt dan de huidige datum. Simpele oplossing die blijft werken ongeacht hoe lang de software in gebruik blijft.

[lredev]

ik neem aan dat sleepkever dit ook bedoelde...