Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Welche Mailserver für Linux? (POP3 und SMTP)

2 views
Skip to first unread message

Mike Pfaff

unread,
Sep 8, 2001, 12:37:37 PM9/8/01
to
Hallo zusammen

Ich bin gerade daran, einen Internet-Server aufzusetzen. Das klappte
eigentlich alles problemlos, nur die Mailserver-Wahl und besonders die
Konfiguration treibt mich noch zum Wahnsinn. Nach etlichen Stunden des Suchens
habe ich noch keine gute Lösung gefunden. Insbesondere fehlt es an
Dokumentationen, welche sich nicht nur stur auf eine Software beschränken,
sondern auch auf das Zusammenspiel von POP3-Server und SMTP-Server eingehen.

Anforderungen:
- Einfach und intuitiv zu installieren(Wenn möglich .deb) und konfigurieren
(Dies ist wohl die wichtigste Anforderung)
- Keine Verwendung von UNIX-Usern(*) oder /etc/passwd, da sich sowieso kein
Normal-User auf dem Server einloggen kann (Dies sollte ohne Patches oder
komplizierte Zusatz-Software möglich sein)
- Gut dokumentiert (Gute HOWTOs sind mir da besonders wichtig, denn was nützt
mir eine Riesen-Doku die einfach stupid alle möglichen und unmöglichen
Konfigurationsparameter alphabetisch auflistet)
- Mailversand vom Localhost aus möglich(Für Perl-Skripts, etc.)
- Catch-All einfach einzurichten(Bis auf wenige Ausnahmen gehen alle Mails an
mich)
- Falls möglich kostenlos

Die Ideal-Lösung sieht so aus:

SMTP-Config(Neben den wenigen globalen Einstellungen):
us...@domain1.xy mailbox1
us...@domain1.xy mailbox2
us...@domain1.xy mailbox3
*@domain1.xy mailbox4
us...@domain2.xy mailbox3
us...@domain2.xy mailbox3
us...@domain2.xy mailbox1
*@domain2.xy mailbox4

POP3-Config:
mailbox1 username1 passwort1
mailbox2 username2 passwort2
mailbox3 username3 passwort3
mailbox4 username4 passwort4

Kennt hier jemand eine Lösung oder kann mir mit guten Dokumentations-Links
weiterhelfen.

Vielen Dank im voraus,

Mike Pfaff

(*) = Selbstverständlich brauchen die Server-Prozesse einen User, aber das ist
mit der Anforderung ja auch nicht gemeint.

tarzeau

unread,
Sep 8, 2001, 1:38:45 PM9/8/01
to
hi

ich benütz exim und qpopper

(apt-get install qpopper exim)
(harden-doc is noch gut zum lesen so..)

gruss
tarzeau / www.linuks.mine.nu

--
Windoze not found: (C)heer, (P)arty or (D)ance?

Philip Hofstetter

unread,
Sep 8, 2001, 1:48:30 PM9/8/01
to
Hallöchen

<werbung>
http://www.pilif.ch/mail.txt (der verwendete IMAP-Server kann auch
POP3)
</werbung>

Mike Pfaff wrote:

>Anforderungen:
>- Einfach und intuitiv zu installieren(Wenn möglich .deb) und konfigurieren
>(Dies ist wohl die wichtigste Anforderung)

zwar kein .deb, aber einzelne Komponenten davon solltest Du in
.deb-Form finden.

>- Keine Verwendung von UNIX-Usern(*) oder /etc/passwd, da sich sowieso kein
>Normal-User auf dem Server einloggen kann (Dies sollte ohne Patches oder
>komplizierte Zusatz-Software möglich sein)

User sind in MySQL-Datenbank (du kanns hier auch problemlos ein
Flat-File verwenden, musst dann aber wieder etwas selbst
programmieren). Patches sind keine nötig; zusatz-Software ist in Perl
geschrieben und ausreichend dokumentiert.

>- Gut dokumentiert (Gute HOWTOs sind mir da besonders wichtig, denn was nützt
>mir eine Riesen-Doku die einfach stupid alle möglichen und unmöglichen
>Konfigurationsparameter alphabetisch auflistet)

Ob meine Doku gut ist, oder nicht, das sei Dir überlassen. Ich denke,
sie sollte auch Anfänger-Tauglich sein und geht genau auf das
Wesentliche ein. Plus: Sie ist deutsch (ist auch ihr grösster
Nachteil).

>- Mailversand vom Localhost aus möglich(Für Perl-Skripts, etc.)

