groot SPAM mail probleem

[Flyduck]

We draaien hier een exchange server met eigen domeinen. Nu heeft iemand op internet bedacht om SPAM mail te gaan sturen met als afzend adres 1 van onze domein namem... Gevolg hiervan is dat we hier gemiddeld 4000 NDR mailtjes per dag krijgen met dit soort meldingen erin:

(reason: 550 [e-mail]...User unknown) <[e-mail]>
(reason: 550 [e-mail]...User unknown) <[e-mail]>
(reason: 550 [e-mail]...User unknown) <[e-mail]>
(reason: 550 5.1.1 [e-mail]... User unknown) <[e-mail]>
(reason: 550 Requested action not taken:user account inactive) <[e-mail]>
(reason: 552 Requested mail action aborted: exceeded storage allocation) <[e-mail]>
(reason: 550 5.1.1 [e-mail]... User unknown) <[e-mail]>
(reason: 550 Requested action not taken:user account inactive) <[e-mail]>
(reason: 550 5.1.1 [e-mail]... User unknown)
... while talking to mx03.earthlink.net.:
>>> RCPT To:<[e-mail]>
<<< 550 [e-mail]...User unknown
550 5.1.1 <[e-mail]>... User unknown
>>> RCPT To:<[e-mail]>
<<< 550 [e-mail]...User unknown
550 5.1.1 <[e-mail]>... User unknown
>>> RCPT To:<[e-mail]>
<<< 550 [e-mail]...User unknown
550 5.1.1 <[e-mail]>... User unknown <[e-mail]>,<[e-mail]>,<[e-mail]>... Deferred: Connection timed out with xmxpita.excite.com. ... while talking to smtp-gw-4.msn.com.:

En zo gaat het nog wel een tijdje door..

De mailtjes zijn gemiddeld 10-20kb per stuk dus dat begint aardig op te lopen... Wat is hier tegen te doen????? We betalen namelijk voor het verkeer wat over de lijn gaat dus dat begint wel aardig op te lopen.

Ik heb al mail essentials enzo voor Exchange geinstalleerd maar het is gewoon allemaal nutteloos want het verkeer gaat toch over de lijn...
De servers via wie de mail verstuurd wordt heb ik gecheckt en blijken allemaal open relay servers te zijn (meestal exchange)uit vooral .jp .kr en .dk

Is er enige manier om dit te stoppen?? we kunnen zelf niet zonder mail dus ik kan de smtp service niet stoppen.

Fly

[zwahiel]

probeer eens een van de servers te rebooten, en dan een andere (ik weet niet of je een vast ip hebt...) ip adres te geven...
Of geef 'm eventueel een andere naam... Je moet dan wel (helaas) bij al je clients de naam veranderen, maar dan ben je wel ff van het probleem af...

Je koopt dan namelijk wat tijd om de servers te sluiten voor extern verkeer...

Ik heb ook eens een keertje gehoord van een proggy waarmee je alleen bepaalde IP adressen toegang laat hebben op de server... Misschien iets voor jouw...?

[Flyduck]

Op vrijdag 04 januari 2002 15:19 schreef zwahiel het volgende:
probeer eens een van de servers te rebooten, en dan een andere (ik weet niet of je een vast ip hebt...) ip adres te geven...

We hebben idd een vast IP adres maar dat kan ik niet zomaar wijzigen omdat we dus een eigen mailserver draaien, waarbij dus ook allerlei DNS registraties horen (mx). Dus als ik het IP wijzig dan moet ik ook de DNS aan laten passen en krijgen we die mail ook weer binnen!

[paulhekje]

ik neem aan dat je een lijn hebt naar een internet provider?
die provider kan betreffende servers voor je blokkeren, zodat het ook niet meer de lijn naar je eigen server over gaat.

[Flyduck]

Op vrijdag 04 januari 2002 15:22 schreef paulhekje het volgende:
ik neem aan dat je een lijn hebt naar een internet provider?
die provider kan betreffende servers voor je blokkeren, zodat het ook niet meer de lijn naar je eigen server over gaat.

Ik heb het een tijdje bijgehouden maar het zijn echt bijna iedere keer andere IP adressen .... Uit allerlei verschillde landen.. Dus dat is gewoon niet te blocken als dat al mogenlijk zou zijn.....

