vertraging bij email forwarding

[peter.deleeuw]

Ik heb een vraag.

Ik heb een domein naam die is geparkeerd bij flexwebhosting. Ik heb bij flexwebhosting ingesteld dat mail naar deze domein moet worden doorgestuurd naar mijn upc adres. Echter, mijn mail blijft tijdens het forwarden 15 tot 30 minuten 'hangen' op de servers van flexwebhosting. Flexwebhosting zegt dat dit normaal is en dat dit zo lang duurt bij elke provider.

Is dit zo?

Hieronder wat flexwebhosting mij schrijft:

'Een kwartier is normaal, vergeet niet dat het hier over forwarding gaat, het is geen mail server zoals u vergelijkt met uw upc account. Daar het een relay systeem is moet ook gecontroleerd worden of:
- de afzender ook echt bestaat
- of het mail adres waarheen gestuurd wordt ook bestaat
- of afzender geen spammer(misbruiker) is
- scannen op virussen

Al deze procedures hebben eenmaal tijd nodig, dit komt omdat het enkel forwarding is en geen mailbox zoals bij UPC, bij een normale mailbox worden al deze procedure bij ons ook niet uitgevoerd, maar bij forward mails wel. Al deze procedures zijn extra en nodig om te voorkomen dat onze relay servers niet in blacklisten terecht komen.

Indien u dit soort begrenzingen niet wilt is de enige optie het nemen van een hosting of mail pakket en de mail via POP3/IMAP op te halen/lezen en deze niet door te sturen, dan is alles "live" en redelijk direct, bij forwarders zal er altijd een vertraging op treden, deze kan soms oplopen tot wel 30 minuten.'

[Marin]

Ik vind het een vreemd verhaal,. Wij doen dezelfde checks. Als het erg druk is duurt de hele procedure hooguit 2 minten maar dat is al erg lang.

[bakkerl]

'Een kwartier is normaal, vergeet niet dat het hier over forwarding gaat, het is geen mail server zoals u vergelijkt met uw upc account. Daar het een relay systeem is moet ook gecontroleerd worden of:
- de afzender ook echt bestaat
- of het mail adres waarheen gestuurd wordt ook bestaat
- of afzender geen spammer(misbruiker) is
- scannen op virussen

Of een afzender daadwerkelijk bestaat, is niet te controlleren. Ze kunnen eventueel controlleren of de mailservers van de verzendende partij, ook voor het afzender adres mail accepteert. Echter wil dit nog niets zeggen.

De rest van de stappen doen we hier ook, en we proberen dit alles binnen 6 seconden te houden, om daarna de mail door te sturen naar de klant. Afhankelijk van de drukte wil de 6 seconden wel eens oplopen, maar nooit nooit naar de minuten Een kwartier zou bij ons dus nooit acceptabel zijn.

En persoonlijk vind ik het wel heel erg lang. Al staat er nergens in de RFC's dat email realtime is en een email bericht mag er dus ook best 3 dagen over doen (volgens de RFC)

[Marin]

Ik heb hier voord de grap eens in een log gekeken. 3-4 seconden voor de mail weer weg is..

[Triloxigen]

30 minuten is inderdaad wel lang.
Als er nog externe spamfilters/virusccanners zijn dan is er wel wat vertraging, denk aan een minuut of 2 max.

Maar 30 minuten lijkt me wat overdreven, lijkt alsof ze met een cronjob steeds email batches moeten versturen?

[Ramon Fincken]

Nouja goed een 15/30 mins is gewoon echt lang voor het "simpel doorsturen" face it ...
Ik stuur zelf ook via verschillende servers mijn mail door, en dat is binnen 30 seconden gebeurd voor 2 forwarders achter elkaar.

Ik denk dat de bottleneck m zit in dat scannen, als ze daar geen power voor hebben moet je in de queue komen en dat kan even duren. Hoe dan ook zal ik OF vragen of ze het echt nie sneller kunnen doen OF toch ergens anders je mail laten forwarden.

[host3000]

Wel grappig om te zien dat iedereen er direct vanuit gaat, dat het probleem bij de verzender zit en niet bij de ontvanger. Je kan pas wat verzenden als de recipient hem wil aanpakken. Dus, zonder logfiles kan je er niets over zeggen.

Misschien doen de mailservers van UPC wel aan greylisting, en geven ze de eerste keer een tijdelijke weigering, hoewel dat eigenlijk maar alleen de eerste keer zou moeten gebeuren.

[Ramon Fincken]

Wel grappig om te zien dat iedereen er direct vanuit gaat, dat het probleem bij de verzender zit en niet bij de ontvanger. Je kan pas wat verzenden als de recipient hem wil aanpakken. Dus, zonder logfiles kan je er niets over zeggen.

Misschien doen de mailservers van UPC wel aan greylisting, en geven ze de eerste keer een tijdelijke weigering, hoewel dat eigenlijk maar alleen de eerste keer zou moeten gebeuren.