Das geht immer.

>- Catch-All einfach einzurichten(Bis auf wenige Ausnahmen gehen alle Mails an
>mich)

Kein Problem. Seit version 1.11 der Dokumentation

>- Falls möglich kostenlos

Naja... Du könntest mir, wenn ich es denn trinken würde, einen Kasten
Bier zusenden :-)

Viel Spass beim durchlesen...

Um nicht einseitig zu wirken: http://www.inter7.com/vpopmail reicht
vielleicht für dich bereits aus; allerdings konnte ich das trotz Doku
nicht wirklich schnell installieren[1]; ganz im Gegensatz zu meinem
eigenen System.

Philip
1) vor allem qmail war mir zu umständlich und dann hat der normale
Kompilier-Vorgang noch nicht so recht geklappt. Anstatt vpopmail zu
flicken habe ich dann "halt" meine eigene Lösung erstellt; vor allem,
weil ich Exim so mag.

--
Wörter auf die der Regex funzt[sz]? passt sind weder deutsch,
noch neudeutsch noch irgendetwas anderes als lächerlich und
haben in einem kultivierten Medium wie dem Usenet nichts
verloren. Du willst "funktioniert" sagen. Sag' das auch.

Thomas Bader

unread,
Sep 8, 2001, 7:43:43 PM9/8/01
to
* Mike Pfaff <black...@datacomm.ch>:

> - Keine Verwendung von UNIX-Usern(*) oder /etc/passwd, da sich sowieso kein
> Normal-User auf dem Server einloggen kann (Dies sollte ohne Patches oder
> komplizierte Zusatz-Software möglich sein)

Da kann es wohl nur das geben:

qmail, qmail-pop3d, vmailmgr und courier-imap

> - Gut dokumentiert (Gute HOWTOs sind mir da besonders wichtig, denn was nützt
> mir eine Riesen-Doku die einfach stupid alle möglichen und unmöglichen
> Konfigurationsparameter alphabetisch auflistet)

Jepp, gibt es.

http://www.qmail.org/top.html

Thomas

Matthias Andree

unread,
Sep 8, 2001, 9:08:44 PM9/8/01
to
usenet01...@linux.ch.eu.org (Thomas Bader) writes:

> Da kann es wohl nur das geben:
>
> qmail, qmail-pop3d, vmailmgr und courier-imap

Die Mühe mit qmail-pop3d braucht sich bei Verwendung von courier-imap
niemand zu machen.

--
Matthias Andree
Outlook (Express) users: press Ctrl+F3 for the full source code of this post.
begin dont_click_this_virus.exe
end

Thomas Bader

unread,
Sep 9, 2001, 12:24:45 PM9/9/01
to
* Matthias Andree <matthia...@gmx.de>:

> usenet01...@linux.ch.eu.org (Thomas Bader) writes:
> > Da kann es wohl nur das geben:
> >
> > qmail, qmail-pop3d, vmailmgr und courier-imap
>
> Die Mühe mit qmail-pop3d braucht sich bei Verwendung von courier-imap
> niemand zu machen.

Wieso Mühe? qmail-pop3d läuft ja Out of the Box. Ich sehe
also nicht, wieso das eine Mühe sein soll.

Thomas

Robin S. Socha

unread,
Sep 9, 2001, 12:26:53 PM9/9/01
to
* Thomas Bader <usenet01...@linux.ch.eu.org> writes:
> * Matthias Andree <matthia...@gmx.de>:

>> Die Mühe mit qmail-pop3d braucht sich bei Verwendung von courier-imap
>> niemand zu machen.

> Wieso Mühe? qmail-pop3d läuft ja Out of the Box. Ich sehe also
> nicht, wieso das eine Mühe sein soll.

Matthias schmollt gerade, weil Dan im auf der qmail Liste die Falten aus
dem Sack gebügelt hat. Possierliches Spielchen, sowas...

Ralf Döblitz

unread,
Sep 9, 2001, 1:16:23 PM9/9/01
to
Mike Pfaff <black...@datacomm.ch> schrieb:
[...]

>Kennt hier jemand eine Lösung oder kann mir mit guten Dokumentations-Links
>weiterhelfen.

sendmail
sendmail-doc
cyrus-*

Das skaliert auch noch vernünftig wenn man etwas größere Userzahlen hat.

Ralf
--
Ralf Döblitz * Schapenstr. 6 * 38104 Braunschweig * Germany
Phone: +49-531-2361223 Fax: +49-531-2361224 mailto:doeb...@gmx.de
Homepage: http://www.escape.de/users/selene/

