hallo,

ich bastel grade ein mini-linux zusammen auf dem auch mdadm zum überwachen der raidsets und smartd zum überwachen der festplatten läuft, und nun suche ich einen einfachen kleinen mailserver der die mails von den zwei daemons annimmt und lokal speichert damit der kunde die mails von seiner windows-schüssel aus abholen kann.

ich googel wie verrückt und über sendmail bin ich zu postfix und dann zu xmail gestolpert, aber irgendwie kapiere ich die ganzen sachen nicht, von wegen MTA und gedöns. ist bei den programmen jetzt alles mit dabei oder brauch ich da doch noch 356 zusatz-programme dazu?

gibts da nix einfacheres das einfach nur mails von 127.0.0.1 akzeptiert und die mails irgendwo einfach speichert bis sie per pop3 abgeholt werden?

ich brauch keine relay, anti-spam, anti-virus oder sonstnochwas funktionen.

hoffe mir kann jemand weiter helfen, bis dahin wühle ich mich weiter durchs manual von xmail

ja schau... kisti lässt sich auch mal wieder blicken...

du brauchst einerseits einen mta[1] bzw lda[2] , andererseits einen pop3-dienst.

[1] mail transfer agent
[2] local delivery agent

ein mta hat primär die aufgabe, mails zu empfangen und zu versenden (port25), ein lda liefert eingetroffene (oder von daemons lokal generierte) mails im jeweiligen mailformat zu, viele mta's sind gleichzeitig auch lda's (muss aber nicht so sein).

und damit dein kunde über windows zugreifen kann, braucht er halt einen pop3- bzw. imap-server (für sein outlook/windows mail wasauchimmer-mailclienten)

ich setzt gerne postfix ein, ist ziemlich einfach aufzusetzen, und doch sehr performant (vor allem in kombi mit mysql, aber des brauchst ja net ), und sicher.

wenn es dir nur darum geht, mails aus logfiles auszuwerten, dann reicht mbox als format (die mails werden dann in /var/spool/mail/<username> gespeichert, und die gesamte mailbox ist eine datei), maildir erfordert sonst ein eigenes homeverzeichnis, wo die mailstrukur (curr/new/tmp) abgebildet werden. wenn du mit imap arbeiten willst, dann nimm maildir -> ist flexibler und performanter!

als pop3-daemon gibts mehrere empfehlungen: qpopper, teapop, courier-imap (der hat auch einen pop3-daemon).

nicht jeder pop3-daemon kann mit maildir bzw. mbox umgehen.

welche distro setzt du ein?

empfehlung (für ein einfaches setting):
postfix, mbox: qpopper
postfix, maildir: courier-imap

any questions?

servus,

mit postfix und courier hab ich mich schon beschäftigt. bei postfix hab ich net kapiert was da jetzt alles dabei ist und was ich extra brauche, bei courier widerstrebt es meinem persönlichem geschmack allein diese beknackten extra-daemons einzurichten nur für die auth-geschichte. für meinen persönlichen geschmack ist es schwachsinn 346 programme am laufen zu haben für so eine simple aufgabe wie mails vom mdadm zu empfangen, abzulegen und an den pop3-client auszuliefern.

ich denke ich programmier mir selber was. mini_sendmail von acme.com denke ich werde ich als einstieg nehmen, die funktionalität zum speichern der mails und kleiner pop3-daemon dazu zu bauen wird nicht sonderlich schwer sein.

distro: selbst gebautes embedded-linux mit 2.6er kernel, busybox und uclibc, selbst gebautes paket-management für die updates und für fernwartung ssh und serielle konsole, fertig

da fällt mir auch noch was ein:

ich hatte zuerst dropbear als sshd laufen, aber sftp und scp ging mit dem nicht richtig, also komplettes openssh eingebaut. nun habe ich gestern vsftpd mit ssl-support eingebaut. nur verstehe ich da jetzt was nicht richtig: ist ftp mit ssl das gleiche sftp wie openssh-ftpd? wenn vsftpd ssl kann, brauche ich dann überhaupt den sftpd von openssh?

ich würe halt gerne folgende sachen anbieten:

- fernwartung per ssh oder telnet (default off)
- updates einspielen per browser oder scp
- daten abolen per sftp, normales ftp oder samba

ok, bei einer embed-gschicht wirst sicher kein maildir verwenden, sondern bei mbox bleiben (das für logfiles vollkommen reicht).

somit bleibt der andere vorschlag übrig: postfix und qpopper

von selber coden würd ich abraten, die gefahr von sicherheitslücken ist zu gross - hier würd ich auf alle fälle die vorhandenen resourcen nutzen.

zwecks sftp: ich vermute, dass die gleichen libraries verwendet werden, somit dürfts ident sein. habe aber beide noch nie benutzt, somit: kA

der "verwendungszweck" bzw. das "einsatzgebiet" (wirklich eine embed-umgebung, oder ein normaler pc) wären nicht uninteressant...

es gibt möglicherweise andere übertragungsmöglichkeiten für die logs, z.b. über snmp an einen eigenen logserver (der lokal oder zentralisiert verwaltet wird), somit wären die logs ausgelagert, und die "monsterapplikation" wäre aus der embed-umgebung raus.