lantis
Sascha Retzki
Zielgruppe:
Du bist ein Mensch, der pine, evolution oder aehnliches nicht mag. Der gerne einen MTA hat, einen MDA und einen MUA? Du magst evtl mutt oder bsd-mail, und willst soviel aus der base verwenden wie irgend möglich. Hier ist dein MTA-setup, wenn du dich per SMTP-AUTH bei einen smarthost (smtp relay) authentifizieren willst (musst), wie z.b. von gmail, gmx, und andere Angeboten.
Versionen und andere Eckdaten:
OpenBSD 3.7
cyrus-sasl 2.1.20p3 (aus de ports, security/cyrus-sasl2/)
sendmail aus base. Man muss das gute Stück neu kompilieren, also braucht man auch die Quellen.
Was hier nicht besprochen wird:
MDA und MUA setups jeglicher Art. Ein paar googlewords: entweder du nimmst mutt (z.b. wenn du deine mails von POP3 abhohlst ist der prima) oder du nimmst fetchmail/procmail und als MUA bsd-mail (oder was anderes, oder mutt).
Vorgehen:
1.) Zunächst braucht unser sendmail SASL support. Also erstmal ports/security/cyrus-sasl2 installieren. Es gibt versch. flavors, wir nehmen "das normale" was vollkommen Ausreichend ist. Das binärpacket sollte auch tun.
Dann laden wir uns den src.tar.gz unserer openbsd version runter, mkdir /usr/src, mv src.tar.gz /usr/src und entpacken. (Ganz tolle Geschichte nebenbei: Ich komme von NetBSD, und bin es gewöhnt das tarbälle sich selbst ein subdir anlegen, und entpackte die quellen in /usr, was problematisch ist, wenn die hälfte deiner lib*/ sachen mit anderem Zeugs überschrieben werden
).
Wir werden nun nur sendmail neu kompilieren, und dessen Dependencies natürlich. "Es" befindet sich in gnu/usr.sbin/sendmail. Vorher müssen wir sagen, das wir sasl haben wollen, dazu gibt es angenehmerweise eine make-direktive, also schreiben wir in /etc/mk.conf:
Dann ein beherztes "make && make install clean" in oben besagtem dir. Als root, selbstredent. Anders als bei der Installation von MTAs aus dem Packetverwaltungssystem brauchen wir nicht mit dem Mailwrapper (/etc/mailer.conf) spielen, da wir das originale sendmail überschreiben werden (/usr/libexec/sendmail/sendmail).
Ich persönlich musste dann noch die Gruppe der sendmail-executable auf smmsp setzen und sie group-setuid setzen:
Das ist notwendig, sodaß auch user in TrustedUsers das ding überhaupt ausführen dürfen. (Kommt gleich)
2.) Wir konfigurieren nun erstmal sendmail. Wer sendmail so noch nicht kennt, "es" verwendet m4 (eine Art sprache ) für die Konfiguration. Wir legen in /etc/mail/ mal so eine Datei an (hier: myconf.mc):
Übersetzt werden solche "mc" Dateien dann mit m4 im Stile von:
OpenBSD hat drei .cf dateien in /etc/mail, Ich kenne es mit zwei. Kurze erklärung ist, das die Dateien abhängig davon benutzt werden, wie sendmail aufgerufen wurde. Wenn du *immer* über deinen relay verschicken willst, dann kannst du einfach die beiden anderen symlinken, e.g.:
Meine config hat noch ein paar kleine andere Sachen, aber imho sollte das so funktionieren. Wenn nicht => post it, baby.
Natürlich muss der SMART_HOST auf euren server-namen angepasst werden. Wenn es MX-probleme gibt, also das ihr z.b. über mail.m00.org relayen *müsst*, aber der Server eigentlich mail.m00net.org heißt oder was weiß ich, setzt den hostnamen einfach in eckige klammern. [mail.m00.org]
Eine Datei namens /etc/mail/trusted-users ( feature use_ct_file, war optional) möge auch eine Liste von Benutzern beinhalten. Wie gesagt, optional.
Wenn euer lokaler Username von eurem remote abweicht (und das passiert recht schnell weil diese <censored> es toll finden "bla@m00.org" als usernamen zu verwenden) so verwendet man dafür die genericstable-datei.
Nun wollen wir unsere login-daten Spezifizieren. In die client-info (oben steht .db, ich weiß. machen wir gleich. Die Datei heißt "client-info" und nicht "client-info.db"):
Der M-part ist optional, iirc.
Nun müssen wir die genericstable in ein genericstable.db format übertragen, dasselbe gilt für unsere client-info.
OpenBSD hat eine Makefile für soetwas, aber es gibt zwei probleme: 1.) Die Makefile weiß nichts von unserer client-info datei (ich glaube traditionel heißt die auch anders :P) und 2.) Man fühlt sich sowieso nicht männlich genug wenn man nur make eintippert.
Nun solltest du auch eine client-info.db sehen. Wenn nicht => antwort-post.
3.)
Cyrus-Sasl konfigurieren unser nächster Schritt ist. Eigentlich sollte es ausreichen, in dem Verzeichnis, wo die sasl2/ -libraries sind, namentlich $prefix/lib/sasl2/ oder absolut /usr/local/lib/sasl2/ , eine Datei namens Sendmail.conf anzulegen:
getpwent (ihr habt ne manpage dafür) ist die native unix/bsd methode der (lokalen) Password-authentifizierung, also das was login(1) und co auch verwenden.
Aufmerksamen Lesern mag evtl ins Gesicht springen, das ich überall explizit auf *-MD5 algos gestellt hatte, aber hier auch noch die (unsicheren) LOGIN PLAIN "algorithmen" mit reinnehme: Das ist richtig. Als ich heute morgen aufhörte zu denken, packte ich diese mit hinein, und *puff*: Es funktionierte. Davor hatte ich Einträge wie "no mechs found" oder "no mechs suitable" oder so (syslog). Kommt noch. Da allerdings in Zeile Drei gesagt wird, das algorithmen die unter einer SFS (weiß gar nimmer ob das wirklich so hieß bzw was es hieß .. man denke sich eine Art Zahl die Aussagt wie stark/gut der algo ist) von (hier
55 liegen als unsicher anzusehen sind. *-MD5 hat 128. Wer nen SSL-Tunnel baut und mit EXTERNAL arbeitet hat iirc 512. Aber wird hier eher nicht der fall sein .
4.) Troubleshooting und Testing.
Ich lege jedem Nahe zu lernen wie man mit sendmail testmails verwendet; Wenn man den $MUA_of_choice verwendet hat man zwei mögliche Probleme. 1.) Mag dieser nicht so gesprächig sein (mutt ist da ein kandidat, er sagt *immer* "Mail sent") und 2.) Man ist wie ich so schön zu sagen pflege evtl "fucked by frontend", will heißen, man hat einen weiteren layer draufgepackt, und hat evtl Probleme des MUAs und macht den MTA verantwortlich oder was-weiß-ich.
Man versende an sich selbst oder einen zweiten Account via:
Nun fängt sendmail an zu senden. Sachen die sendmail sendet sollten mit ">>> " prefixed sein. Nach einen EHLO <bla>, STARTTLS und einem zweiten EHLO sollte er "AUTH CRAM-MD5" oder ähnliches schreiben. Wenn nicht: logs checken. es gibt unter OpenBSD by default
Wenn alles glattläuft seht ihr allerdings ne Menge Buchstaben, dann
5.) Klassiker
- Sendmail will einen FQDN. Mit dynamischer IP wird das schwer. Man trage "mein_hostname.local" in die /etc/hosts ein, falls sendmail soetwas sagt wie "my unqualified hostname bla could not be resolved" oder so. Eigentlich reicht es hinter den lokalen namen in der hosts-datei einen Punkt zu machen...
6.) Anderes OS, andere Karten?
Ja. Z.B. NetBSD (da offiziell aus den USA komment) wird kein SSL haben, welches für STARTTLS gebraucht wird.
Die logfiles mögen anders sein, aber sich mit syslog auseinanderzu setzen hat noch keinem geschadet
Die grobe Richtung wird allerdings diesselbe sein.
Du bist ein Mensch, der pine, evolution oder aehnliches nicht mag. Der gerne einen MTA hat, einen MDA und einen MUA? Du magst evtl mutt oder bsd-mail, und willst soviel aus der base verwenden wie irgend möglich. Hier ist dein MTA-setup, wenn du dich per SMTP-AUTH bei einen smarthost (smtp relay) authentifizieren willst (musst), wie z.b. von gmail, gmx, und andere Angeboten.
Versionen und andere Eckdaten:
OpenBSD 3.7
cyrus-sasl 2.1.20p3 (aus de ports, security/cyrus-sasl2/)
sendmail aus base. Man muss das gute Stück neu kompilieren, also braucht man auch die Quellen.
Was hier nicht besprochen wird:
MDA und MUA setups jeglicher Art. Ein paar googlewords: entweder du nimmst mutt (z.b. wenn du deine mails von POP3 abhohlst ist der prima) oder du nimmst fetchmail/procmail und als MUA bsd-mail (oder was anderes, oder mutt).
Vorgehen:
1.) Zunächst braucht unser sendmail SASL support. Also erstmal ports/security/cyrus-sasl2 installieren. Es gibt versch. flavors, wir nehmen "das normale" was vollkommen Ausreichend ist. Das binärpacket sollte auch tun.
Dann laden wir uns den src.tar.gz unserer openbsd version runter, mkdir /usr/src, mv src.tar.gz /usr/src und entpacken. (Ganz tolle Geschichte nebenbei: Ich komme von NetBSD, und bin es gewöhnt das tarbälle sich selbst ein subdir anlegen, und entpackte die quellen in /usr, was problematisch ist, wenn die hälfte deiner lib*/ sachen mit anderem Zeugs überschrieben werden
).Wir werden nun nur sendmail neu kompilieren, und dessen Dependencies natürlich. "Es" befindet sich in gnu/usr.sbin/sendmail. Vorher müssen wir sagen, das wir sasl haben wollen, dazu gibt es angenehmerweise eine make-direktive, also schreiben wir in /etc/mk.conf:
Code:
WANT_SMTPAUTH=yesIch persönlich musste dann noch die Gruppe der sendmail-executable auf smmsp setzen und sie group-setuid setzen:
Code:
chgrp smmsp /usr/libexec/sendmail/sendmail
chmod g+s /usr/libexec/sendmail/sendmail
ls -l /usr/libexec/sendmail/sendmail
-r-xr-sr-x 1 root smmsp 623332 May 26 20:39 sendmail2.) Wir konfigurieren nun erstmal sendmail. Wer sendmail so noch nicht kennt, "es" verwendet m4 (eine Art sprache
) für die Konfiguration. Wir legen in /etc/mail/ mal so eine Datei an (hier: myconf.mc):
Code:
include(`/usr/share/sendmail/m4/cf.m4')
OSTYPE(`bsd4.4')
define(`SMART_HOST',`mail.myprovider.net')
define(`confAUTH_MECHANISMS'.`DIGEST-MD5 CRAM-MD5')
TRUST_AUTH_MECH(`DIGEST-MD5 CRAM-MD5')
dnl Dies ist ein Kommentar.
dnl Folgendes ist optional. Es wird festgelegt welche user ihre FROM: line ändern dürfen oder anderweitig previligiert sind:
define(`confTRUSTED_USERS',`dewd foo bar')
define(`confTRUSTED_USER',`dewd bar')
FEATURE(`use_ct_file')
dnl Jetzt wirds wieder nicht-optional
FEATURE(`authinfo,`hash /etc/mail/client-info.db')
MAILER(`smtp')Übersetzt werden solche "mc" Dateien dann mit m4 im Stile von:
Code:
m4 myconfig.mc >submit.cf
Code:
rm sendmail.cf localhost.cf
ln -sf submit.cf sendmail.cf
ln -sf submit.cf localhost.cfMeine config hat noch ein paar kleine andere Sachen, aber imho sollte das so funktionieren. Wenn nicht => post it, baby.
Natürlich muss der SMART_HOST auf euren server-namen angepasst werden. Wenn es MX-probleme gibt, also das ihr z.b. über mail.m00.org relayen *müsst*, aber der Server eigentlich mail.m00net.org heißt oder was weiß ich, setzt den hostnamen einfach in eckige klammern. [mail.m00.org]
Eine Datei namens /etc/mail/trusted-users ( feature use_ct_file, war optional) möge auch eine Liste von Benutzern beinhalten. Wie gesagt, optional.
Wenn euer lokaler Username von eurem remote abweicht (und das passiert recht schnell weil diese <censored> es toll finden "bla@m00.org" als usernamen zu verwenden) so verwendet man dafür die genericstable-datei.
Code:
foo bar@m00.org
Code:
AuthInfo:mail.m00.org "U:f00" "I:bar@m00.org" "P:leetpasswd" "M:DIGEST-MD5 CRAM-MD5"Nun müssen wir die genericstable in ein genericstable.db format übertragen, dasselbe gilt für unsere client-info.
OpenBSD hat eine Makefile für soetwas, aber es gibt zwei probleme: 1.) Die Makefile weiß nichts von unserer client-info datei (ich glaube traditionel heißt die auch anders :P) und 2.) Man fühlt sich sowieso nicht männlich genug wenn man nur make eintippert.
Code:
makemap hash genericstable <genericstable
makemap hash client-info <client-info3.)
Cyrus-Sasl konfigurieren unser nächster Schritt ist. Eigentlich sollte es ausreichen, in dem Verzeichnis, wo die sasl2/ -libraries sind, namentlich $prefix/lib/sasl2/ oder absolut /usr/local/lib/sasl2/ , eine Datei namens Sendmail.conf anzulegen:
Code:
pwcheck_method: getpwent
mech_list: LOGIN PLAIN DIGEST-MD5 CRAM-MD5
minimum_layer: 55Aufmerksamen Lesern mag evtl ins Gesicht springen, das ich überall explizit auf *-MD5 algos gestellt hatte, aber hier auch noch die (unsicheren) LOGIN PLAIN "algorithmen" mit reinnehme: Das ist richtig. Als ich heute morgen aufhörte zu denken, packte ich diese mit hinein, und *puff*: Es funktionierte. Davor hatte ich Einträge wie "no mechs found" oder "no mechs suitable" oder so (syslog). Kommt noch. Da allerdings in Zeile Drei gesagt wird, das algorithmen die unter einer SFS (weiß gar nimmer ob das wirklich so hieß bzw was es hieß
.. man denke sich eine Art Zahl die Aussagt wie stark/gut der algo ist) von (hier 55 liegen als unsicher anzusehen sind. *-MD5 hat 128. Wer nen SSL-Tunnel baut und mit EXTERNAL arbeitet hat iirc 512. Aber wird hier eher nicht der fall sein . 4.) Troubleshooting und Testing.
Ich lege jedem Nahe zu lernen wie man mit sendmail testmails verwendet; Wenn man den $MUA_of_choice verwendet hat man zwei mögliche Probleme. 1.) Mag dieser nicht so gesprächig sein (mutt ist da ein kandidat, er sagt *immer* "Mail sent") und 2.) Man ist wie ich so schön zu sagen pflege evtl "fucked by frontend", will heißen, man hat einen weiteren layer draufgepackt, und hat evtl Probleme des MUAs und macht den MTA verantwortlich oder was-weiß-ich.
Man versende an sich selbst oder einen zweiten Account via:
Code:
$ sendmail -v lantis@second_mail.org
der text der in der mail steht, abgeschlossen durch einen
.
Code:
/var/log/maillog
/var/log/authlog
Code:
235 "go ahead"
>>> MAIL FROM: bar@m00.org AUTH=bar@m00.org"
250 "ok"
>>> RCPT To testmail@m00.org
250 "ok"
>>> DATA"
354 "go ahead"
>>> .
250 Message accepted5.) Klassiker
- Sendmail will einen FQDN. Mit dynamischer IP wird das schwer. Man trage "mein_hostname.local" in die /etc/hosts ein, falls sendmail soetwas sagt wie "my unqualified hostname bla could not be resolved" oder so. Eigentlich reicht es hinter den lokalen namen in der hosts-datei einen Punkt zu machen...
6.) Anderes OS, andere Karten?
Ja. Z.B. NetBSD (da offiziell aus den USA komment) wird kein SSL haben, welches für STARTTLS gebraucht wird.
Die logfiles mögen anders sein, aber sich mit syslog auseinanderzu setzen hat noch keinem geschadet
Die grobe Richtung wird allerdings diesselbe sein.
Zuletzt bearbeitet:
