Eigener Mailserver - Wie vorgehen?

[Dalai]

Hallo liebe Experten ,

ich hätte gerne mal wieder ein Problem . Folgende Situation: Firma hat eine Homepage und den Mailserver bei einem externen Anbieter, der Internetprovider ist T-Online. Das funktioniert auch wunderbar.

Aber eine Sache stört dabei massiv: wenn die Mitarbeiter der Firma Mails, die u.U. mit größeren Anhängen (Aufträge, Rechnungen u. dgl.) versehen sind, an andere Mitarbeiter schicken und/oder weiterleiten. Warum das stört, sollte klar sein: bei einer Weiterleitung müssen die Mails vom externen Anbieter abgeholt werden, dann wieder mit komplettem Anhang über den DSL-Anschluss versendet werden, um anschließend vom anderen Mitarbeiter erneut über den Anschluss gesaugt zu werden. Das nervt trotz mehrfacher Bemühungen, die versendenden Firmen zu kleinen Anhängen zu bewegen...

Nun haben wir uns gedacht, einen eigenen Mailserver auf dem bestehenden Ubuntu-Server einzurichten. Dabei stellen sich aber diverse Fragen und Probleme, über die ich noch nicht vollumfänglich Bescheid weiß, um das weitere Vorgehen zu planen:

• Kann man einen Mailserver prinzipiell an einem Anschluss mit dynamischer IP betreiben? In Zeiten von Spam ist das sicher nicht mehr so einfach... Ein DynDNS-Eintrag existiert natürlich, schon allein für die Fernwartung von außen.
• Welche Voraussetzungen sind in jedem Fall nötig? Ich habe bisher von MX-Records und solchen Sachen gelesen.
• Falls der komplett eigene Mailserver nicht realisierbar ist: Kann man den Mailserver so betreiben, dass alle internen Mails intern bleiben und alles, was nach draußen geschickt werden soll, an den bestehenden externen Mailserver "weiterleiten"?
• Gibt's andere Möglichkeiten? Wie würdet ihr die Sache angehen?

Wenn die vorgenannten Fragen geklärt sind, hab ich sicher noch weitere, nicht zuletzt nach den entsprechenden Softwarepaketen (Postfix ist vorhanden und fungiert schon als lokaler Mailserver).

MfG Dalai

 

[ghostadmin]

Das ist alles kein Problem, Kann man auch manuell einrichten aber dauert dann eben länger.

Den Provider nutzt man als Relay Agent da andere Mailserver die Mails sonst ablehnen würden, wegen Spam.

Die Mails holt man sich normal per POP3 z.B. fetchmail auf den Postfix.

Und dann braucht man noch was wie Dovecot oder Cyrus für IMAP damit die Clients darauf zugreifen können und auch Webmail geht mit z.B. Squirrel

Problematisch wirds bei kostenlos eigentlich nur wenn man unbedingt Outlook haben möchte, was ja einige leider vorraussetzen.

 

[Dalai]

Das ist alles kein Problem, Kann man auch manuell einrichten aber dauert dann eben länger.

Wie lange das Einrichten dauert, ist mir egal, solange wir das verstehen, um es zu konfigurieren . Was dabei aber keinesfalls passieren darf, ist eine Beeinflussung der existierenden Mailerei, denn davon hängen Aufträge ab usw.

Den Provider nutzt man als Relay Agent da andere Mailserver die Mails sonst ablehnen würden, wegen Spam.

D.h. man müsste bei der Telekom schauen, dass man dort sowas aktiviert? Bieten die das an?

Die Mails holt man sich normal per POP3 z.B. fetchmail auf den Postfix.

Mmh. Das bedeutet dann aber eine zusätzliche "Verzögerung", weil ein weiterer Mailserver dazwischengeschaltet wird, sehe ich das richtig? Mit Verzögerung meine ich, dass man ja nur in einem bestimmten Intervall Mails abholen kann/darf, um die Server nicht unnötig oft bzw. ununterbrochen zu kontaktieren. Die Mailclients wiederum holen sich die Mails ebenfalls in Intervallen ab.

Und dann braucht man noch was wie Dovecot oder Cyrus für IMAP damit die Clients darauf zugreifen können und auch Webmail geht mit z.B. Squirrel

