POP3_transporter.getMail() / isEncodingProblem

Ich have heute erstmals POP3_transporter.getMail() verwendet. Die Ausführung dauert ca. 5 Minuten bei einem kleinen Mail mit Subject und Text “Test”, gesendet mit Apple Mail.app.

			$mailInfo_c:=$transporter_o.getMailInfoList()
			For each ($in_o;$mailInfo_c)
				$message_o:=$transporter_o.getMail($in_o.number)

Es tritt der Fehler:
Fehler bei Ausführung der Methode “P_ReceiveMail” in Zeile 22

Error code: 59 (srvr)

Error code: 59 (srvr)
Error code: 59 (srvr)
component: ‘srvr’
task -11, name: ‘P_9’

auf.

Auszug aus $message_o :

{
“subject”: “Test”,
“messageId”: “<…>”,
“from”: […
],
“to”: […
],
“headers”: [

{
“name”: “Mime-Version”,
“value”: “1.0 (Mac OS X Mail 12.4 \(3445.104.14\))”
},
{
“name”: “X-Mailer”,
“value”: “Apple Mail (2.3445.104.14)”
}
],
“bodyStructure”: {
“type”: “text/plain”,
“charset”: “us-ascii”,
“subParts”: [
{
“partId”: “p0001”,
“type”: “text/plain”,
“charset”: “US-ASCII”
}
]
},
“bodyValues”: {
“p0001”: {
“value”: “”,
"isEncodingProblem": true
}
}
}

Offenbar gibt es ein Kodierungs-Problem. Mein Fehler oder kommt POP3_transporter nicht mit Apple Mail oder dem Mailserver klar?
V18R2, Mac

  • Markus Weber

Ich tippe auf ein Problem mit dem Mail-Server. Die 5 Minuten deuten auf ein Kommunikationsproblem, gefolgt von einem Timeout, hin.

Bitte schalten Sie doch mal das Logbuch ein:
https://doc.4d.com/4Dv18/4D/18/transporterlogFile.303-4505981.de.html

Mit etwas Glück sagt Ihnen das bereits etwas, ansonsten entfernen Sie ev. vorhandene vertrauliche Informationen (am besten mit xxx überschreien, aber das Format lassen) und senden dies an unsere Hotline.

Mit einem anderen Mailserver tritt das Problem nicht auf, stimmt.
Ich eröffne einen TAOW-Fall mit dem Log.

Falls noch jemand darüber stolpert, der Link:

https://doc.4d.com/4Dv18/4D/18/transporterlogFile.303-4505981.de.html

führt noch zur V18 Doku, die das POP3 Log noch nicht kennt. Man muss bei der V18R2 schauen.

danke, das Log hilft.

Es ist ein Kerio Mail Server. Damit gab (sollte behoben sein) es ein Problem das die angekündigte Länge der Meldung um 1 Byte falsch zu groß war, 4D wartet und wartet und bricht dann mit Timeout ab. So sieht auch Ihr Log aus.

Welche 4D Version verwenden Sie genau?
Könnten Sie bitte auch mal v18 LTS nightly build bzw 18 R3 tagesbuild ausprobieren?

Pop3 ist doch ein “Feature”, da komme ich mit der LTS nicht weiter :wink:

Mit der 18R3.251808: Zeitlich kein Unterschied, es dauert immer noch ewig. Aber keine Fehlermeldung und der Body-Part wird korrekt gefüllt (hier bodyValues p0001 value : “Test\r\n\r\n.”).
Log wird leider keines angelegt, trotz identischem Code zur R2 mit SET DATABASE PARAMETER (POP3 Log;1).

sorry, ich hatte das verwechselt.
Die Meldung an die ich mich mit Kerio erinnerte, war beim Senden, daher auch v18 LTS, hier kam Kerio mit einem Unicode Format nicht klar.

Die Vermutung mit dem Timeout scheint aber nicht völlig falsch zu sein.
Das Log der R3 würde also helfen das weiter einzugrenzen.

Die Variante mit SET DATABASE PARAMETER (POP3 Log;1) bietet sich als Dauerlog an, es ist ein verkürzestes Log das sich automatisch überschreibt und dauerhaft mitgeführt werden kann.

Zum Debuggen gibt es eine bessere Variante:
$server:=New object

$server.logFile:=“MyPOP3AuthLog.txt” // kann auch absoluten Pfad enthalten
$transporter:=POP3 New transporter($server)

https://doc.4d.com/4Dv18R3/4D/18-R3/Beschreibung-der-Logbucher.300-4919535.de.html#4837674
(scrollen bis 4DPOP3Log.txt)

Ab der R3 gibt es auch den Befehl: $blob:=$transporter.getMIMEAsBlob($mailInfo[0].number)
https://doc.4d.com/4Dv18R3/4D/18-R3/POP3-transportergetMIMEAsBlob.305-4961612.de.html

der entspricht quasi dem früheren POP3_Download. Der Befehl wurde eigentlich zum archivieren geschaffen, ist aber auch zum debuggen ganz praktisch. Man könnte so prüfen wie groß die original, unveränderte, Nachricht wirklich ist oder ob hier vielleicht weitere Zeichen enthalten sind/fehlen. Das könnte uns auch helfen.

Alternativ:
tritt das bei jedem Mail oder nur bestimmten auf?
Wenn bei jedem, können Sie uns auf dem Server einen Test-Account einrichten und zur Verfügung stellen (nur empfangen reicht), dann können wir selbst logs erzeugen und testen?

Die andere Debug-Methode funktioniert, das Log ist soweit ich sehe identisch zur R2.

Das Problem tritt bei allen Mails auf.