SMTP / POP3 Client, eMail Encoder & Decoder

[cptdark]

Das Projekt wird in http://forums.purebasic.com/german/view ... =8&t=23313 fortgeführt.

[X360 Andy]

Hallo,

sieht interessant aus, werd ich bestimmt mal genauer testen.

Frage zum ganzen, erstellst du einen "eigenen" lokalten SMTP Server beim Mail verschicken oder brauch ich einen externen Anbieter ?
Wenn das funktioniert wäre es Wahnsinn

Gruß Andreas

[cptdark]

hallo...

Es handelt sich hier um einen SMTP-Clienten, d.h. man braucht einen externen Anbieter (wie gmx, web.de, ...). Google wird erstmal wegen der Verschlüsselung nicht funktionieren. Bei Yahoo funktionierte zumindest meine alte Variante, also müsste diese hier auch gehen. Umfangreiche Tests stehen noch aus.
Was definitiv fehlt, ist eine Verbindung via SSL oder WebMail, da muss ich mal schauen, ob ich da eine Zugriffsmöglichkeit finde.

[Nino]

Hallo,

sowas steht auch noch auf meiner ToDo-Liste, also sind Deine Funktionen für mich erstmal sehr interessant.

Auf den ersten Blick:

Wegen der Menge des Codes habe ich mir vieles noch nicht angesehen, daher im Moment nur ein paar Anmerkungen:

• Die Datei "awmessage.pbi" ist ziemlich groß und unübersichtlich, die würde ich nochmal aufteilen. * siehe edit 2
• Warum ist z.B. die Prozedur ____MSG_ParseRFC822DateTime() für Windows und Linux unterschiedlich? Das sollte doch unabhängig vom OS sein, und sich nur nach dem RFC richten.
  Apropos: Seit 2001 ist die maßgebliche RFC für das Nachrichtenformat RFC 2822. Vielleicht hast Du Dich ja danach gerichtet, dann ist das "822" nur ein Schönheitsfehler in der Prozedur-Bezeichnung.