Darüber machen wir uns noch Gedanken, weil noch nicht klar ist, ob intern POP3 genügt oder IMAP zwingend ist. Webmail halte ich zumindest momentan für nicht unbedingt notwendig.

Problematisch wirds bei kostenlos eigentlich nur wenn man unbedingt Outlook haben möchte, was ja einige leider vorraussetzen.

Kostenlos muss es nicht sein. Es sollte kein Problem sein, für entsprechende Dienste (feste IP oder Relay oder sonstwas) einen kleinen Betrag zu bezahlen. Aber Outlook gibt's bei uns nicht, nur Thunderbird .

MfG Dalai

 

[ghostadmin]

D.h. man müsste bei der Telekom schauen, dass man dort sowas aktiviert? Bieten die das an?

Nö das sollte auch so gehen. Ist ja im Prinzip nix anderes das sich der Mailserver als Client ausgibt. Ist nur ziemliches gefummel mit SSL, TLS etc. und es gibt auch unterschiedliche Konfigurationen bei der Anmeldung je nach Provider. Da muss man oft rumprobieren bis es geht.
Es gibt manche Groupware unter Linux die z.B. mit Google nicht funktioniert, weil die sich nicht an Standards halten (wegen HELO).

Mmh. Das bedeutet dann aber eine zusätzliche "Verzögerung", weil ein weiterer Mailserver dazwischengeschaltet wird, sehe ich das richtig? Mit Verzögerung meine ich, dass man ja nur in einem bestimmten Intervall Mails abholen kann/darf, um die Server nicht unnötig oft bzw. ununterbrochen zu kontaktieren. Die Mailclients wiederum holen sich die Mails ebenfalls in Intervallen ab.

Man könnte das auch einstellen das der Mailserver es jede Minute abholt. Per SMTP geht halt nicht ...
Es gibt noch andere Protokolle die über den Provider einen Push machen würden (mir ist der Name entfallen) aber für Free gibts das wohl nicht.

Darüber machen wir uns noch Gedanken, weil noch nicht klar ist, ob intern POP3 genügt oder IMAP zwingend ist. Webmail halte ich zumindest momentan für nicht unbedingt notwendig.

IMAP hat eben den Vorteil das die Mails default auf dem Server bleiben und man Ordner anlegen kann. Beispiel: Ein User hat 2 Geräte und stellt beide auf POP3 ein und wundert sich dann warum die Mails nur auf einem Gerät ankommen.

Kostenlos muss es nicht sein. Es sollte kein Problem sein, für entsprechende Dienste (feste IP oder Relay oder sonstwas) einen kleinen Betrag zu bezahlen. Aber Outlook gibt's bei uns nicht, nur Thunderbird .

MfG Dalai

Solange es nur IMAP oder POP3 ist, geht alles. Nur wenn man Terminverwaltung oder Kalender gemeinsam verwenden will, dann wirds aufwendiger.

 

[Dalai]

Ich fasse mal zusammen, wie ich es bisher verstanden habe:

1. Bei einem eigenen Mailserver, der den bisher genutzten externen Mailserver außen vor lässt, braucht man eine feste IP und einen MX Record (und ggf. sogar einen MX Reverse Record). Zusätzlich muss man den Mailserver absichern, weil Port 25 (SMTP) nach außen offen sein muss.
2. Bei einem eigenen Mailserver, der die Mails vom externen Mailserver abholt und nur die firmenintern verschickten Mails selbst behandelt und den Rest nach außen weiterleitet, braucht man weder eine feste IP noch einen MX Record, dafür aber eine Software, die die Mails in Intervallen vom externen Mailserver abholt.

Ist das bisher richtig?

Ausgehend von Szenario 2, welche Software ist dann notwendig für welchen Zweck?

• Postfix für die Annahme der internen Mails von den Clients via SMTP. Kann der auch die Mails nach außen senden oder macht das ein anderer Daemon?
• fetchmail oder getmail für's Abholen der Mails vom externen Mailserver via POP3.
• Dovecot, um POP3/IMAP für die Clients zur Verfügung zu stellen.

Und auf welcher Basis arbeiten diese Daemons zusammen? In diesem Tutorial wird MySQL benutzt. Der ist zwar bei uns vorhanden, aber irgendwie hab ich Zweifel daran, dass es sinnvoll wäre, Mails in einer Datenbank zu speichern (der existierende Postfix speichert die Mails im mbox-Format).

