Doppelposting

[Deus Figendi]

Programme wie Outlook oder Thunderbird sind Clients. Mit Hilfe der Clients kann ich meine E-Mail's vom Mailserver abholen (POP oder IMAP) bzw. E-Mails an den Mailsserver schicken (SMTP). Der Mailserver empfängt E-Mails und leitet diese entsprechend weiter. GMX stellt beispielsweise solche Mailserver zur Verfügung.

Sendmail hingegen ist selbst kein Client sondern stellt selbst einen Mailserver dar.

Das stimmt.

Um das auch mal in der Praxis umzusetzen habe ich mir mal eine Windowsimplementierung von Sendmail heruntergeladen. Hierbei handelt es sich um das Programm "indigoMail". Das Programm kann per Kommandozeile bedient werden.
(...)
Was ich hier nicht verstehe ist das in der ini-Datei ein Mailserver angegeben werden muss, ich dachte sendmail ist selbst ein Mailserver, demnach muss doch nicht noch einer in der ini-Datei angegeben werden.

Ich weiß jetzt nicht wie indigoMail funktioniert, entweder man gibt dort an als was er sich ausgeben soll oder es ist doch ein Client. Oder es ist eine Art Kombination, kann also beides.
Nach kurzer Recherche scheint es mir einfach ein Kommandozeilen-Client zu sein, wenngleich ich die Beschreibung "Windows-Version des populären Programms Unix-Sendmail" mehrfach gefunden habe.

Hab mal mit meinem Hoster (allinkl.com) telefoniert, er sagt, dass bei im die UNIX-Varinate von sendmail installiert ist. Genau diese Unix-Variante von Sendmail nutzt xt:commerce. Nun hat diese UNIX-Variante von Sendmail ja auch eine ini-Datei.

"ini" ist eigentlich eine Windows-typische Konfigurationsmethode (und auch das eher historisch). Dass die auch bei solch uralten unixoiden Programmen üblich sein soll wundert mich ein wenig.

Warum klappt denn das versenden über xt:commerce von jeder x-beliebigen Adresse? Das funktioniert bei meiner Windows Version von sendmail ja auch nicht, da wiederrum ein mailserver angegeben werden muss.

Weil SMTP beides macht: Client=>Server sowie Server=>Server-Kommunikation. SMTP sieht vor, dass Mails immer weiter geleitet werden, auch wenn sie nicht für einen selbst bestimmt sind. Die Idee ist, dass ein Server den anderen unter Umständen nicht sehen/erreichen kann, ein Mittelsmann aber beide. Zudem muss in der Regel ein Mal eine Server-Server-Kommunikation stattfinden (außer man schickt an den gleichen Server wie der von dem man versendet).
Dabei sieht SMTP keine Authentifizierung zwischen den Servern vor, wie auch? Der Benutzer hat keinen Account beim Ziel-Server und der Server natürlich auch nicht. Ein Mail-Server lässt sich ja binnen Minuten aufstellen, da können nicht plötzlich alle 3465347 anderen Mail-Server sich einen Account einrichten und wenn dann müsste das automatisch geschehen, wo ist da der Unterschied dazu keine Authentifizierung vorzunehmen?
Folglich werden Mails von Servern in der Regel einfach entgegen genommen und zugestellt. Wenn sich nun irgendjemand als Server ausgibt (d.h. er ist dann ja auch einer), dann läuft das eben ohne Auth durch. Wie oben dargestellt werden dynamische Adressen aber oftmals auch abgelehnt.
Mail-Header lassen sich dabei auch weitestgehend fälschen, man kann sogar einen Weg fälschen von wo nach wo, man eine Mail weiterleitet. Bis zu dem Punkt wo man sie eben aus der Hand gibt. Wenn du also eine Mail empfängst und du vertraust deinem Mail-Provider, dann kannst du dich darauf verlassen, dass die letzten beiden Angaben stimmen, dein Provider sagt dir, dass er selbst die Mail empfangen hat und von wem/wo. Wo der vorherige sie her hat steht auch drin, kann aber beliebig gefälscht sein.

Aber in diesem Weiterleiten etc. liegt eben auch die Krux, wenn jemand eine Mail verschickt und er sagt er hat die von example.com entgegen genommen und leitet sie nun an example.org weiter. Dann muss example.org das einfach mal so glauben. Es ist natürlich möglich nun bei example.com nachzufragen, aber das ist eben nicht vorgesehen. Der Sender muss und kann in diesem Fall nicht nachweisen, dass er die Mail von example.com entgegengenommen hat und dass der Benutzer dort auch existiert und eine Berechtigung hat Mails zu verschicken.