Matthias Andree

unread,
Sep 10, 2001, 7:33:37 AM9/10/01
to
usenet01...@linux.ch.eu.org (Thomas Bader) writes:

> Wieso Mühe? qmail-pop3d läuft ja Out of the Box. Ich sehe
> also nicht, wieso das eine Mühe sein soll.

Für qmail-pop3d mußt Du erst checkpassword organisieren und einrichten,
und wenn Du eh Courier-IMAP installierst, hast Du mit *einer*
Installation Daemons für *zwei* Protokolle mit identischer
Authentifizierung eingerichtet.

Matthias Andree

unread,
Sep 10, 2001, 7:57:51 AM9/10/01
to
"Robin S. Socha" <robin-dated-10...@socha.net> writes:

> > Wieso Mühe? qmail-pop3d läuft ja Out of the Box. Ich sehe also
> > nicht, wieso das eine Mühe sein soll.
>
> Matthias schmollt gerade, weil Dan im auf der qmail Liste die Falten aus
> dem Sack gebügelt hat. Possierliches Spielchen, sowas...

Um mal auf Deinem Sprachniveau zu bleiben: Du hast den Arsch auf.

Ich lege das Problem dar, damit jeder ganz klar sieht, was passieren
kann, wenn man ohne genauere Reflektion "irgendeine" Mail in qmail jagt,
ob per qmail-queue oder qmail-qmqpd - ob qmail-inject auf problematisch
ist, hab' ich nicht untersucht.

Was das Problem ist: qmail kann über verschiedene Interfaces, unter
anderem qmail-qmqpd, das auf Port 628 eingerichtet wird, Mail annehmen,
die Dan als "extended format" bezeichnet, die per SMTP nicht verschickt
werden kann (zum Beispiel fehlendes CRLF nach letzter Zeile).

Das kann in letzter Instanz dazu führen, daß die Mail - unter lautem
Gezeter im Log - von qmail-send weggeworfen wird.

Szenario:

1. qmail nimmt die Mail im "extended format" an.

2. qmail-send gibt sie an qmail-remote. Das stellt fest "die Mail geht
nicht durch SMTP" und baut den Bounce. QSBMF, das "tolle" Bounceformat,
ist zwar maschinenlesbar, aber enthält die Originalmail als 1:1-Kopie.
Format.

3. Das heißt, der Bounce geht wieder nicht durch qmail-remote (diesmal
hätte der Absender die Mail kriegen sollen). qmail-send baut nach
denselben Regeln den Double-Bounce an den Postmaster.

4. Da der nicht lokal ist, bounct auch der doublebounce, qmail-send
wirft die Mail und die beiden Bounces weg, heult sich im Log aus und das
war's.

Und ja, Postmaster ist per SMTP in jedem Fall erreichbar, und QMQP
unterliegt passenden ACLS (und ist nicht der einzige Weg, Mail zu
verlieren), insofern liegt kein Konfigurationsfehler vor, wie viele,
unter anderem Dave Sill, mir unterstellt haben.

Die triviale Abhilfe wäre, zumindest den doublebounce so
zurechtzustutzen, daß er in jedem Fall durch SMTP paßt. Man kann dazu
einfach der Body der ursprünglichen Mail wegwerfen, dann sind nur noch
QSBMF-Records und Mailheader über, und der RFC-822-Header paßt immer
durch SMTP.

Sinnvoll wäre das auch deswegen, weil den doublebounceuser der INHALT
der Mail nichts angeht, insofern würde ein zugestellter doublebounce die
Privatsphäre des Absenders verletzen.

Die ordentliche Abhilfe wäre, einen RFC-1894-konformen Bounce zu löten,
der paßt IMMER durch SMTP, das geht mit Dans Ego und bewußter
Desinformation nicht. Auch hier dürfte der doublebounceuser (postmaster
per Default) den Body nicht zu Gesicht bekommen.

Fakt ist, daß praktisch alle relevante Clientsoftware, sei es nun
Listenmanager oder MUA, RFC-1894 versteht. Nur ein Beispiel: mutt
1.3.x.y kann die gebouncte Mail aus dem Bounce extrahieren und im Editor
anbieten.