[23m3]

Als het goed is kun je ergens instellen dat je relaying van buiten af (want dat is wat waarschijnlijk gebeurt) niet toe wilt staan.

[Flyduck]

Op vrijdag 04 januari 2002 15:30 schreef 23m3 het volgende:
Als het goed is kun je ergens instellen dat je relaying van buiten af (want dat is wat waarschijnlijk gebeurt) niet toe wilt staan.

Het is geen relaying... We krijgen gewoon de NDR'S binnen van alle spam-mail die niet is aangekomen,... die mail is dus gewoon gericht aan ons domein dus komt gewoon aan... (ook al bestaat de recipient zelf niet)....

[Verwijderd]

Welke versie van exchange heb je?

Het lijkt mij namelijk alsof ze jullie exchange server gebruiken als antwoord adres... en dat je daarom al die mailtjes krijgt.

Als je Exchange 5.5 draait moet je eens SP3 eroverheen gooien, dan kan dat namelijk niet meer.


Suc6.
WildCat

edit:
typo's

[Sjaaky]

Misschien kan je hier eens kijken.
http://mail-abuse.org/rbl/
Ze houden hier een blacklist bij met open-relay servers. Ik weet niet of exchange hier standaard support voor heeft, maar er zijn wel extra utils voor (staat ook op de site).

[igmar]

Misschien kan je hier eens kijken.
http://mail-abuse.org/rbl/
Ze houden hier een blacklist bij met open-relay servers. Ik weet niet of exchange hier standaard support voor heeft, maar er zijn wel extra utils voor (staat ook op de site).

Dat is betalen helaas. ordb.org is er ook een, met dezelfde functionalteit, en is ook vanuit Exchange te gebruiken. Het grote voordeel is dat er (bijna) geen verkeer over de lijn gaat.

[Flyduck]

Nog even voor de duidelijkheid:

Een spammer op internet stuurt dus duizenden spam-mailtjes via slecht beveiligde servers met als AFZEND adres een adres met onze domein naam. Dus alle mailtjes van hem die niet aankomen (en dat zijn er veel) worden teruggestuurd naar het afzend adres... en dat komt dus aan bij onze server!

[Verwijderd]

Op vrijdag 04 januari 2002 15:55 schreef Flyduck het volgende:
Nog even voor de duidelijkheid:

Een spammer op internet stuurt dus duizenden spam-mailtjes via slecht beveiligde servers met als AFZEND adres een adres met onze domein naam. Dus alle mailtjes van hem die niet aankomen (en dat zijn er veel) worden teruggestuurd naar het afzend adres... en dat komt dus aan bij onze server!

En daarom moet je even SP3 instaleren dan kan dat niet meer...

[Fatamorgana]

Op vrijdag 04 januari 2002 15:58 schreef WildCat het volgende:
En daarom moet je even SP3 instaleren dan kan dat niet meer...

Komt het dan helemaal niet meer richting server of neemt ie het gewoon niet aan? Want als het er toch eerst heen gaat om daarna geweigerd te worden is het dataverkeer er nog steeds...

[Tijger]

Kun je niets tegen doen, NDR's komen altijd terug naar het afzend adres.

[Verwijderd]

Op vrijdag 04 januari 2002 16:05 schreef Fatamorgana het volgende:

[..]

Komt het dan helemaal niet meer richting server of neemt ie het gewoon niet aan? Want als het er toch eerst heen gaat om daarna geweigerd te worden is het dataverkeer er nog steeds...

Service Pack 3 (2 ook trouwens) zorgt ervoor dat ze je Exchange server niet meer kunnen gebruiken van email relay.

Gewoone mail komt dus nog wel aan, lijkt me wel zo handig.
Alleen kunnen ze jouw mail server dus niet meer gebruiken om SPAM mail mee te sturen.

[Verwijderd]

Enige wat je misschien zou kunnen doen is filteren op inhoud van de NDR's en die eruit gooien. Is dan wel even tijdelijke oplossing, want dat wil je niet permanent hebben, maar kan je totdat de stroom NDR's ophouden wel even instellen denk ik.

[Verwijderd]