Wieviel Mehraufwand ist es, einen Spamfilter zu integrieren? Welchen sollte man benutzen? An welcher Stelle sollte man den einbinden?

MfG Dalai

 

[PuckPoltergeist]

Ich fasse mal zusammen, wie ich es bisher verstanden habe:

1. Bei einem eigenen Mailserver, der den bisher genutzten externen Mailserver außen vor lässt, braucht man eine feste IP und einen MX Record (und ggf. sogar einen MX Reverse Record). Zusätzlich muss man den Mailserver absichern, weil Port 25 (SMTP) nach außen offen sein muss.
2. Bei einem eigenen Mailserver, der die Mails vom externen Mailserver abholt und nur die firmenintern verschickten Mails selbst behandelt und den Rest nach außen weiterleitet, braucht man weder eine feste IP noch einen MX Record, dafür aber eine Software, die die Mails in Intervallen vom externen Mailserver abholt.

Ist das bisher richtig?

passt soweit

Ausgehend von Szenario 2, welche Software ist dann notwendig für welchen Zweck?

• Postfix für die Annahme der internen Mails von den Clients via SMTP. Kann der auch die Mails nach außen senden oder macht das ein anderer Daemon?
• fetchmail oder getmail für's Abholen der Mails vom externen Mailserver via POP3.
• Dovecot, um POP3/IMAP für die Clients zur Verfügung zu stellen.

Und auf welcher Basis arbeiten diese Daemons zusammen? In diesem Tutorial wird MySQL benutzt. Der ist zwar bei uns vorhanden, aber irgendwie hab ich Zweifel daran, dass es sinnvoll wäre, Mails in einer Datenbank zu speichern (der existierende Postfix speichert die Mails im mbox-Format).

Postfix (oder ein anderer MTA deine Wahl) ist für die gesamte Mailzustellung verantwortlich. Deshalb heißen die ja Mail Transfer Agent. Sie nehmen die Mails entgegen und leiten sie weiter. Die Richtung ist dabei egal.
Und die Mails werden nicht in einer Datenbank gespeichert, sondern die Konfiguration. Das geht bei den Nutzerdaten los (username, password), und erstreckt sich auch über Dinge, wie die Mailzustellung, sprich welchen Mail wohin geleitet wird. Alternativ kann man das auch über Datei-basierte Konfigurationen machen oder über LDAP.

Wieviel Mehraufwand ist es, einen Spamfilter zu integrieren? Welchen sollte man benutzen? An welcher Stelle sollte man den einbinden?

Hält sich in Grenzen, da das schon konzeptionell beim MTA vorgesehen ist. Nennt sich amavis: http://www.ijs.si/software/amavisd/
und dient generell zur Einbindung von zusätzlicher Filter-Software wie z.B. auch Virenscanner.

 

[Rones]

Ich hoffe ich verwirre Dich jetzt nicht mit folgendem Beitrag:

Wenn Du Dein Szenario 2 einmal soweit geübt und lauffähig hast kannst Du Dich danach vielleicht auch noch an das erste Szenario wagen, wenn Deine Firma mal mit einem festen externen IP-Adresspool (1 oder mehrere) ausgestattet sein sollte. Vielleicht helfen Dir die Anleitungen unter folgender Adresse auch weiter:

http://www.heinlein-support.de/blog/howto/tutorial-robuste-mailserver-einrichten/

Die Tipps da drin sind auf jeden Fall sehr hilfreich für das Verständnis um die Verantwortung, die man beim Konfigurieren eines von außen erreichbaren MTAs hat.

 

[Dalai]

Und die Mails werden nicht in einer Datenbank gespeichert, sondern die Konfiguration.

Stimmt, jetzt wo, du's sagst, seh ich's auch .

Alternativ kann man das auch über Datei-basierte Konfigurationen machen oder über LDAP.

Da LDAP eh vorhanden ist, wird der natürlich mit eingebunden. Also kann MySQL außen vor bleiben für diesen Zweck.

Hält sich in Grenzen, da das schon konzeptionell beim MTA vorgesehen ist. Nennt sich amavis: http://www.ijs.si/software/amavisd/
und dient generell zur Einbindung von zusätzlicher Filter-Software wie z.B. auch Virenscanner.

D.h. ein SpamAssassin kann nicht direkt mit dem Postfix quatschen sondern muss über eine solche Schnittstelle gehen? Virenscanner lass ich erstmal weg, denn der externe Mailserver wird wahrscheinlich sowas haben und bislang ist der sowieso der einzige benutzte Mailserver und Probleme mit Viren hatten wir auf diesem Weg AFAIK noch keine.

Mal noch eine andere Frage:

• Manchmal verschicken "äußerst kompetente" Mitarbeiter anderer Firmen Mails mit Anhängen in Größenordnungen, bei denen man sich nur an den Kopf greifen kann (20 MB hatten wir schon IIRC). Kann man dem Mailserver beibringen, bei solchen Vorfällen die Mail abzuweisen und eine Benachrichtigung an den Absender zu schicken mit einem definierbaren Inhalt (Bitte um Verkleinerung des Anhangs)? Momentan geht's mir erstmal nur um das Ob, nicht um das Wie.

Ich hoffe ich verwirre Dich jetzt nicht mit folgendem Beitrag:

Nö, noch mehr Verwirrung ist kaum möglich . Ich denke, Szenario 1 mit fester IP liegt erstmal in weiter Ferne, aber danke dir für den Input!


Wir werden in jedem Fall innerhalb der kommenden Wochen mal mit dem Betreiber des derzeitigen externen Mailservers (die heißen PWD) reden, um allgemeine und hoffentlich auch konkrete Tips - neben diesem Thread hier - zu bekommen. Ich denke, dann können wir uns ein umfassenderes Bild machen, wie was zusammenspielt und wie vorzugehen ist. Bisher war Mail einfach Mailserver und -Client und fertig . Insofern wird man von den MTAs, MRAs, MUAs & MDAs erstmal erschlagen...

MfG Dalai

 

[ghostadmin]

D.h. ein SpamAssassin kann nicht direkt mit dem Postfix quatschen sondern muss über eine solche Schnittstelle gehen? Virenscanner lass ich erstmal weg, denn der externe Mailserver wird wahrscheinlich sowas haben und bislang ist der sowieso der einzige benutzte Mailserver und Probleme mit Viren hatten wir auf diesem Weg AFAIK noch keine.

Doch, Amavis wird direkt in Postfix in die master.cf eingetragen und fängt dann alles ab. Allerdings ist SpamAssassin und Clamav nicht gerade sehr wirkungsvoll, man könnte aber noch weitere Scanner eintragen. Auch ratsam ist es in apt eine source einzutragen die regelmäßig die neuesten updates liefert.

[*]Manchmal verschicken "äußerst kompetente" Mitarbeiter anderer Firmen Mails mit Anhängen in Größenordnungen, bei denen man sich nur an den Kopf greifen kann (20 MB hatten wir schon IIRC). Kann man dem Mailserver beibringen, bei solchen Vorfällen die Mail abzuweisen und eine Benachrichtigung an den Absender zu schicken mit einem definierbaren Inhalt (Bitte um Verkleinerung des Anhangs)? Momentan geht's mir erstmal nur um das Ob, nicht um das Wie.

Man kann nur die Message Size begrenzen z.B. in Postfix. Man könnte auch in Amavis einstellen das bestimmte Dateiendungen verboten sind und vieles mehr.

 

[Dalai]

Update

Da wir bei der Umstellung des DSL-Anschlusses feststellten, dass im neuen Vertrag sogar schon eine feste IP enthalten ist (TDSL Business irgendwas), haben wir uns entschieden, den Server in diese Richtung einzurichten. Vom Erfolg dessen hängt es ab, ob das weiter verfolgt wird. Momentan sehe ich dabei aber keine großen Schwierigkeiten, denn der Betreiber des derzeitigen Mailservers hat Unterstützung in der Richtung zugesagt.

Ich bin inzwischen so weit, dass das Verschicken von Mails klappt. Nun aber zum Problem: ich möchte in der Lage sein, systeminterne Mails ebenso verschicken und empfangen zu können wie externe Mails. Mir ist noch nicht klar, welche Konfigurationsoptionen dies bestimmen. Bisher habe ich folgende Konfig:

smtpd_banner =          $myhostname ESMTP
biff =                  no
append_at_myorigin =    yes
append_dot_mydomain =   no
alias_maps =            hash:/etc/aliases
alias_database =        hash:/etc/aliases

myorigin =              /etc/mailname
myhostname =            mail.domain.biz
mydomain =              mail.domain.biz
mydestination =         $myhostname, $mydomain, localhost.$mydomain, localhost
mynetworks =            127.0.0.0/8

home_mailbox =          Mail/
mailbox_command =       /usr/bin/procmail -t

In der Konfig sind noch ein paar Optionen angegeben bzgl. SMTP und SMTPD, aber ich gehe davon aus, dass die bzgl. des Problems keine Rolle spielen.

Hat jemand mehr Ahnung (oder besser gesagt Wissen) als ich?

MfG Dalai

 

[ghostadmin]

Alias machen für root auf einen user in deiner internen Domäne

 

[Dalai]

Es geht mir nicht um root sondern wirklich um lokale Mails "aller" User. Konkret gibt es einen Nutzer wartung, der bei der Installation angelegt wurde (mit UID 1000) und alle Mails an root gehen an eben diesen Nutzer wartung; es gibt also schon einen Alias, wie ein Blick in /etc/aliases verrät:

# Added by installer for initial user
root:   wartung

Nun möchte ich in der Lage sein, die Mails auch zu lesen wie bisher. D.h. ein Senden einer Mail an "wartung" soll lokal bleiben ("wartung@localhost" natürlich ebenfalls), alles andere aber soll nach außen geschickt werden. Es geht mir also um die (Mail-)Domäne. Aber ich sage gleich dazu: ich muss in der Lage sein, Mails an lokale User an eine externe Adresse weiterzuleiten.

Ich drück's nochmal anders aus und betrachte es von einer anderen Seite. Mit obiger Konfig konnte ich bereits eine Mail an "wartung@localhost" schicken, sagt jedenfalls das /var/log/mail.log. Die Mail selbst ist sogar in /home/wartung/Mail/new zu finden. Aber abholen kann ich sie nicht, die Eingabe von "mail" sagt, es wäre keine neue Mail vorhanden. Zusatzfrage: lassen sich die Konten "wartung@localhost" und "wartung@domain.biz" überhaupt trennen oder landen die gezwungenermaßen im/beim selben Konto/Nutzer?

MfG Dalai

 

[mj]

Realisierbar ist das durchaus, aber es erfordert ein wenig Verständnis von Mailtransport und vor allem des Ungetüms postfix

Wenn ich es richtig verstanden habe willst du E-Mails an wartung und wartung@domain.biz zustellen, die jedoch unterschiedliche Konten sind. Das dürfte sich über die Direktive append_dot_mydomain lösen lassen. Zur Erklärung: $mydomain ist die Variable in der die Domain der postfix-Instanz festgelegt wird, im Beispiel also domain.biz. Postfix weiß, dass es für diese Domain zuständig ist, da $mydomain in der Variable $mydestination enthalten ist und postfix somit angewiesen ist, Mails an diese Domain anzunehmen. Die Direktive append_dot_mydomain, die standardmäßig auf "yes" steht, fügt beim Absenden einer Mail an "wartung" automatisch "@$mydomain", also im Beispiel "@domain.biz" an. Postfix merkt, dass es selbst dafür zuständig ist und die Zustellung erfolgt lokal.

Wenn du dies nicht wünscht und eine Trennung von wartung und wartung@domain.biz willst, musst du die Direktive append_dot_mydomain entsprechend ändern.

 

[ghostadmin]

Postfix arbeitet nicht mit localhost, dass geht alles an die Maildomain.

Edit: Den append_dot_mydomain hätte er ja schon disabled. In meiner Config steht der auf yes aber ich habe von root trotzdem noch mails drin wenn ich "mail" eingebe. Ich denke man darf einfach keinen alias auf root setzen, sonst landet alles in der Domain.
Ich habe nur Virtualuser in Mysql, da ist es nicht mal möglich das da Root mails drin landen die nicht an die Domäne andressiert sind.

 

[Dalai]

