Sendmail, kiedyś domyślnie instalowany MTA w linuskach. Dzisiaj nawet nie wiem czy jest w ogóle jeszcze rozwijany. Zrobienie na nim czegokolwiek było... dziwne. No cóż, pozostawmy to tutaj, żeby sobie poleżało. Opis
Masz dosyć spamerów? Pół europy może wysyłać przez Twojego sendmaila pocztę a Ty nie możesz tego zablokować bo masz klientów modemowych? Dobra, spróbujmy coś na to poradzić. Spróbujmy zrobić sendmaila który wymaga autoryzacji (obsługiwane przez M$ Outlook Express, Netscape Mail, TheBat! i pewnie jeszcze kilkanaście innych klientów do poczty, sprawdzane z sendmailami 8.11.* i 8.12.*). Niestety metody tylko login i plain, gdyż na pozostałe nie mam czasu.
Jeżeli czujesz się na siłach kompilować źródła i nie tylko, to zapraszam do lektury już teraz. W przypadku gdy boisz się źródeł i chcesz mieć idealny porządek w swoich pakietach rpm, zapraszam na sam dół tej strony.
Małe info dla osób które będą upgrade z sendmaila z 8.11.* do sendmaila 8.12.* – aby go zainstalować należy stworzyć w systemie konto ‘smmsp’ i grupę ‘smmsp’:
groupadd smmsp useradd -g smmsp smmsp
Potrzebujemy Cyrus-SASL. W tutorialu na sendmail.org nie ma niestety opisu jak należy skompilować SASL. Znalazłem opis tego w faq o SMTP-AUTH w Postixie:
make distclean # jeżeli już kompilowaliśmy sasl ./configure --with-pwcheck --enable-login --prefix=/usr make make install echo "pwcheck_method: shadow" > /usr/lib/sasl/Sendmail.conf
To powinno wystarczyć.
Potrzebujemy Sendmaila. Rozpakowywujemy go. Do pliku devtools/Site/site.config.m4 dopisujemy:
APPENDDEF(`confLIBDIRS', `-L/usr/lib/sasl') APPENDDEF(`confINCDIRS', `-I/usr/include') APPENDDEF(`confENVDEF', `-DSASL') APPENDDEF(`conf_sendmail_LIBS', `-lsasl')
Tworzymy plik Makefile.m4 i wpisujemy:
APPENDDEF(`confENVDEF', `-DSASL') APPENDDEF(`conf_sendmail_LIBS', `-lsasl')
sh Build; sh Build install
Przyszykujmy plik konfiguracyjny:
cd cf/cf cp generic-linux.mc sendmail.mc # jeżeli chcemy wycinać spamerów, dopuszczać relaying dla konretnych IP. cat ../feature/access_db.m4 >> sendmail.mc # jeżeli chcemy obsługiwać wirtualne domeny na naszym serwerze cat ../feature/virtusertable.m4 >> sendmail.mc # jeżeli chcemy aby nasz sendmail pracował jako zapasowy mx cat ../feature/mailertable.m4 >> sendmail.mc
Do pliku sendmail.mc dopisujemy:
define(`confAUTH_MECHANISMS',`LOGIN PLAIN')dnl TRUST_AUTH_MECH(`LOGIN PLAIN')dnl
Kompilujemy plik cf:
sh Build sendmail.cf sh Build install-cf killall -9 sendmail sendmail -bd -q15m
Te dwie ostatnie linijki to kolejno ubicie sendmaila i jego ponowne uruchomienie. Posiadacze redhatów, mandarynek i podobnych piszą grzecznie ‘/etc/rc.d/init.d/sendmail restart’ i widzą dwa ładne zielone napisy [ OK ].
Uwaga! Często po instalacji sendmaila możecie mieć problemy z dostępem do kolejki, tj, sendmail normalnie udostępnia relaying, wysyła pocztę ale np. nie działają programy mail czy tez pine. Problem tutaj leży w prawach dostępu do katalogów kolejki, binarki sendmaila i jego plików konfiguracyjnych. Powinny one wyglądać tak:
-r-xr-sr-x 1 root smmsp 584057 Oct 1 21:37 /usr/sbin/sendmail drwxrwx--- 2 smmsp smmsp 419 Dec 29 02:48 /var/spool/clientmqueue/ drwx------ 2 root wheel 35 Dec 29 02:48 /var/spool/mqueue/ -r--r--r-- 1 root wheel 55713 Dec 29 02:44 /etc/mail/sendmail.cf -r--r--r-- 1 root wheel 38707 Dec 29 02:42 /etc/mail/submit.cf
Więc jeżeli nie masz pewności co do praw dostępu do tych plików, po instalacji wykonaj:
chown root.smmsp /usr/sbin/sendmail chmod 2555 /usr/sbin/sendmail mkdir -p /var/spool/clientmqueue chown smmsp.smmsp /var/spool/clientmqueue chmod 770 /var/spool/clientmqueue chown root.wheel /var/spool/mqueue chmod 700 /var/spool/mqueue chown root.wheel /etc/mail/sendmail.cf chown root.wheel /etc/mail/submit.cf chmod 444 /etc/mail/sendmail.cf chmod 444 /etc/mail/submit.cf
Jeżeli w naszym systemie nie ma grupy ‘wheel’, spokojnie można użyć root.root.
Warto by było sprawdzić czy autoryzacja działa. Robimy coś takiego: printf ‘user\0user\0hasło’|mimencode, gdzie user i hasło to faktyczny login i hasło konta na serwerze:
$ printf 'lukasz\0lukasz\0ljm300fpqa'|mimencode bHVrYXN6AGx1a2FzegBsam0zMDBmcHFh $ telnet 0 25 Trying 0.0.0.0... Connected to 0. Escape character is '^]'. 220 home.baseciq.org ESMTP Sendmail 8.12.3/8.12.3; Fri, 13 Apr 2001 23:18:42 +0200 HELO localhost 250 home.baseciq.org Hello baseciq@localhost [127.0.0.1], pleased to meet you AUTH PLAIN bHVrYXN6AGx1a2FzegBsam0zMDBmcHFh 235 2.0.0 OK Authenticated QUIT 221 2.0.0 home.baseciq.org closing connection Connection closed by foreign host. $
I po bólu ;-). Na koniec warto przerobić pliki access i virtusertable. Byłbym zapomniał, jeżeli dorzucimy podczas tworzenia configa access_db.m4 i virtusertable.m4 to sendmail nie będzie chciał działać bez plikóe /etc/mail/access.db i /etc/mail/virtusertable.db. Jeżeli chcesz mieć te funckje na przyszłość, ale tymczasowo nie wiesz co do tych plików wpisać, to poprostu zostaw je puste / utwórz je komendą touch. Stworzenie nowych baz access i virtusertable wykonuje się tak:
cd /etc/mail rm access.db alises.db virtusertable.db /usr/sbin/makemap hash access < access /usr/sbin/makemap hash virtusertable < virtusertable /usr/bin/newaliases
aliases
Jest to plik z aliasami systemowymi, w formacie user: faktycznyuser. Np. root: baseciq – to oznacza że poczta na root’a niezależnie od domeny idzie na konto baseciq. Alias może wskazywać na inny alias, na przykład webmaster: root, a później root: user. Standardowo powinny być w tym pliku takie wpisy:
MAILER-DAEMON: postmaster postmaster: root # Przekierowania dla kont systemowych: bin: root daemon: root games: root ingres: root nobody: root system: root toor: root uucp: root # Powszechnie znane aliasy: manager: root dumper: root operator: root decode: root abuse: root # Osoba która powinna otrzymywać pocztę dla root'a. root: someuser
Po jego edycji należy uruchomić komendę ‘newalises’.
access
Plik ten dopuszcza bądź zabrania dostępu konkretnym hostom, domenom, adresom pocztowym do relayingu bądź dostępu do serwera. Może również dopuszczać konkretne domeny lub hosty do relayingu, ale po co kiedy właśnie przed chwilą zrobiłeś autoryzację ? :^). Przykładowy plik:
# dwie sieci lan - 192.168.1.* i 192.168.4.* mogą wysyłać przez nas pocztę 192.168.1 RELAY 192.168.4 RELAY # a ten oto pacjent nam wysyła jakiś spam: from:misiek72123@kki.net.pl ERROR:"550 We don't accept mail from spammers" # tutaj takie jedno sdi nam wysyła śmieci więc też je wytnijmy: px666.warszawa.sdi.tpnet.pl ERROR:"550 We don't accept mail from spammers" # o, właśnie Ci się przypomniało że z free.net.pl też są sami spamerzy, # więc wytnijmy ich domenę ;-) from:free.net.pl ERROR:"550 We don't accept mail from spammers"
Typów wpisów tutaj może być wiele, polecam więc lekture dokumentacji (ja sam tych wpisów dobrze nie znam). Po modyfikacji tego pliku generujemy ponownie bazę danych przy pomocy ‘makemap hash access < access’.
virtusertable
Cytuje za virtusertable.sample: Plik ten mapuje jednego lub wszystkich użytkowników z danej domeny do podanego (lub tego samego) użytkownika na innej maszynie. Pamiętaj o dodaniu danej domeny do /etc/mail/local-host-names aby sendmail akceptował pocztę dla danej domeny. Przykładowy plik wygląda tak:
# Poczta dla uzytkownik@przykladowa.domena.pl jest dostarczana # lokalnemuuzytkownikowi uzytkownik@przykladowa.domena.pl lokalnyuzytkownik # Poczta dla uzytkownik2@przykladowa.domena.pl jest przesylana # do ktostam@gdzies.pl uzytkownik2@przykladowa.domena.pl ktostam@gdzies.pl # cala poczta dla domeny cala.domena.pl trafia na konto lokalnyuser @cala.domena.pl lokalnyuser # poczta dla domeny inna.domena.pl jest przesylana do misio@gdzies.pl @inna.domena.pl misio@gdzies.pl # poczta dla domeny jeszcze.inna.pl jest forwardowana do takiego samego # uzytkownika w domenie tam.dalej.pl, np.: # jan.kowalski@inna.domena.pl jest przesylane do jan.kowalski@tam.dalej.pl @jeszcze.inna.pl %1@tam.dalej.pl
mailertable
Plik ten służy do informowania gdzie sendmail relayować pocztę dla konkretnych domen. Aby sendmail działał jako zapasowy mx, do access dopisujemy: ‘domena.pl RELAY’, oraz dopisujemy go do mailertable:
domena.pl SMTP:mx0.domena.pl
Ta linijka informuje sendmaila że pocztę adresowaną do domena.pl należy przekazać do hosta mx0.domena.pl. Równie dobrze można wpisać np. ‘SMTP:10.2.3.4′. Jak można to wykorzystać? Ustawiamy że podstawowym mxem dla domeny jest nasz serwer, a później go konfigurujemy żeby pocztę przesyłał do komputera w lanie. Oczywiście komputer w lanie musi mieć skonfigurowanego sendmaila lub inny demon pocztowy (np. Postfix, Qmail pod Linuxa, lub Mdaemon pod windows).
Uf… Pokręcone, prawda ? :^). Po modyfikacji tego pliku robimy ‘makemap hash virtusertable < virtusertable’. Uf. Done ;).
A teraz z pakietów…
Parę dni temu zostałem namówiony do instalacji u siebie PLD co uczyniłem i oczywiście odrazu na pierwszy rzut poszła instalacja podstawowych rzeczy z których musiałbym korzystać gdyby kiedyś mnie naszła ochota na postawienie serwera na tej dystybucji w pracy. Nie będę się rozpisywał o samej dystrybucji (slackware i tak rulez), która uważam jest jedną z lepszych i ciekawszych dystrybucji, a o samym sendmailu.
Spodziewałem się najgorszego, iż będę musiał kompilować przynajmniej sendmaila ale zostałem mile zaskoczony. Próba apt-get install sendmail poinformowała mnie grzecznie iż wymagany jest cyrus-sasl co z przyjełem z radością. Generalnie PLD jest wstępnie przygotowane do takowego zabiegu jak SMTP+AUTH a jedyne co trzeba to instalacja odpowiednich pakietów którymi są:
sendmail
cyrus-sasl
cyrus-sasl-login
cyrus-sasl-plain
cyrus-sasl-saslauthd (wymagany w przypadku sendmaila-8.12.9)
Po instalacji tych czterech pakietów pozostaje nam modyfikacja pliku /etc/mail/sendmail.mc.
Zamiast: TRUST_AUTH_MECH(`PLAIN GSSAPI KERBEROS_V4 DIGEST-MD5 CRAM-MD5') define(`confAUTH_MECHANISMS',`PLAIN GSSAPI KERBEROS_V4 DIGEST-MD5 CRAM-MD5') Musi być: TRUST_AUTH_MECH(`LOGIN PLAIN GSSAPI KERBEROS_V4 DIGEST-MD5 CRAM-MD5') define(`confAUTH_MECHANISMS',`LOGIN PLAIN GSSAPI KERBEROS_V4 DIGEST-MD5 CRAM-MD5')
Uwaga! Zmiany te były w potrzebne w czasach sendmaila 8.12.2 (o ile dobrze pamiętam) i w stabilnej wersji PLD-1.0-Ra zostały już przeze mnie wprowadzone.
Wpisy te znajdują się w okolicach 23 linijki tegoż pliku. Poprostu należy dodać LOGIN jako jeden z mechanizmów autoryzacji. Po dokonaniu zmian w pliku sendmail.mc generujemy nowe sendmail.cf:
m4 /etc/mail/sendmail.mc > /etc/mail/sendmail.cf
Po tych zabiegach pozostaje tylko wpisać /etc/rc.d/init.d/sendmail restart i korzystać.