Op vrijdag 04 januari 2002 16:16 schreef WildCat het volgende:

[..]

Service Pack 3 (2 ook trouwens) zorgt ervoor dat ze je Exchange server niet meer kunnen gebruiken van email relay.

Gewoone mail komt dus nog wel aan, lijkt me wel zo handig.
Alleen kunnen ze jouw mail server dus niet meer gebruiken om SPAM mail mee te sturen.

En heeft dus geen nut nu! Lees even wat het probleem is.

1. Er is geen mail via hun server gestuurd (dus geen relay)
2. Iemand heeft een vals adres als return-adres opgegeven (die van hun), en dus komen alle NDR's bij hun aan.

Heeft verder weinig (niks) met relaying te maken.

[Flyduck]

Op vrijdag 04 januari 2002 16:18 schreef ml1 het volgende:
Enige wat je misschien zou kunnen doen is filteren op inhoud van de NDR's en die eruit gooien. Is dan wel even tijdelijke oplossing, want dat wil je niet permanent hebben, maar kan je totdat de stroom NDR's ophouden wel even instellen denk ik.

Dit heb ik op dit moment ook ingesteld,.. het grote probleem is echter dat de mail nog steeds over onze lijn heen gaat....Ik denk idd dat er gewoon nix tegen te doen is ...

[Fatamorgana]

Yep, het probleem is gewoon vooral de traffic dat die 'terug komende' mailtjes genereren. En daar lijkt dus niks aan te doen helaas... Je kunt pas zien dat het iets is wat je niet wilt als het er is, en dan is het al over de lijn geweest.

edit:

Hmmm, dat staat hier dus net boven ook al.

[Sjaaky]

Ik weet niet of dit in te stellen valt, maar als er emailtje terug komt naar [e-mail] en de exchangeserver ziet dat dit geen bestaande user is, kan hij toch direct de verbinding verbreken zonder eerst het hele mailtje te ontvangen?
Het lijkt mij trouwens nog lastiger worden als de spammer email adressen gebruikt die wel bestaan, want dan krijgen de gebruikers bakken met email.

[Verwijderd]

ik denk dat je alle mailtje moet door spitten tot je
alle bron ip's heb en dan verder .... een lange weg
met mogelijk een rechtzaak voor gemaakte onkosten/tijd
voor de veroorzaker(s) van dit probleem.

post eens een paar header's ..

[Verwijderd]

Op vrijdag 04 januari 2002 19:39 schreef Conar het volgende:
een lange weg
met mogelijk een rechtzaak voor gemaakte onkosten/tijd
voor de veroorzaker(s) van dit probleem.

een onmogelijke weg bedoelje... je moet wel heeeel veeel geld, lef en tijd hebben wil je sowieso zo ver komen dat je de persoon (en waarschijnlijk personen) wilt kunnen achterhalen, en dan nog een rechtzaak. Ik kan je vrijwel verzekeren dat je dit nooit lukt...

wat je kunt doen is hopen dat het ooit stopt

[Flyduck]

Nou ben weer ff remote ingelogt op me werk maar het gaat nog steeds maar door en door en door

Ik zal ff wat headers posten later.

[DJSmiley]

Kun je bij je provider geen rule maken dat gewoon alle "550" foutmailtjes (user unknown) wegpleurt??

Alleen toevallig jammer voor degenen die vanaf jullie iets perongeluk fout tikken, maar die hebben maar pech dan...

[localhost]

Misschien een vreemde opmerking, maar zou het misschien een oplossing zijn om bv. Sendmail onder NT te compileren en deze als enige primaire (externe) mailserver beschikbaar te maken ?

Exchange moet je dan zo inrichten dat hij alleen van en naar deze sendmail applicatie kan sturen.

Met sendmail kan je namelijk heel veel configureren, bijvoorbeeld ook het blokkeren van bekende Open-SMTP-relay's.

[Verwijderd]

Er is gewoon niks te doen aan het feit dat die NDR mails over jouw lijn naar binnen komen. Als reject of drop je ze iedere keer ze blijven naar jouw server komen en data verbruiken.

Zelfde met een DoS, je kunt em gewoon blokken op een server maar hij komt toch je netwerk op.