Wenn ich es richtig verstanden habe willst du E-Mails an wartung und wartung@domain.biz zustellen, die jedoch unterschiedliche Konten sind.

Es sollen unterschiedliche Mailkonten sein, richtig. Der Sinn dahinter ist, dass ich z.B. Mails von Munin nicht unbedingt extern zustellen muss, Mails vom erfolgreichen oder gescheiterten Backup aber schon. Die Mails von Munin sind größtenteils nicht zeitkritisch (es macht also nichts, wenn die ein paar Tage nicht lokal gelesen werden), ein gescheitertes Backup hingegen schon.

Das dürfte sich über die Direktive append_dot_mydomain lösen lassen. Zur Erklärung: $mydomain ist die Variable in der die Domain der postfix-Instanz festgelegt wird, im Beispiel also domain.biz. Postfix weiß, dass es für diese Domain zuständig ist, da $mydomain in der Variable $mydestination enthalten ist und postfix somit angewiesen ist, Mails an diese Domain anzunehmen. Die Direktive append_dot_mydomain, die standardmäßig auf "yes" steht, fügt beim Absenden einer Mail an "wartung" automatisch "@$mydomain", also im Beispiel "@domain.biz" an. Postfix merkt, dass es selbst dafür zuständig ist und die Zustellung erfolgt lokal.

Soweit habe ich das bisher auch verstanden.

Wenn du dies nicht wünscht und eine Trennung von wartung und wartung@domain.biz willst, musst du die Direktive append_dot_mydomain entsprechend ändern.

Die Option steht ja bereits auf "no". Der Versand klappt laut Log, die Mail ist im Mail-Verzeichnis zu finden, aber abholen und lesen kann ich sie nicht - und ich weiß nicht, warum das so ist.

Ich kann nur sagen, dass der Postfix zum Installationszeitpunkt als "Local only" eingerichtet wurde und nachträglich umkonfiguriert wird (geht auch nicht anders, weil auf dem Produktivsystem dieselbe Situation herrscht). Außerdem liegen die Mails der "Local only" Config an anderer Stelle (/var/mail/wartung) und in einer einzelnen Datei, während die neue Config die Mails in /home/wartung/Mail ablegt mit einer Mail pro Datei.

MfG Dalai

 

[Emploi]

In der c't 2012, Heft 3 ist auch ein ausführlicher Artikel zur Problematik.

 

[Dalai]

Danke für den Hinweis. Ich werd mir das mal anschauen. Allerdings sieht es danach aus, als wären in erster Linie die allgemeinen Dinge erklärt, wenn ich mir das Inhaltsverzeichnis so anschaue:

Wege zur eigenen Mail-Domain - Seite 102
Mailserver unter Windows einrichten - Seite 108
Rechtlicher Rahmen für private Mailserver - Seite 112

Und ein Mailserver unter Windows kommt schon gar nicht in Frage . Dennoch werde ich mir den Artikel mal durchlesen, ggf. sind die rechtlichen Aspekte ebenfalls wichtig und/oder interessant.

MfG Dalai

 

[mj]

Die Option steht ja bereits auf "no". Der Versand klappt laut Log, die Mail ist im Mail-Verzeichnis zu finden, aber abholen und lesen kann ich sie nicht - und ich weiß nicht, warum das so ist.

Ich kann nur sagen, dass der Postfix zum Installationszeitpunkt als "Local only" eingerichtet wurde und nachträglich umkonfiguriert wird (geht auch nicht anders, weil auf dem Produktivsystem dieselbe Situation herrscht). Außerdem liegen die Mails der "Local only" Config an anderer Stelle (/var/mail/wartung) und in einer einzelnen Datei, während die neue Config die Mails in /home/wartung/Mail ablegt mit einer Mail pro Datei.

Das klingt dann nach einer geänderten Zustellung. Postfix nimmt die E-Mail zwar entgegen, übergibt sie dann aber standardmäßig an postdrop, alternativ maildrop, lmtp, etc. Diese Einstellung findet sich in der Datei master.cf, wobei ich mir gerade nicht zu 100% sicher bin inwiefern die main.cf da mit reinspielt. Vielleicht verstehe ich das Problem ja auch noch nicht so ganz

 

[Dalai]

