Mal wieder eine Konstruktionsfrage, bei der ich bislang
keine befriedigende L�sung gefunden habe, obwohl ich jetzt das
Mail-Admin-HowTo, Net-HowTo, man procmail, man fetchmail
etc studiert habe:
Ich bin mir sicher, das es f�r dieses Problem eine
bekannte L�sung gibt -> vielleicht funktioniert auch das, was
ich mir gedacht habe und es liegt nur irgend ein kleiner
Fehler vor. 

Ich habe hier einen Server und insgesamt 15 Clients. An
den Clients sitzen ebensoviele verschiedene Nutzer.  

Wir haben keine st�ndige Verbindung zu Internet,
sondern sind dialup. Auf dem Server l�uft postfix,
fetchmail und procmail. Die user haben ihre Home-Verzeichnisse
per export/nfs-kernel-saver auf dem Server. 
Das lokale Netz hei�t lokal.lan, so das die Rechner
linux01.lokal.lan, linux02.lokal.lan etc. hei�en.
Die interne Mailadressen hei�en dementsprechend -
je nach Rechner, an dem einer sitzt z. B.
[EMAIL PROTECTED] # wenn user1 an linux01 angemeldet
[EMAIL PROTECTED] # wenn user1 an linux02 angemeldet 

E-Mails an unsere Leute erreichen uns �ber 
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
Jetzt kommt das Problem: Post an user1, user2 .... landet 
bei einem ISP in einem einzigen Postfach, das ich mit
fetchmail leere. Wie bekomme ich diese Post 
hier in die lokalen Postf�cher user1, user2 ...

Das ganze sieht in etwa so aus: 


Sender To:        ISP-Postf.   Server   /var/mail
[EMAIL PROTECTED] ...                         ...user1
                .    ___         ___    .
[EMAIL PROTECTED]| |.........| |..,,,,,.user2
               .     ~~~         ~~~    .
[EMAIL PROTECTED]                          ...user3


Das hei�t, Post an user1 oder user2 wird mit fetchmail von 
einem ISP abgeholt und zwar aus einem Postfach, 
die "To: Adresse
bleibt unver�ndert To: user1 oder To: user2
Bis zu unserem Server und dann alles in /var/mail/user1
ist kein Problem mit fetchmail (poll ISP ... is user1 here)
Dann landet aber Post an user1, user2, und user3 im Postfach
von user1. 

Ich habe bislang folgendes probiert und vielleicht ist 
es nur an meiner falschen Konfiguration gescheitert:

user1 f�hrt aus "fetchmail | procmail" und holt
s�mtliche Post f�r user1, user2 und user3 ab.
In der ~/.procmailrc ivon user1steht dann (ich habe auch eine
Mailingliste f�r user3, die zuerst ausgefiltert werden 
sollte):

>PATH=/usr/bin:/bin:/usr/local/bin:.
>MAILDIR=$HOME/Mail  #Default mbox von mutt 
>DEFAULT=$MAILDIR/mbox
>LOGFILE=$MAILDIR/from
>LOCKFILE=$HOME/.lockmail
>
>:0
>* ^Sender:.*debian
>!user3    
>
>:0
>* ^X-Mailing-List:.*debian
>!user3
>
>:0
>* ^X-Loop:.*debian-user
>!user3   
>
>:0
>To:.*user2
>!user2
>
>:0
>To:.*user3
>!user3

Wenn user1 die Post f�r user3 empf�ngt und an user3 weiterschickt,
also forward "To: user3"      
wei� der MUA (mutt war es bei mir), das die Nachricht an
USER3 NACHNAME  <[EMAIL PROTECTED]> geschickt werden muss und
die Post kommt intern auch bei user3 an. 
Ein "@linux03.lokal.lan" oder "@lokal.lan" als Anh�ngsel an den
Usernamen ist nicht notwendig. 

Ausser dass die Post an den jeweiligen Adressaten weitegeleitet
wird m�chte ich auf jeden Fall vermiden, dass user1, also der user, der 
die gesamte Post abholt, die Post f�r user2 oder user3 zu lesen bekommt.
Das hei�t, die Post darf nicht bei ihm im Postfach landen. Geht das mit
>:0
>To:.*user2
>!user2  
>/dev/null

Ich kann hierzu nat�rlich einen Mailuser einrichten, der nichts
anderes macht alles per cron-job die Post abzuholen, und bei
dem ich alle paar Tage nachschaue, was noch im Postfach von
dem Mailuser h�ngen geblieben ist - lieber w�re es mir aber, wenn 
eine bestimmte Person sozusagen den Rest mit der sonstigen 
t�glichen Post �berpr�ft.  


- - 
--//--\\--
Eckhard Hoeffner
[EMAIL PROTECTED]
--//--\\--

--
-----------------------------------------------------------
Um sich aus der Liste auszutragen schicken Sie bitte eine
E-Mail an [EMAIL PROTECTED] die im Subject
"unsubscribe <deine_email_adresse>" enthaelt.
Bei Problemen bitte eine Mail an: [EMAIL PROTECTED]
-----------------------------------------------------------

684 eingetragene Mitglieder in dieser Liste.

Antwort per Email an