Und nun zur Lösung: Misstraue Mails!
Mails können eben bis auf diese zwei besagten Zeilen im Header vollständig gefälscht sein, die Absender-Adresse ist dabei nicht alles, sogar die Empfänger-Adresse kann von jeder Zwischenstation beliebig verändert werden.
Für den Snail-Mail-Vergleich: Du weißt dass der Postbote dir den Brief gebracht hat und der Postbote kann dir versichern, dass er es vom lokalen Verteiler-Zentrum entgegen genommen hat. Das Verteilerzentrum kann gegenüber dem Postboten aber behaupten was es will. (Der Postbote kann auch dich belügen, aber wie ich oben schrieb, da stellt sich die Frage ob du deinem Provider soweit vertraust).
Aber es ist ja nicht so, dass alles so schrecklich wäre :) Signiere E-Mails!
Es gibt inzwischen mindestens vier verschiedene Signierungs-Verfahren, wahrscheinlich mehr (die kenne ich eben nicht).
Signierung funktioniert einfach so, dass du über den Inhalt einer Mail einschließlich Absender-Adresse und eines Schlüssels einen Hash-Wert bildest und den einfach mitschickst. (Üblicherweise mit asynchroner Verschlüsselung sonst macht es wenig Sinn).
Ich bevorzuge Open-PGP. Ein recht verbreitetes, dezentrales System, welches auch die nächste Wirtschaftskriese und den Atom-Krieg überleben wird, ganz so wie E-Mail ursprünglich designt wurde :)
Und ich signiere seit geraumer Zeit jede meiner E-Mails. Und soweit der Empfänger ebenfalls OPGP verwendet verschlüssle ich sie auch.
Signierte Mails sind weitestgehend fälschungssicher (Ausnahme: Jemand gibt seinen privaten Schlüssel weiter). Die Schlüssel sind idR sehr sehr lang. Hier ist z.B. mein öffentlicher Schlüssel:
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v1.4.7 (MingW32)

mQENBEtioywBCAC74Xqk1DTsHr7YRG8CvKOHGS4jYUf6gPh5QX4SOcs7L0QpqHEJ
E+bbkE2tlxySD12yfEc+DVcDUQ4LveHGihMrx8SJs3YsWZns9Lwwt5O+ToeysKzK
VkD6tmsny8l+OCbd/hqxJthi/u80L8bvAg0mZyCdj2QRn9vZjt6rOWLybGUUsD9z
YgCTqsOjg8I4o/YTFOPpB9QMOoJpAKHDanOM1r6JkkPv4883F/ZSMCcC9GSYtuzX
gLWjTHbNPvy/FMuMzSA1Ds6XaAe7+pcHISxBD0SYJBntj2NnwIyPZrwL3VdH484D
zGBilF6bi74tLW7w1z7fUvudjEbcw6kX/6pvABEBAAG0REthaS1Vd2UgS3JhbWVy
IGFrYSBEZXVzIEZpZ2VuZGkgKGVhcmx3b3d3KSA8ZGV1c2ZpZ2VuZGlAZG5kLWdh
dGUuZGU+iQE8BBMBAgAmBQJLYqMsAhsjBQkCx+oABgsJCAcDAgQVAggDBBYCAwEC
HgECF4AACgkQCGHzL8QSWkV+FQf/WF73ecbvz14ptBJO3T+Yaaem+kna9o+gYYDy
KGVqVf3xKDDEti6dJQCy4ItK9d5xv+PW7AFyvKZSokkhV9y6k312IBMgsOOTEiLA
Wjn1lOzoNf/mLC6cke8hmTj9MQnWCrKyKgxwCKIr+j3FvYImHhG3mEguv5C607nG
JfjF425WybVgobhkZzG62tWlXuKm8In79OqMGNyJQSa2yYAzzSqUqiOyyxd9RRv7
9ae2ZYPGqncW36wuDWm5bg1hnxy1xsWIh9j/837V/Nn6+rn2gJ15uvbf/u+0yT64
gufyMI6vrpv+4VPubQhq1MajvY3QIllyyKEx5GXfVB+nxj8kAYhGBBMRAgAGBQJL
YrjUAAoJEBkl7/G1IPbFIZwAoILkiQwO6pt2524LulXlBmc0uD8cAJ9WBSWCMyuh
jIvao2umejgqGh8Td7kBDQRLYqMsAQgA8obXhJdnyR6I5gv+DvpujYOg2jz1CFfJ
Aa8gc9jRekdCNJK0uo89MEX+Bv8RR3EanX0DXlmI05Bbf3nPNA+H7l1otekvtiSb
Z9rN6G7mb2kS+oDrkQHyk6aJhG2dc9ioDpK5T3DKoBz6fRWTHTxlkocnB1Vd3shP
eUu72ynbFj0naeI9LATVMMFZv494xVwbueKI31+ETboP5+fjtfYOikYX3I+LZ3ZB
k0GfmOEX+JRMTaEK/Pwbrtf6ujWZVjS9O9ZiV+IXbIyuClQ/Hmd7Ts2qTeLdEZav
dZpyMgVxr8mDaLbOfisTmcUJFLgdb9nym5yNC/gqKtNiP+XlMJAaIQARAQABiQEl
BBgBAgAPBQJLYqMsAhsMBQkCx+oAAAoJEAhh8y/EElpFSIwH/j2B9Tag/yFoYyIf
WrDJLOprjhZowDxbvxSTJNJ1WeFmse5Z5T7axaDBs0+Q2GVe36AmPdYI78i+52PW
OnoPO0OYGzFbEhUKI/qpEYJGECQ6eMFImfb3RH/lNvXt3NfcXIQjqGG2M1/1kf/T
Pj54k9HALVl4ZyWjLPvlSafIXQlhVcOb+hz07XwTD3Jn9XPLp6ynb6p9s+1Cn75J
byWcZs2y+2rkBZp2ZG+gjPKS3OymSVDmMrgKC7JC/iLQsKZ7IzdFFjg+IVw81Goj
DmqTkW5PA/33fctuSGZmaRFpGaG//Tv/IMOdQDFp/+LhjQNtR0I/GVJ0PXNxWHk1
zbL9Nmk=
=nrOn
-----END PGP PUBLIC KEY BLOCK-----
Der private (den ich natürlich nicht hier poste ^^) ist ebenso lang. Also recht schwierig zu knacken :)