In der master.cf habe ich auch Änderungen vorgenommen, ja. Ich habe eine Zeile der "Standardkonfig" (also die der "Local only") geändert, glaube aber nicht, dass es daran liegt. Anyway, hier die komplette master.cf:

#
# Postfix master process configuration file.  For details on the format
# of the file, see the master(5) manual page (command: "man 5 master").
#
# Do not forget to execute "postfix reload" after editing this file.
#
# ==========================================================================
# service type  private unpriv  chroot  wakeup  maxproc command + args
#               (yes)   (yes)   (yes)   (never) (100)
# ==========================================================================
smtp      inet  n       -       n       -       -       smtpd
#submission inet n       -       -       -       -       smtpd
#  -o smtpd_tls_security_level=encrypt
#  -o smtpd_sasl_auth_enable=yes
#  -o smtpd_client_restrictions=permit_sasl_authenticated,reject
#  -o milter_macro_daemon_name=ORIGINATING
#smtps     inet  n       -       -       -       -       smtpd
#  -o smtpd_tls_wrappermode=yes
#  -o smtpd_sasl_auth_enable=yes
#  -o smtpd_client_restrictions=permit_sasl_authenticated,reject
#  -o milter_macro_daemon_name=ORIGINATING
#628      inet  n       -       -       -       -       qmqpd
pickup    fifo  n       -       -       60      1       pickup
cleanup   unix  n       -       -       -       0       cleanup
qmgr      fifo  n       -       n       300     1       qmgr
#qmgr     fifo  n       -       -       300     1       oqmgr
tlsmgr    unix  -       -       -       1000?   1       tlsmgr
rewrite   unix  -       -       -       -       -       trivial-rewrite
bounce    unix  -       -       -       -       0       bounce
defer     unix  -       -       -       -       0       bounce
trace     unix  -       -       -       -       0       bounce
verify    unix  -       -       -       -       1       verify
flush     unix  n       -       -       1000?   0       flush
proxymap  unix  -       -       n       -       -       proxymap
proxywrite unix -       -       n       -       1       proxymap
smtp      unix  -       -       -       -       -       smtp
# When relaying mail as backup MX, disable fallback_relay to avoid MX loops
relay     unix  -       -       -       -       -       smtp
        -o smtp_fallback_relay=
#       -o smtp_helo_timeout=5 -o smtp_connect_timeout=5
showq     unix  n       -       -       -       -       showq
error     unix  -       -       -       -       -       error
retry     unix  -       -       -       -       -       error
discard   unix  -       -       -       -       -       discard
local     unix  -       n       n       -       -       local
virtual   unix  -       n       n       -       -       virtual
lmtp      unix  -       -       -       -       -       lmtp
anvil     unix  -       -       -       -       1       anvil
scache    unix  -       -       -       -       1       scache
#
# ====================================================================
# Interfaces to non-Postfix software. Be sure to examine the manual
# pages of the non-Postfix software to find out what options it wants.
#
# Many of the following services use the Postfix pipe(8) delivery
# agent.  See the pipe(8) man page for information about ${recipient}
# and other message envelope options.
# ====================================================================
#
# maildrop. See the Postfix MAILDROP_README file for details.
# Also specify in main.cf: maildrop_destination_recipient_limit=1
#
maildrop  unix  -       n       n       -       -       pipe
  flags=DRhu user=vmail argv=/usr/bin/maildrop -d ${recipient}
#
# See the Postfix UUCP_README file for configuration details.
#
uucp      unix  -       n       n       -       -       pipe
  flags=Fqhu user=uucp argv=uux -r -n -z -a$sender - $nexthop!rmail ($recipient)
#
# Other external delivery methods.
#
ifmail    unix  -       n       n       -       -       pipe
  flags=F user=ftn argv=/usr/lib/ifmail/ifmail -r $nexthop ($recipient)
bsmtp     unix  -       n       n       -       -       pipe
  flags=Fq. user=bsmtp argv=/usr/lib/bsmtp/bsmtp -t$nexthop -f$sender $recipient
scalemail-backend unix  -       n       n       -       2       pipe
  flags=R user=scalemail argv=/usr/lib/scalemail/bin/scalemail-store ${nexthop} ${user} ${extension}
mailman   unix  -       n       n       -       -       pipe
  flags=FR user=list argv=/usr/lib/mailman/bin/postfix-to-mailman.py
  ${nexthop} ${user}