[Flyduck]

OK vandaag zit ik vanaf 0.00 op 406 NDR's met een gemiddelde grootte van 23KB. Hier eentje:

Your message has encountered delivery problems to the following recipients:
[e-mail]
[e-mail]
[e-mail]
[e-mail]
[e-mail]
[e-mail]
[e-mail]
[e-mail]
[e-mail]

Unable to deliver to destination domain
Failed to deliver to domain usastreet.com after 54 tries.

Your message reads (in part):

Received: from http:www.unige.ch (unverified [203.168.17.185]) by happycorp.co.kr
(EMWAC SMTPRS 0.83) with SMTP id <[e-mail]>;
Fri, 28 Dec 2001 20:43:43 +0900
Message-ID: <00002da3272b$00007489$00001836@http:www.unige.ch>
To: <[e-mail]>
From: sam_cl2340@***ONS DOMEIN***
Subject: FW: Increase your Muscle-Strength
Date: Fri, 28 Dec 2001 03:27:33 -0800
MIME-Version: 1.0
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Priority: 3
X-MSMail-Priority: Normal

[Verwijderd]

Geef eens de headers van de email. Aan de error zelf heb je niet zoveel.

[Verwijderd]

Op zaterdag 05 januari 2002 12:15 schreef Flyduck het volgende:
[knip]
Your message reads (in part):

/me from http:www.unige.ch (unverified [203.168.17.185]) by [b]happycorp.co.kr[b] (EMWAC SMTPRS 0.83) with SMTP id <[e-mail]>;
Fri, 28 Dec 2001 20:43:43 +0900
Message-ID: <00002da3272b$00007489$00001836@http:www.unige.ch>
To: <[e-mail]>
From: sam_cl2340@***ONS DOMEIN***
Subject: FW: Increase your Muscle-Strength
Date: Fri, 28 Dec 2001 03:27:33 -0800
MIME-Version: 1.0
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Priority: 3
X-MSMail-Priority: Normal

De server happycorp.co.kr heeft dit mailtje ontvangen van een machine die zichzelf http:www.unige.ch noemt (smtp HELO/EHLO commando) op ip adres 203.168.17.185
Dat is of het ip adres van de afzendende smtp server/client, of het is het IP van een server die relayt en daarbij eerder headers stript.
(die happycorp server is inderdaad een relayende smtp server, heb ik getest)
Kijk eens in wat van die andere mailtjes of daar bepaalde adressen overeen komen, als die relayserver anders is maar de afzender dezelfde heb je de dader te pakken en kun je eens gaan mailen naar [e-mail]

[Flyduck]

Naja ok hier de header van een willekeurige NDR,.. maar echt veel wijs wordt je er niet uit.. Heb wel weer ff onze domeinnaam eruit gefilterd ..

Received: from nt-public.*ONSDOMEIN* (NT-PUBLIC [192.168.0.5]) by mailserver.*ONSDOMEIN* with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
id CJ3BCAJ3; Sat, 5 Jan 2002 18:08:15 +0100
To: <sam_cl2340@*ONSDOMEIN*>
Received: from WWW.BUSINESSUN.COM (211.169.246.205[211.169.246.205 port:4335]) by nt-public.*ONSDOMEIN*Mail essentials (server 2.429) with SMTP id: <990@nt-public.*ONSDOMEIN*>transfer for <sam_cl2340@*ONSDOMEIN*>; Sat, 5 Jan 2002 06:12:33 PM +0100 ;transfer smtpmailfrom <>
X-MESINK_Inbound: 1
X-MESINK_MailForType: SMTP
X-MESINK_SenderType: SMTP
X-MESINK_Sender: <>
X-MESINK_MailFor: sam_cl2340@*ONSDOMEIN*
Received: from localhost (localhost)by www.businessun.com (8.10.1/8.10.1) id g05H8uG22075;Sun, 6 Jan 2002 02:08:56 +0900
Date: Sun, 6 Jan 2002 02:08:56 +0900
From: Mail Delivery Subsystem <[e-mail]>
Content-Type: multipart/report; report-type=delivery-status;boundary="g05H8uG22075.1010250536/www.businessun.com"
subject: Returned mail: see transcript for details
Auto-Submitted: auto-generated (failure)
x-receiver: sam_cl2340@*ONSDOMEIN*
x-sender: <>
MIME-Version: 1.0
Message-ID: <68599c5506084907d2@[192.168.0.5]>

