Mailversand aus einem Delphi Programm

[idefix2]

Hallo,

ich raufe jetzt schon eine ganze Weile mit dem Versenden von Mails aus meiner Anwendung heraus. Indy ist ein ziemlicher Horror: Out of the box kommen nicht einmal Umlaute im Mailtext richtig an, und wo man da in dem Wust von Units was ändern muss, um das Problem zu beheben, habe ich bis jetzt nicht gefunden. Die Unzahl von unterschiedlichen Klassen macht es auch nicht unbedingt einfach, sich zurechtzufinden.

Vor längerem habe ich diese schlanke Unit zum Mailversand gefunden, die mir schon mehrmals gute Dienste geleistet hat. Nun habe ich aber das Problem, dass ich sehr grosse Attachments mit dem Mail mitsenden muss, und da hängt sich dieses Programm auf - Ich vermute, dass man ein grosses Attachment in mehrere Blöcke aufteilen und dem Mailserver die Blöcke nacheinander schicken muss, aber ich weiss nicht, was da hinsichtlich des Protokolls noch zu beachten ist, noch, welche Blockgrössen zu empfehlen ist - zu kleine Blöcke dürften den Versand vermutlich unnötig herunterbremsen. Bevor ich mich jetzt weiter durch den Indy-Code quäle, um zu schauen, wie die das machen, frage ich lieber einmal hier :wink:

[Luckie]

Nun das Verschicken sehr großer Anhänge (Was ist eigentlich sehr groß?) wird das Programm eben mit dem Verschicken beschäftigt sein und kann eben nicht mehr auf Benutzereingaben und ähnliches reagieren.

BTW das "Aufteilen" in Blöcke übernimmt eine untere OSI Schicht und nicht das Application Layer.

[idefix2]

Sehr gross ist in meinem Fall maximal 2MB - Da bleibt das Programm komplett hängen.
Mit Thunderbird kann ich aber Mails mit solchen Anhängen, sogar mit 10MB, problemlos bei meinem Mailserver absetzen, es kann also nicht daran liegen, dass so ein Mail prinzipiell zu gross für meinen Server wäre.

[idefix2]

Zitat:

Zitat von Luckie (Beitrag 1304744)

BTW das "Aufteilen" in Blöcke übernimmt eine untere OSI Schicht und nicht das Application Layer.

Hmm, bist du da sicher?
In der msdn steht zum winsock Send Aufruf, den dieses Programm verwendet:

Zitat:

The send function is used to write outgoing data on a connected socket.

For message-oriented sockets (address family of AF_INET or AF_INET6, type of SOCK_DGRAM, and protocol of IPPROTO_UDP, for example), care must be taken not to exceed the maximum packet size of the underlying provider. The maximum message packet size for a provider can be obtained by calling getsockopt with the optname parameter set to SO_MAX_MSG_SIZE to retrieve the value of socket option. If the data is too long to pass atomically through the underlying protocol, the error WSAEMSGSIZE is returned, and no data is transmitted.

Dass aber auch keine Fehlermeldung kommt und das Programm einfach bei dem Aufruf hängenbleibt, ist etwas eigenartig.

[idefix2]

@Luckie
Du hast Recht, das Senden funktioniert doch in einem, es dauert nur absurd lang.
Vermutlich gibt es keine Chance, von den Winsocks so etwas wie eine Fortschrittsanzeige herauszukitzeln?

[Sir Rufo]

Es dauert nicht absurd lange, es dauert einfach bis die Daten über deine Leitung an den Mail-Server geschickt wurden.

Warum Thunderbird (oder jeder andere Mail-Client) da nicht einfach stehenbleibt, liegt wohl daran, dass der Versand innerhalb eines Threads erfolgt.

[idefix2]

Naja, auch im Thunderbird kann man sehen, wie lange ein Mail braucht, um zum Server übertragen zu werden, und wann der Transfer fertig ist, unabhängig davon, dass man in der Zwischenzeit weiterarbeiten kann. Und für Vergleichswerte kann man auch einen FTP-Upload zum gleichen Provider hernehmen.
Das Senden des Mails aus meiner Anwendung heraus braucht ein Vielfaches dieser Zeit, und das verstehe ich nicht so recht.

[Hansa]

Du machst da irgendwas verkehrt. :mrgreen: Mit den Indy's ist ein email-Sendeprogramm jedenfalls mit höchstens 50 (eher 20 Zeilen) zu scghafen. Das liegt daran, dass eben immer irgendwelcher Mist aus dem Internet abgekupfert wird. Der ist meist überfrachtet mit unnötigem Zeug. Hinzu kommt dann noch eine gewisse Beratungskonsistenz. Verbesserungsvorschläge werden eben ignoriert.

Ich habe hier ein 150 Zeilen Programm, um emails zu senden. Das liest aus Ini-Datei die Zugangsdaten, den Empfänger und den Anhang. Dann habe ich noch eine Gauge eingebaut. Mit den ganzen Deklarationen usw. ist das echt nicht viel und es läuft seit 10 Jahren. Kurz gesagt : ich verstehe nicht wo das Problem ist.