Dan Schwadron J. Bernstein vergißt leider über seinem Rant gegen
RFC-1894, daß andere, verbreitet MTAs, zum Bleistift Sendmüll und
Postfix, es verwenden und daher Clients RFC-1894 lesen können
müssen. DJB erwartet nun aber, daß sich alle um den Einfall eines
kleinen Professors in Illinois scheren, dessen Hobby das Erfinden
überflüssiger Protokolle und Datenformate ist, und extra noch einen
Parser für das normwidrige QSBMF löten.

Auf den Vorschlag hin, im doublebounce den Body zu strippen, hab' ich
bisher positives Feedback bekommen.

Und nun troll Dich weg.

Niklaus Hug

unread,
Sep 10, 2001, 2:14:58 PM9/10/01
to

"Matthias Andree" <matthia...@gmx.de> wrote in message
news:m3ofoj2...@emma1.emma.line.org...

> "Robin S. Socha" <robin-dated-10...@socha.net> writes:
>

> Was das Problem ist: qmail kann über verschiedene Interfaces, unter
> anderem qmail-qmqpd, das auf Port 628 eingerichtet wird, Mail annehmen,
> die Dan als "extended format" bezeichnet, die per SMTP nicht verschickt
> werden kann (zum Beispiel fehlendes CRLF nach letzter Zeile).

well qmqpd war mir schon immer suspekt .. und läuft bei mir daher auch
nicht. Ist mein schluss richtig, dass ich einen grossen teil der von dir
geschilderten bounce-troubles damit umgehen kann?

gruss

nik


Gerrit Pape

unread,
Sep 10, 2001, 3:49:45 PM9/10/01
to
Matthias Andree <matthia...@gmx.de> wrote:
> Ich lege das Problem dar, damit jeder ganz klar sieht, was passieren
> kann, wenn man ohne genauere Reflektion "irgendeine" Mail in qmail jagt,
> ob per qmail-queue oder qmail-qmqpd - ob qmail-inject auf problematisch
> ist, hab' ich nicht untersucht.

1. 'ohne genauere Reflektion "irgendeine" Mail' ist wohl etwas anderes als
du unten beschreibst
2. du benutzt doch nicht qmail-queue zum Einliefern:
# man qmail-queue
[...]
message. Other than this, qmail-queue does not inspect
the message and does not enforce any restrictions on its
contents. However, the recipients probably expect to see
[...]
bleibt qmail-qmqpd

> Was das Problem ist: qmail kann über verschiedene Interfaces, unter
> anderem qmail-qmqpd, das auf Port 628 eingerichtet wird, Mail annehmen,
> die Dan als "extended format" bezeichnet, die per SMTP nicht verschickt
> werden kann (zum Beispiel fehlendes CRLF nach letzter Zeile).

Zu qmail-qmqpd gibt es auch den entsprechenden client qmail-qmqpc
# man qmail-qmqpc
[...]
qmail-qmqpc offers the same interface as qmail-queue, but
it gives the message to a QMQP server instead of storing
it locally.
[...]
siehe dazu http://cr.yp.to/qmail/mini.html

aus http://cr.yp.to/proto/qmqp.html :
Note that QMQP is not designed for mail injection from dumb clients that are
unable to build complete messages and envelopes. A QMQP server shouldn't
even have to glance at incoming messages; its only job is to queue them and
relay them to the outside world.

> Das kann in letzter Instanz dazu führen, daß die Mail - unter lautem
> Gezeter im Log - von qmail-send weggeworfen wird.