• Deine Pozedur ____MSG_DecodeBase64() scheint mir auf den ersten Blick ziemlich umständlich -- ich verstehe im Moment nicht, was sie macht bevor sie dann PureBasics Base64Decoder() aufruft.
• In ____MSG_GetRFC822DateTime() steht: tz = "GMT", solche Zeitzonen-Angaben sind spätestens seit RFC 2822 veraltet.
  Aktuelle Programme sollten optimaler Weise so etwas korrekt interpretieren falls sie es vorgesetzt bekommen, aber nicht selbst veraltete Formate erzeugen. Ein E-Mail-Datum im aktuellen Format sieht z.B. so aus: "Sat, 7 Aug 2010 17:24:40 +0200", d.h. als Zeitzonen-Angabe ist nur noch eine entspr. Zahl mit + oder - davor erlaubt (siehe auch http://www.purebasic.fr/german/viewtopi ... =8&t=23019).

Das ganze ist als Include-Dateien realisiert; funktioniert unter 32 und 64 Bit; im ANSI und Unicode-Modus und müsste auch unter Linux funktionieren (evtl kann das mal jmd testen - Danke). Getestet bisher nur mit Win7 PB 4.51 RC2 x64 ANSI/Unicode.
Sicherlich sind noch einige Fehler drin - aber grundsätzliches Abrufen/Versenden/Erstellen/Zerlegen funktioniert. (mit GMX getestet)

Bei solch größeren Projekten ist ein Testprogramm wichtig, das möglichst bequem und schnell einen Überblick vermittelt ... denn es gibt auch noch so viele andere interessante Programme zum Testen und zum Selbstschreiben. Die meisten Benutzer sehen im Gegensatz zu Dir das Programm "test.pb" zum ersten Mal. Gut wären daher kurze Hinweise darauf was genau man gerade testet (z.B. im Falle CompilerIf #TEST_MAILENCODE), und ganz am Anfang des Quelltextes Konstanten oder Variablen, um die betr. Account- und Maildaten einzutragen.

In "test.pb" ist mir noch folgende Zeile aufgefallen:

Code: Alles auswählen

Global *msg, mailtext.s, htmlmailtext.s, *part, file.s

Müsste ich diese globalen Variablen auch verwenden, wenn ich Deine Funktionen in einem Programm benutzen will? Es wäre schön, mit weniger globalen Variablen auszukommen.

Grüße, Nino


//edit 1:
Die Konsolenausgabe von "test.pb" lässt sich schlecht lesen, weil sie schnell scrollt und die Konsole dann wieder verschwindet. Um das zu verhindern, sollte am Ende von "test.pb" etwas stehen wie

Code: Alles auswählen

PrintN("Drücken Sie [Enter] zum Beenden.")
Input()

//edit 2:
Der Quelltext ist für mich (und andere die sich mit dem Thema beschäftigen) natürlich nicht interessant um ihn einfach "abzuspielen", sondern um ihn zu verstehen. Wie ich sehe, enthält die Datei "awmessage.pbi" Code zum speichern von Mail-Dateien in einem eigenen Format. Das ist ein spezielles Thema für sich, dieser Code sollte besser nicht mit Code für gemäß RFCs standardisierte Dinge in der selben Include-Datei stehen. Denn natürlich interessiere ich mich zunächst für die Dinge, die man in jedem Fall für E-Mails braucht.

Es wäre außerdem hilfreich, wenn der Quelltext ausführlicher kommentiert wäre.

[cptdark]

Hallo...

Ich werde die noch aufteilen und dokumentieren. Ist die erste Veröffentlichung meinerseits, und daher noch in meinem Style

Warum ist z.B. die Prozedur ____MSG_ParseRFC822DateTime() für Windows und Linux unterschiedlich? Das sollte doch unabhängig vom OS sein, und sich nur nach dem RFC richten.

Es werden Systemaufrufe benutzt, aber dieser Teil muss noch überarbeitet werden. Das ist noch Stand von vor fast 2 Jahren. Den RFC2822 werd ich mir dann mal anschauen - Danke.

Deine Pozedur ____MSG_DecodeBase64() scheint mir auf den ersten Blick ziemlich umständlich -- ich verstehe im Moment nicht, was sie macht bevor sie dann PureBasics Base64Decoder() aufruft.

Aufbau eines Mailanhanges in Base 64: soweit mir bekannt ist einheitliche Zeilenlänge. Also wird erst die Zeilenlänge festgestellt (kann man ja nicht unbedingt fest voraussetzen) und dann werden im Prinzip lediglich alle CRLF's entfernt.
(Ich gebe zu, ich habe nicht probiert, ob der interne Decoder die nicht einfach überspringt. In meiner alten Version habe ich das mit ReplaceString gemacht ... aber das war viel zu langsam.)

Bei solch größeren Projekten ist ein Testprogramm wichtig, das möglichst bequem und schnell einen Überblick vermittelt ... denn es gibt auch noch so viele andere interessante Programme zum Testen und zum Selbstschreiben. Die meisten Benutzer sehen im Gegensatz zu Dir das Programm "test.pb" zum ersten Mal. Gut wären daher kurze Hinweise darauf was genau man gerade testet (z.B. im Falle CompilerIf #TEST_MAILENCODE), und ganz am Anfang des Quelltextes Konstanten oder Variablen, um die betr. Account- und Maildaten einzutragen.

Ok. Testprogramme folgen

Code: Alles auswählen

Global *msg, mailtext.s, htmlmailtext.s, *part, file.s

Müsste ich diese globalen Variablen auch verwenden, wenn ich Deine Funktionen in einem Programm benutzen will? Es wäre schön, mit weniger globalen Variablen auszukommen.

Musst Du nicht, das war jetzt eigentlich nur für meine Testzwecke (v.a. auch da all-in-one). Und als Global deklariert sind sie v.a. deshalb, weil ich grundsätzlich mit EnableExplicit kompiliere.

Die Konsolenausgabe von "test.pb" lässt sich schlecht lesen, weil sie schnell scrollt und die Konsole dann wieder verschwindet. Um das zu verhindern, sollte am Ende von "test.pb" etwas stehen wie

Code: Alles auswählen

PrintN("Drücken Sie [Enter] zum Beenden.")
Input()

Gute Idee. Ist mir nicht aufgefallen, weil ich das immer direkt aus der Konsole starte. Da bleibt das Fenster ja immer offen. Und zum Debuggen nehm ich dann ja Debug in Massen.

Den Speichern-Teil will ich sowieso noch ausbauen, damit er für andere Zwecke einsetzbar wird. Der wird demnächst in eine eigene Datei umgelagert.

Es wäre außerdem hilfreich, wenn der Quelltext ausführlicher kommentiert wäre.

Wird gemacht, ich habe erstmal die öffentlichen Funktionsaufrufe dokumentiert, damit die erstmal erklärt sind. Die Interna folgen.
Ursprünglich wollte ich es eigentlich nur als DLL freigeben, aber das ist mit Linux dann nicht so gut verwendbar (zumindest x64). Und so kriegt man das Teil bestimmt auch fehlerfreier.

Danke für die Hinweise.

[cptdark]

hallo...

Änderungen:

• Bugfixes
• bessere Datumskonvertierung <-> RFC 2822
• erweiterte Dateifunktionen für eigenes Format
• Aufteilung auf mehrere Dateien
• Beispielprogramme
• erweiterte Dokumentierung

Die internen Funktionen sind jetzt etwas besser kommentiert (im Quellcode), ausserdem wurden ein paar weitere allgemein verfügbar gemacht.

Eingefügt sind bisher noch 2 Debug-Ausgaben: Serverkommunikation: gesendet/empfangen.
Falls beim SMTP/POP3 Probleme auftauchen, bitte die (anonymisierte) Ausgabe posten oder per PM.

Hinweis: Datumsfunktionen für Linux sind noch nicht vorhanden, diese kommen in Version 0.3
Ich suche da noch eine Funktion (Linux API ?) um die Zeitzone zu ermitteln. Vielleicht hat da jemand eine Idee?

[Nino]

Hallo!

Und als Global deklariert sind sie v.a. deshalb, weil ich grundsätzlich mit EnableExplicit kompiliere.

Das mache ich auch. Aber ich deklariere Variablen wann immer möglich mit Declare oder Protected statt mit Global, das erleichtert die Pflege gerade von großen Programmen.

Vielen Dank für die neue Version. Ich werde sie demnächst testen.

Hinweis: Datumsfunktionen für Linux sind noch nicht vorhanden, diese kommen in Version 0.3
Ich suche da noch eine Funktion (Linux API ?) um die Zeitzone zu ermitteln. Vielleicht hat da jemand eine Idee?

Ich habe etwas bei stackoverflow gefunden. Der Output ist offenbar direkt im passenden Format. In PB kann das dann etwa so aussehen:

Code: Alles auswählen

CompilerIf #PB_Compiler_OS = #PB_OS_Linux
   
   Procedure.s SystemTimezone()
      Protected p, ret$=""
      
      p = RunProgram("date", "+%z", "", #PB_Program_Open | #PB_Program_Read)
      If p
         ret$ = ReadProgramString(p)
         CloseProgram(p)
      EndIf
      ProcedureReturn ret$
   EndProcedure
   
CompilerEndIf


Debug SystemTimezone()

Nochmal vielen Dank für das Veröffentlichen des Codes!

Grüße, Nino

[cptdark]

Ich habe etwas bei stackoverflow gefunden. Der Output ist offenbar direkt im passenden Format. ...

Vielen Dank, habe das mal in die 0.2.1 übernommen, aber noch nicht getestet. Die Umkehrfunktion dazu fehlt ja auch noch.
Aber Linux (Ubuntu 10.04 x64) ist jetzt fertig installiert, da werde ich es am Wochenende mal probieren.

In der 0.2.1 ist ein Fehler behoben, der die Anmeldung bei einigen Anbietern fehlschlagen ließ. Des weiteren kann nun zwischen AUTH LOGIN und AUTH PLAIN gewählt werden (oder Automatik). (DL-Link wie immer im ersten Post)

[Nino]

Hallo,

was genau meinst Du mit der Umkehrfunktion zu derjenigen Funktion, die die Zeitzone ermittelt?

Grüße, Nino

[cptdark]

Eine Funktion, die das Datum aus der eMail in eine PureBasic-Datumswert umwandelt. Die bisherige Funktion benutzt eine Windows-API-Funktion.
Das dürfte aber nicht weiter schwer sein, ist ja auch nur ein Parser. (Ok, Umkehrfunktion war eine blöde Bezeichnung.)
Den Windows-Part wollte ich vorerst zumindest nicht ändern, da er ja so funktioniert.