Die Änderung ist in Zeile 11, dort wurde für smtp in der Spalte chroot ein "n" gesetzt.

MfG Dalai

 

[Dalai]

Ich habe soeben herausgefunden, woran es liegt, dass die Mails woanders landen (durchaus gewünscht) und nicht mittels "mail" abgerufen werden können (nicht gewünscht): die Konfig von procmail ist dafür verantwortlich, konkret ist es

DEFAULT=$HOME/Mail/

in /etc/procmailrc. Kommentiere ich die Zeile aus, kommen die Mails in /var/mail/wartung rein und werden nach Abrufen nach /home/wartung/mbox geschrieben.

Kann das Kommando "mail" überhaupt mit "qmail-style delivery" umgehen, wie es so schön in der Manpage zu postconf(5) steht? Im Moment sind mir die Zusammenhänge noch nicht klar.

MfG Dalai

 

[Herr Rossi]

Beim Betrieb eines eigenen Mail-Servers ohne Relay solltest du evtl. noch ein paar Dinge berücksichtigen, die über die Grundkonfiguration hinaus gehen. Zwar ist die feste IP schon mal ein guter Ansatz, jedoch muss man meiner Erfahrung nach mittlerweile leider noch ein wenig mehr Aufwand treiben, um mit einem selbst betriebenem Mail-Server bei den Empfängern nicht im Spam-Ordner zu landen.
Ohne Domainkey Einträge im DNS lande ich z.B. mit meinem Server mittlerweile bei fast allen Freemailern im Spam-Ordner.
Infos dazu kannst du hier nachlesen http://de.wikipedia.org/wiki/DomainKeys
Die genaue Implementierung hängt von dem von dir benutztem Mailserver ab.
Generell sehr wichtig sind natürlich sowieso die DNS Einträge.
Um deinen Mail-Server auf "Spam-Kompatibilität" zu testen würde ich dir empfehlen einfach mal bei den üblichen Freemailern (gmx, yahoo, msn, web.de, etc.) eine Mail-Adr. einzurichten und zu schauen ob die Mails dort durchkommen.

 

[Emploi]

Bringt eigentlich dieses SPF in der Beziehung was?

 

[Herr Rossi]

Ich habe es auch aktiv, aber soweit ich das beurteilen kann bringt Domainkeys mehr. Es ist aber sicherlich nicht verkehrt beides zu integrieren.
Bei Yahoo landeten meine Mails ohne beides noch nicht einmal im Spam-Ordner, sondern wurden scheinbar komplett gelöscht. Wobei ich sagen muss, dass das schon für ein sehr bescheidenes Filtersystem spricht... nur was hilft es dir, denn Yahoo wird sicherlich nicht für irgend welche selbst betriebenen kleinen Mail-Server irgend etwas umstellen.

 

[Dalai]

Ohne Domainkey Einträge im DNS lande ich z.B. mit meinem Server mittlerweile bei fast allen Freemailern im Spam-Ordner.

Um diesen Kram brauche ich mich nicht zu kümmern, weil der DNS-Eintrag für diese IP-Adresse bzw. der Name weiterhin beim bisherigen Betreiber des Mailservers bleibt, d.h. ich habe keinen DNS-Server zu ändern sondern nur den Mailserver selbst aufzusetzen.

Momentan sieht es auch sehr gut aus, ich bin schon recht weit gekommen. Das Senden und Empfangen funktioniert intern einwandfrei, sogar mir SSL-Verschlüsselung (bzw. TLS, um genau zu sein). Das Schicken nach außen funktioniert ebenfalls (auch an meine eigene GMX-Adresse), ob das Empfangen von außen funktioniert, wird sich noch zeigen (da gabs vorhin noch ein kleines Konfigurationsproblem).

SPF ist übrigens mit einbezogen und genau jenes hatte besagtes Konfigproblem .

MfG Dalai

 

[Herr Rossi]

Das klingt ja schon mal sehr gut. Ich würde aber zur Sicherheit dennoch bei anderen Freemailern einen Account einrichten und dort noch mal testen. Wenn die Mails dort durchkommen, dann kann man dir wohl zur erfolgreichen Einrichtung gratulieren!