--g05H8uG22075.1010250536/www.businessun.com
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: Quoted-Printable

--g05H8uG22075.1010250536/www.businessun.com
Content-Type: message/delivery-status
Content-Transfer-Encoding: base64

--g05H8uG22075.1010250536/www.businessun.com
Content-Type: Message/rfc822

To: <[e-mail]>
Return-Path: <sam_cl2340@*ONSDOMEIN*>
Received: from home.powertech.no ([203.168.20.246])by www.businessun.com (8.10.1/8.10.1) with SMTP id g05H4KG21988;Sun, 6 Jan 2002 02:04:21 +0900
From: sam_cl2340@*ONSDOMEIN*
Subject: Money Judgements 879m
Date: Sat, 05 Jan 2002 09:03:58 -0800
Content-Transfer-Encoding: quoted-printable
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Content-Type: text/html;charset="iso-8859-1"
x-receiver:
x-sender:
MIME-Version: 1.0
Message-ID: <68599c4106084807d2@[192.168.0.5]>

--g05H8uG22075.1010250536/www.businessun.com--


maargoed het gaat dus idd steeds via andere servers. Ik heb contact gehad met onze provider en we kunnen idd een filter proberen te laten zetten. Deze filter moet zo vroeg mogelijk op het traject komen zodat ook hun netwerk niet belast wordt. Dus dat wordt fijn IP nummers verzamelen...

[Spiff]

Je betaalt toch je ISP om dit soort dingen op te lossen?

Misschien helpt het om een regeltje aan te maken die alle NDR's forward naar [e-mail]!

Hebben gelijk materiaal voor een 'sporenonderzoek'...

[Perseus|IA]

Duck, komen die NDR's allemaal binnen naar het zelfde (niet) bestaande e-mail adres ??

zo ja, dan kan je misschien proberen om een e-mail adress aan te maken, dan komen op een mail box alle mailtjes binnen.

Als je dan een client die mailbox laat openen en daar een rule maakt om alles direct te verwijderen dan is die mail in iedergeval weg.

Kweet ut is niet ideaal, want je verlegt het probleem, en de Exchange server is nog net zo druk, maar je krijgt niet meer die NDR's in je mailbox

[StevenK]

Op vrijdag 04 januari 2002 15:55 schreef Flyduck het volgende:
Nog even voor de duidelijkheid:

Een spammer op internet stuurt dus duizenden spam-mailtjes via slecht beveiligde servers met als AFZEND adres een adres met onze domein naam. Dus alle mailtjes van hem die niet aankomen (en dat zijn er veel) worden teruggestuurd naar het afzend adres... en dat komt dus aan bij onze server!

Kun je niet aan je provider vragen alle mail gericht aan dat specifieke adres te blokken ?

[Francois]

Op zondag 06 januari 2002 08:56 schreef Perseus het volgende:
Duck, komen die NDR's allemaal binnen naar het zelfde (niet) bestaande e-mail adres ??

zo ja, dan kan je misschien proberen om een e-mail adress aan te maken, dan komen op een mail box alle mailtjes binnen.

Als je dan een client die mailbox laat openen en daar een rule maakt om alles direct te verwijderen dan is die mail in iedergeval weg.

Kweet ut is niet ideaal, want je verlegt het probleem, en de Exchange server is nog net zo druk, maar je krijgt niet meer die NDR's in je mailbox

Neej, dat is het probleem niet. Topicstarter wil voorkomen dat de NDR's over de lijn gaan. Enige dat je daaraan kan doen is op IP laten blocken van je exchange server. Maar dat wil je niet, want dan krijgt exchange niets meer binnen. Als je op username gaat filteren moeten de NDR's toch eerst over de lijn.

Zoals iemand al voorstelde: Spammers achterhalen en gerechtelijke stappen is het enige dat je kan doen Maar uiteraard is dat in de praktijk

Even afwachten of het afneemt in de komende dagen, ik gok van wel.

[Verwijderd]

Even gek idee...

