E-Mail Client in C

[kpman]

Hallo Leutz!
Ich hab da man prob:mauer:. Und zwar möchte ich einen mail client in C schreiben.
So dazu bräucht ich irgendeinen Befehl der ähnliche Funktionen wie der DOS Befehl "nslookup" bietet. Als nächstes brauch ich für dateianhänge eine funktion die dateien in ich glaube 7 oder 8 bit code umwandelt :confused:.
Also ... wenn ihr Tipps und Tricks auf Lager habt dann schreibt sie mir bitte.
Ich sag schonmal DANKE!

[butterkeks]

nslookup kenn ich net...

Ginge auch gethostbyname()?
Wie man damit umgeht kannst du in der manpage (unter unixoiden Systemen) oder im MSDN (unter Windows) nachlesen.
Im Zweifelsfalle müsste sich was bei google finden können.

Was du für Anhänge suchst nennt sich "unicode" Konversion; Auch hier hilft dir google weiter

[foobarflu]

Was du für Anhänge suchst nennt sich "unicode" Konversion; Auch hier hilft dir google weiter
Du meintest ganz sicher uuencode statt dem neumodischen unicode-Zeug.
Auch bekannt als base64.

[butterkeks]

stimmt, unicode ist was anderes; sry!

[Xpyder]

UUencode oder MIMEcode.
Dieser Kram hat folgenden Grund:
Weil eMails aufgrund des Protokolls nur Klartext erlauben,
jedoch "Daten" alle 256 Zeichen enthalten können, wird mit
Hilfe von ausgewählten "druckfähigen" Zeichen alles
dargestellt.

Dies funktioniert (beim Encoden) so:
Man denkt sich alle Bits der Bytes hintereinandergeschrieben.
Dann nimmt man aber statt der 8 Bits (für ein Byte) nur
jeweils 6 Bits, um damit ein Zeichen zu verschlüsseln.
64 Bits sind 64 Zeichen. Diese sind:
Alle Groß- und Kleinbuchstaben, alle Ziffern, sowie
Schrägstrich und Plus. Weiß grad die Reihenfolge nicht,
vermute aber ASCII-Reihenfolge - das wäre
Plus (43), Schrägstrich (47), 0 bis 9 (48 bis 57)
A bis Z (65 bis 90), a bis z (97 bis 122).

Decodieren genau andersrum.

Es versteht sich von selbst, daß codierte Files nach dem
Codieren größer sind.

Es gibt noch eine zweite Methode, die ich aber jetzt nicht
auswendig kenne - aber vermutlich ist die statt 8 zu 6 bit
halt 8 zu 7 bit - bin mir aber nicht sicher. (Das heißt,
statt 64 verschiedener Zeichen werden 128 verschiedene
benutzt.)

Achja, btw: POP3 (eMails holen) steht in RFC1939, SMTP
(eMails senden) in RFC822 oder RFC826, weiß jetzt grad
nicht genau.

Falls noch Fragen, helf ich gerne weiter.

[Alamar]

alle 256 zeichen?

[Xpyder]

Ja, alle 256 Zeichen.
Ein Byte (=8bit) kann 256 verschiedene "Zahlen" (oder halt
Zeichen) darstellen, nämlich 0 bis 255.

Die Zeichen 0 bis 31 sind aber, wenn man sie als ASCII
liest, "nichtdruckend", d.h. sie sind standardmäßig nicht
uneingeschränkt einsetzbar, wenn es um ein rein "Klartext"
(also "lesbare Zeichen") basierendes System geht - was ja
eMail über SMTP/POP3 nunmal ist.

Die Zeichen 128 bis 255 sind im ASCII nicht standardisiert
- so daß man hier theoretisch ALLES erwarten kann. Das hat
sich zwar mittlerweile geändert - aber der eMail-Standard
stammt noch aus einer Zeit, in der 7-Bit-ASCII (0 bis 127)
noch der Standard war.

Irgendwann erfanden Leute dann mal eine Möglichkeit, an
eMails Dateien anzuhängen. Problem war, daß man sie nicht
einfach anhängen konnte - weil Dateien halt ALLE Werte 0
bis 255 enthalten können (schließlich gibts nicht nur
reine Textdateien). Und dieser UUcode wurde halt
entwickelt, um mit Hilfe von 64 "druckbaren" Zeichen alle
256 darzustellen, indem man die Bits der Datei statt in
8-Bit in 6-Bit-Pakete verpackt hat.

Ich erklär das mal anders. Obere Zeile sind die Bits der
Datei, die zu UUencoden ist (pro Byte 8-Bit, also 0 bis 7).
Untere Zeile sind die entsprechenden Bits pro Zeichen, da
es nur 64 Zeichen gibt, die benutzt werden, also 6 Bit, 0
bis 5.

0-1-2-3-4-5-6-7-0-1-2-3-4-5-6-7-0-1-2-3-4-5-6-7-0-1-2-3-4-5-6-7
0-1-2-3-4-5-0-1-2-3-4-5-0-1-2-3-4-5-0-1-2-3-4-5-0-1-2-3-4-5-0-1

Klar? Das heißt, um 3 ganze Bytes zu "verschlüsseln"
braucht man 4 UUencode-Zeichen.
Weil 3 Byte = 24Bit. Und 4 6Bit-Zeichen = auch 24 Bit.