Emailtje breekt pop3 sessie

[Verwijderd]

Sinds een paar dagen krijgen diverse van mijn klanten rare emailtjes die de pop3 sessie breekt.

Ik heb een aantal feiten:
• de klanten zijn over verschillende servers verdeeld
• de verschillende servers hebben verschillende server software
• als ik dan ga kijken is het een emailtje ZONDER body of subject, maar met een fout in Message-ID of een andere identifier regel.
• alle klanten die ik er naar heb gevraagd gebruiken MSOE. 1 klant ben ik vergeten te vragen, maar ik ga er van uit dat die ook MSOE gebruikt
• ik heb dit probleem nooit eerder geconstateerd, maar sinds vrijdag al meerdere malen

Dit is zo'n mailtje:

code:

Return-Path: <[e-mail]>
X-Original-To: censored@censored
Delivered-To: virtual+censored@censored
Received: from pcp04058843pcs.wbrmfd01.mi.comcast.net (pcp04058843pcs.wbrmfd01.mi.comcast.net [68.41.255.75])
        by censored (Postfix) with SMTP id 718D4D076D26
        for <censored>; Wed, 19 May 2004 05:54:44 +0200 (CEST)
Received: from 234.195.217.88 by 80.142.110.123; Wed, 19 May 2004 18:45:09 -0200
Message-ID: <X[20
Date: Wed, 19 May 2004 05:54:44 +0200 (CEST)
From: [e-mail]
To: undisclosed-recipients:;

Ik ben er nu nog niet achter of dat dit mailtje de pop3 client of de pop3 server breekt, maar het lijkt er op (ettercap) dat het de client is die faalt. Maar is er iets bekend hiervan?

Heb ik bijv een bug in outlook gemist, die nu actief misbruikt wordt om clients de DoSsen? En is er een oplossing bekend? (Bijv een regexp filter wat ik in postfix kan plaatsen?)

[maartenba]

Heb er zo ook eens enkele gehad, als je een webmail client hebt: verwijder zo even die e-mail. Horde/IMP kan deze mailtjes al zeker en vast lezen en verwijderen, waarschijnlijk zijn er nog wel...

In Eudora wordt de POP3 sessie trouwens ook onderbroken...

[Verwijderd]

maartenba schreef op 19 mei 2004 @ 15:03:
Heb er zo ook eens enkele gehad, als je een webmail client hebt: verwijder zo even die e-mail. Horde/IMP kan deze mailtjes al zeker en vast lezen en verwijderen, waarschijnlijk zijn er nog wel...

In Eudora wordt de POP3 sessie trouwens ook onderbroken...

Ehm, dat klopt. Verwijderen via de webmail behoort tot de mogelijkheden. Maar dat is niet zo professioneel tegenover klanten. Vooral als het meerdere keren per dag voorkomt, is dat niet te doen.

Dus op de lange termijn zal toch een andere oplossing nodig zijn.

[maartenba]

Als je kan filteren voor het echt in je mailbox terecht komt, kan je misschien nakijken of de message-id langer is dan x-tekens ?

[Verwijderd]

maartenba schreef op 19 mei 2004 @ 15:10:
Als je kan filteren voor het echt in je mailbox terecht komt, kan je misschien nakijken of de message-id langer is dan x-tekens ?

kan, maar het probleem is dat hij dus de ene keer message-id corrupt maakt, de andere keer een ander id veld, eentje die ik zelfs niet eens kende tot ik het zag. Helaas heb ik het betreffende mailtje al weggegooid.

Maar alleen message-id filteren zou dus niet voldoende zijn...

anyway, thanx voor de suggestie

[Markieman]

Kan je niet gewoon controleren of er na de headers een lege regel en dan een body staat.
Zo niet, weggooien?

[Egbert]

Ik ken het probleem. Het kom tegenwoordig steeds vaker voor. Ook fetchmail verslikt zich erin. Outlook (express) icm imap kan er wel tegen.

[Verwijderd]

Dit probleem heb ik nog steeds niet opgelost. Ik heb ondertussen besloten alle email te gaan weigeren die geen goede header heeft.

Dus:
Message-ID: <20040705090937.AAF1210B3234@localhost>
is wel toegestaan, maar:
Message-ID: <20040705090937.AAF1210B[3234@localhost>
wordt knetterhard geweigerd. De [ wordt niet gematcht met een ], dus gaan we er maar voor het gemak van uit dat de header kapot is.

Nu zit ik alleen met de regexp voor de header_checks waar ik niet uit kom. De [ en ] zijn control characters, en dus niet wat moeilijker. Ik heb o.a. al geprobeerd:
/\\[[^:]:]*$/ REJECT Kapotte headers
/\\[[^\]]*$/ REJECT Kapotte headers
/\\[[^\\]]*$/ REJECT Kapotte headers
/\\[[^\\\\]]*$/ REJECT Kapotte headers
/\\[[^\\\\]]*$/ REJECT Kapotte headers
/\\[[^\(]\)]*$/ REJECT Kapotte headers

De ene werkt helemaal niet, de andere blockt ook goede headers. Het moet toch zoiets zijn? Zijn er nog regexp guru's aanwezig toevallig?