Is het toch niet zo dat je mail-server gebruikt wordt om te relayen en dat de mailtjes die je terug binnenkrijgt onbestelbaar zijn?


Oeps... 2e pagina niet gelezen

[Verwijderd]

Ik neem aan dat je de webmasters van bv. www.business.com al benaderd hebt? Via hun zou je aan het IP adres/provider van de spammer kunnen komen (als hij die niet spoofed, that is)

[Coen Rosdorff]

Ik heb diverse malen mee gemaakt dat er enorme hoeveelheden spam verstuurd werden, met ons domein als afzender.

Het aantal bounces is zelfs 1x meer dan 10.000 geweest. We hadden toen een verbinding van 64Kbit, en een P60 met linux als mailserver.

Die machine begon te bezwijken onder de 100'en tcp connecties die maar half werden opgezet. (Verbindingen kwamen niet tot stand doordat de lijn zwaar overbelast was.)

De oplossing was om poort 25 op die server dicht te gooien (behalve voor de ip's van de backup MX). Hier door zakte de load op de server, en ging de mail naar onze backup MX.

De backup MX leverde de mail met ESMTP (~ 500 berichten per sessie) af aan onze mail server. Dit was een enorme verlichting voor de server, en voor de internet connectie.

Na een uurtje of 10 stampen was het hele zooitje er doorheen en hebben we de boel weer open gezet.

[Verwijderd]

De boosdoener aan de bron adressen te zien,
deze block eigenaar moet zijn klanten eens op de vingers
tikken ,of misschien zelf een veeg hebben

code:

Server used for this query: [ whois.apnic.net ]

                % Rights restricted by copyright. See 
http://www.apnic.net/db/dbcopyright.html 
% (whois7.apnic.net)

[aandacht] inetnum:     203.168.16.0 - 203.168.31.255[/aandacht]
netname:     WEBQUEST-PH
descr:   WEBSCAPE PHILIPPINES INC
descr:   INTERNET SERVICE AND PRESENCE PROVIDER
country:     PH
admin-c:     TY1-AP
tech-c: GY1-AP
changed:     [e-mail] 971114
source: APNIC

person: Ting S Yupangco
address:     31392 PIKE PLACE
address:     UNION CITY CALIFORNIA
country:     US
phone:   [phone]
fax-no: [phone]
e-mail: [e-mail]
nic-hdl:     TY1-AP
mnt-by: MAINT-NULL
changed:     [e-mail] 19960731
source: APNIC

person: Geminiano Q Yabut
address:     446 EDSA
address:     MAKATI CITY
country:     PH
phone:   [phone]
fax-no: [phone]
e-mail: [e-mail]
nic-hdl:     GY1-AP
mnt-by: MAINT-NULL
changed:     [e-mail] 19960731
source: APNIC

Die qmail/sendmail server als buffer is een goed idee
ik zou zeggen route ALL mail back to webscape.net/apnic.net

[Verwijderd]

In Exchange zit een bug (een van de vele security bugs in Exchange, in zwitserse kaas lekgeschoten met hagel zit minder gaten) en die zorgt ervoor dat relaying toch kan plaats vinden ook al heb je relaying UIT staan op je server (encapsulated SMTP relaying) Daarvoor is met SP2 een bugfix uitgebracht. Schijnbaar is dat niet het geval hier.

Workaround #1: (alleen zinvol als er niet teveel gebruikers zijn)

installeer een SMTP proxy. zet elke ECHTE mailbox adres in de lijst en blokeer non-existing. Mailtjes komen dus niet eens meer binnen (address paterns, allow "pietje@jouwdomein" enz.. enz.)

Workaround #2: (alleen zinvol als de afzender hetzelfde land of andere kenmerken gebruikt die identiek zijn in elk mailtje. werkt alleen als je ook X.400 connectors gebruikt en SP 2 of hoger draait op je exchange bak.
Vanaf dat moment kun je namelijk op DN (distinguished name) filteren.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeMTA\Parameters\x400-connectornaam\.

(bar P1 originator)

Als je daar nu het naampje van de niet bestaande mailbox in knalt, heb je een reject gebouwd en komt alleen de header binnen, niet het mailtje. Scheelt weer iets.