Nee, eigenlijk niet echt; niets anders dan de timeout
nog verder opschroeven.
Nog maar eens voor de duidelijkheid aangeven waar het wat mij betreft fout gaat.
Ik heb maar even een SMTP conversatie van Wikipedia gekopieerd om e.e.a. toe te lichten:
S: 220 smtp.example.com ESMTP Postfix
C: HELO relay.example.org
S: 250 Hello relay.example.org, I am glad to meet you
C: MAIL FROM:<bob@example.org>
S: 250 Ok
C: RCPT TO:<theboss@example.com>
S: 250 Ok
C: DATA
S: 354 End data with <CR><LF>.<CR><LF>
C: From: "Bob Example" <bob@example.org>
C: Cc: theboss@example.com
C: Date: Tue, 15 January 2008 16:02:43 -0500
C: Subject: Test message
C:
C: Hello Alice.
C: This is a test message with 5 header fields and 4 lines in the message body.
C: Your friend,
C: Bob
C: .
S: 250 Ok: queued as 12345
C: QUIT
S: 221 Bye
{The server closes the connection}
Waar gaat het fout? Omdat de mailserver er op een gegeven moment wel heel lang over doet om het bericht "250 Ok: queued as 12345" te sturen. De timeout daarvoor is vorig jaar al verhoogd van 30 naar 60 seconden, dat zul je misschien ook wel gemerkt hebben.
Let wel, de RFC's (met name 5321) zeggen over dat deel van de conversatie waar het fout gaat, het volgende:
If the processing is successful, the receiver MUST send an OK reply. If the processing fails, the receiver MUST send a failure reply.
In het eerste geval mag de email-client (=Profit) de email als afgehandeld beschouwen, in het tweede geval niet; het in het ongewisse laten van de email-client over het al dan niet geslaagd zijn van de transaktie mag dus gewoon niet, maar gebeurt wel.