[himitsu]

Je nach Codierung ist der Anhang innerhalb der Mail auch noch mindestens 33% größer. (mindestens Base64 kodiert)

[mkinzler]

Das ist aber auch bei Thunderbird und Co. so

[himitsu]

Jupp ... nur daß er sich dann nicht wundert, wenn es langsamer ist, als er denkt.

[idefix2]

Wie gesagt, der Vergleichswert ist das, was der Thunderbird für die gleiche Nachricht braucht. Und der codiert den Anhang auch base64, braucht zum Senden aber nur einen Bruchteil der Zeit (da geht es nicht um 33%, sondern der ist gut 10 mal schneller).
Zum Testen schreibe ich den kompletten Datentransfer in einem Logfile mit, das werde ich jetzt probeweise herausnehmen - aber ich kann mir nur schwer vorstellen, dass das die Bremse ist.

[BUG]

Die verwendete base64-Funktion ist mit den ganzen String-Konkatenation (und damit Kopien) der Horror.
Probiere mal eine optimierte Variante hier aus dem Forum, das könnte schon eine Menge bringen.

Was mir ansonsten auffällt, ist das die Datei erst komplett in den Speicher geladen wird, dann nach base64 codiert wird und erst danach komplett gesendet wird. Das ließe sich vermutlich parallelisieren. Aber vorher solltest du dir auf jeden Fall erst einmals base64 angucken.

Lass dir mal die Zeiten für die unterschiedliche Phasen(Lesen/Kodieren/Senden) anzeigen, dann siehst du eventuell wo das meiste herauszuholen ist

[Perlsau]

Zitat:

Zitat von Hansa (Beitrag 1304754)

Mit den Indy's ist ein email-Sendeprogramm jedenfalls mit höchstens 50 (eher 20 Zeilen) zu schaffen.

Kann ich bestätigen: Bislang konnte ich keine nennenswerten Probleme beim Mailversand via Indi-Komponenten feststellen. Dank der Indys ist so ein Programmteil sehr kurz und schnell implementiert. Wie häufig haben wir auch hier keinen keinen Code, so daß wir nicht wissen können, was der arme Idefix heute wieder für ein Süppchen gekocht hat :wink:

[Jasocul]

Ich kann mir auch vorstellen, dass das AV-Programm da noch ausbremst.
Wenn es für Thunderbird so eingestellt ist, dass der Mail-Versand nicht geprüft wird und das Programm von idefix immer geprüft wird, dann kann bei großen Dateien schon mal zusätzlicher Zeitbedarf auftreten.

Ich habe die Indy-Komponenten in eigene Komponenten gekapselt. Je eine für den SMTP und den MAPI-Versand. Insgesamt 380 Zeilen inklusive Leerzeilen, Kommentare und theoretisch unnötiger begin-end-Zeilen. Ist also wirklich kein Hexenwerk. Langsamer Versand ist mir dabei noch nie aufgefallen. Weder bei großen Dateien, noch beim Versand vieler Dateien im Anhang.

[Jumpy]

Zitat:

Zitat von Perlsau (Beitrag 1304760)

Wie häufig haben wir auch hier keinen keinen Code, so daß wir nicht wissen können, was der arme Idefix heute wieder für ein Süppchen gekocht hat :wink:

Ich vermute er benutzt die in #1 verlinkte Unit "out of the box".

[idefix2]

@BUG
Danke für den Hinweis. Ich habe das jetzt gecheckt, die Encode Routine braucht tatsächlich fast die ganze Zeit, und der Zeitbedarf steigt bei dem Algorithmus natürlich quadratisch mit der Grösse des Anhangs an - keine besonders gute Idee :-D
In den meisten Fällen ist ja die Zeit, die ein Programm im Arbeitsspeicher Daten schaufelt, gegenüber der Zeit, die für I/O aufgewendet wird, vernachlässigbar, deshalb habe ich darauf nicht geschaut.

Die Routine muss ich umschreiben.

[BUG]

Noch eine kleine Ergänzung für kommende Generationen: die überarbeitete Unit hat idefix2 im Originalthema hochgeladen :wink:

[mensch72]

kaum noch universell verwendbar, denn welcher Mailserver über Standardprovider wie z.B. 1&1 nimmt noch SMTP Auth ohne SSL/TLS an?

Das ohne Indy auch zu Fuß selbst machen.. dann mal viel Spaß;)

[idefix2]

Mein Provider zum Beispiel, sonst hätte ich ein Problem :wink:

Wenn ich dazu komme, schau ich mir das an, das wird sicher auch lösbar sein. Für den Augenblick bin ich mit dem glücklich, was ich habe.

[himitsu]

Kommt aber auch darauf an, wie sehr es sich lohnt ... Wenn man einige Technologien von Embarcadero und Fremdfirmen einsetzt, dann hat man Indy eh schon im Programm.