---
On Sat, 08 Sep 2001, D. J. Bernstein wrote:
> You said `QMQP may eat your mail.'' That is a lie. You are maliciously
> trying to frighten people who have no reason to be frightened.
>
> The extended message format is not used for Internet mail. The fact that
> it can't be delivered over SMTP has no relevance to Internet mail users.
> There is no reliability problem here.
---


> Szenario:
> 1. qmail nimmt die Mail im "extended format" an.

Von einem 'dumb client'?

> unterliegt passenden ACLS (und ist nicht der einzige Weg, Mail zu
> verlieren), insofern liegt kein Konfigurationsfehler vor, wie viele,

welcher noch?


> Dan Schwadron J. Bernstein vergißt leider über seinem Rant gegen
> RFC-1894, daß andere, verbreitet MTAs, zum Bleistift Sendmüll und
> Postfix, es verwenden und daher Clients RFC-1894 lesen können
> müssen. DJB erwartet nun aber, daß sich alle um den Einfall eines
> kleinen Professors in Illinois scheren, dessen Hobby das Erfinden

oh mann, was ist mit dir los...


> überflüssiger Protokolle und Datenformate ist, und extra noch einen
> Parser für das normwidrige QSBMF löten.

Einen Vierzeiler, IOHO. Ueberlege dir mal, welche dieser 'überflüssiger
Protokolle und Datenformate' heute Standard sind und auch in postfix
implementiert sind und (gerade) werden.

> Und nun troll Dich weg.

Gerrit.

--
pa...@innominate.com
innominate AG

tel: +49.30.308806-0 fax: -77 http://www.innominate.com

Matthias Andree

unread,
Sep 10, 2001, 11:32:03 PM9/10/01
to
Gerrit Pape <pa...@innominate.com> writes:

> 2. du benutzt doch nicht qmail-queue zum Einliefern:
> # man qmail-queue
> [...]
> message. Other than this, qmail-queue does not inspect
> the message and does not enforce any restrictions on its
> contents. However, the recipients probably expect to see
> [...]

Jeder kann qmail-queue aufrufen, wenn es ihm beliebt. Wenn er das
Protokoll einhält, was selbst mit 'nem Shellwrapper hinzubiegen sein
sollte, wirft qmail-queue die Mail ins System.

> Zu qmail-qmqpd gibt es auch den entsprechenden client qmail-qmqpc
> # man qmail-qmqpc
> [...]
> qmail-qmqpc offers the same interface as qmail-queue, but
> it gives the message to a QMQP server instead of storing
> it locally.
> [...]
> siehe dazu http://cr.yp.to/qmail/mini.html

Wohl wahr, nur legt sich diese Mini-Installation auf den Bart, wenn der
Server nicht funktioniert, weil sie nicht mehr queuen kann.

> aus http://cr.yp.to/proto/qmqp.html :
> Note that QMQP is not designed for mail injection from dumb clients that are
> unable to build complete messages and envelopes. A QMQP server shouldn't
> even have to glance at incoming messages; its only job is to queue them and
> relay them to the outside world.

DJB nennt das ganze "extended format", wenn z. B. die letzte Zeile kein
LF trägt oder sowas. DAs heißt nicht, daß die Nachricht unvollständig
ist. Einen eigenen QMQP-Client schreibst Du mit ein paar Zeilen Perl.

> > 1. qmail nimmt die Mail im "extended format" an.
> Von einem 'dumb client'?

Nein. Oder darf qmail-qmqpd nur SMTP-feste Mail annehmen? Kaum, dann
gäb's die Diskussion um "extended format" nicht.

> > unterliegt passenden ACLS (und ist nicht der einzige Weg, Mail zu
> > verlieren), insofern liegt kein Konfigurationsfehler vor, wie viele,
>
> welcher noch?

qmail-queue.

Und natürlich eine virtuelle Domain anzulegen, die nach /dev/null
zustellt, aber das ist grober Unfug.

[RFC-1894]


> Einen Vierzeiler, IOHO. Ueberlege dir mal, welche dieser 'überflüssiger
> Protokolle und Datenformate' heute Standard sind und auch in postfix
> implementiert sind und (gerade) werden.

QSBMF-Parser sind überflüssiger Code.

RFC-1894-Parser muß jeder haben, um Sendmail und Postfix (und vermutlich
auch Exim) zu verstehen.

Und, mein ganz persönlicher Geschmack: man hätte besser nicht Postfix
einen QMQP-Daemon gegeben, sondern serialmail (weil es ESMTP PIPELINING
redet) so umgehackt, daß es lokal ein qmail-queue-Interface hat. Mal
sehen, ob ich das mal mit ein paar Zeilen Perl mache.

Matthias Andree

unread,
Sep 10, 2001, 11:20:15 PM9/10/01
to
"Niklaus Hug" <n...@fgb.ch> writes:

> well qmqpd war mir schon immer suspekt .. und läuft bei mir daher auch
> nicht. Ist mein schluss richtig, dass ich einen grossen teil der von dir
> geschilderten bounce-troubles damit umgehen kann?

Nein, qmqpd ist auch nicht alleinschuld, sondern nur eines der
Einfallstore, wie beschrieben.

Du kannst die kaputte (DJB sagt "extended format") Mail auch per
qmail-queue reinfüttern, brauchbare Abhilfe gegen unzustellbare Bounces
ist ausschließlich, den doublebounceuser auf dem lokalen Rechner zu
haben und seine Mail in einem Maildir abzulegen. Wird dessen Mail per
SMTP geforwardet, gibt's das Problem, was ich beschreibe.

0 new messages