True ! maar ... TS geeft zelf aan dat zijn hoster toegeeft dat een kwartier normaal gezien kan worden.

Hoe groot is dat kans dat zijn ISP daar nog een kwartier bovenop gooit?

@TS: test dit eens door een forward naar bv een gmail adres?

[bakkerl]

@TS: test dit eens door een forward naar bv een gmail adres?

Waarom een test. Meestal is er in de headers van een email te zien langs welke servers het bericht allemaal gegaan is en op welke tijstippen.

[host3000]

True ! maar ... TS geeft zelf aan dat zijn hoster toegeeft dat een kwartier normaal gezien kan worden.

Hoe groot is dat kans dat zijn ISP daar nog een kwartier bovenop gooit?

@TS: test dit eens door een forward naar bv een gmail adres?

Het antwoord dat TS gekregen heeft, is duidelijk een generiek antwoord om de verwachting, dat email altijd instant afgeleverd wordt, te temperen. Ik geloof niet dat de logfiles hiervoor ingezien zijn

Edit: Bij UPC kan je overigens alles verwachten.

[Ramon Fincken]

@bakkerl : klopt, maar dan schakel je UPC als partij even uit wat zeker geen raar of slecht idee is IMO

@host3000 : nee dat heb ik iig niet geroepen, mijn voorbeeld van 30 seconden voor 2x een forward is een voorbeeld van niet instant.

[peter.deleeuw]

Bijgaand de header die ik naar flexwebhosting heb gestuurd en waarvan zij vinden dat dit normaal is.

Mag ik alsjeblieft weer jullie reactie?

[peter.deleeuw]

oeps, hier dan nog een keer:

Return-Path:
Received: from edge01.upc.biz ([192.168.13.236]) by viefep20-int.chello.at
(InterMail vM.7.09.01.00 201-2219-108-20080618) with ESMTP
id
for ; Tue, 17 Feb 2009 14:32:34 +0100
Received: from dns.mail.forward.flexwebhosting.nl ([85.92.140.135])
by edge01.upc.biz with edge
id H1YZ1b00E2vULnH011YabE; Tue, 17 Feb 2009 14:32:34 +0100
X-SourceIP: 85.92.140.135
Received: from localhost (localhost.localdomain [127.0.0.1])
by dns.mail.forward.flexwebhosting.nl (Postfix) with ESMTP id 066604590C46
for ; Tue, 17 Feb 2009 14:32:23 +0100 (CET)
X-Virus-Scanned: amavisd-new at dns.mail.forward.flexwebhosting.nl
Received: from dns.mail.forward.flexwebhosting.nl ([127.0.0.1])
by localhost (dns.mail.forward.flexwebhosting.nl [127.0.0.1]) (amavisd-new, port 10024)
with LMTP id YBbQ+zxKGukb for ;
Tue, 17 Feb 2009 14:32:22 +0100 (CET)
Received: from wsspam05.livemail.nl (wsspam05.livemail.nl [193.93.174.197])
by dns.mail.forward.flexwebhosting.nl (Postfix) with ESMTP id D93614590C45
for ; Tue, 17 Feb 2009 14:32:21 +0100 (CET)
Received: from wsmail04.livemail.nl (wsmail04.livemail.nl [193.93.174.43])
by wsspam05.livemail.nl (Spam Firewall) with ESMTP
id DF88F175685; Tue, 17 Feb 2009 14:14:18 +0100 (CET)
Received: from wsmail04.livemail.nl (wsmail04.livemail.nl [193.93.174.43]) by wsspam05.livemail.nl with ESMTP id e5essKAfb2BrABc6; Tue, 17 Feb 2009 14:14:18 +0100 (CET)
Received: from WSWWW06 ([193.93.174.96]) by livemail.nl with MailEnable ESMTP; Tue, 17 Feb 2009 14:14:16 +0100
MIME-Version: 1.0
From: deDatabaseSpecialisten.nl
To: peter.deleeuw@2kit.nl
Date: 17 Feb 2009 14:14:11 +0100
Subject: Activeer je Business Card
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: base64
Message-Id:

[Marin]

Zo te zien blijft hij een kwartier hangen bij livemail.nl

[Kingcobra]

Mail word op spam gefilterd bij livemail, daar zit dus duidelijk de vertraging.
Er van uitgaande dat een server met de naam wsspam05 een spamfilter is.

Received: from wsspam05.livemail.nl (wsspam05.livemail.nl [193.93.174.197])
by dns.mail.forward.flexwebhosting.nl (Postfix) with ESMTP id D93614590C45
for ; Tue, 17 Feb 2009 14:32:21 +0100 (CET)
Received: from wsmail04.livemail.nl (wsmail04.livemail.nl [193.93.174.43])
by wsspam05.livemail.nl (Spam Firewall) with ESMTP
id DF88F175685; Tue, 17 Feb 2009 14:14:18 +0100 (CET)

mail gaat van partij a naar partij b , voor beide partijen is het van belang mail te scannen op spam en virussen, dit is om hun eigen machines en die van andere te beschermen.