fetchmail holt keine Mails
Ulrich Fürst
Also anscheinend holt fetchmail keine mails ab
fetchmail -a -v -L /var/log/fetchmail
ergibt keinen output auf der console und ein logfile /var/log/fetmail
existiert auch nicht. (als root durchgeführt)
Ich gehe mal davon aus, dass die mails in /var/mail/ulrich landen
müssten und ich sie dann durch ein einfaches "mail" als user auf der
console lesen können müsste?
meine /etc/fetchmailrc
> set no bouncemail
> set daemon 300
> set syslog
>
> poll mail.vr-web.de protocol POP3
> # user "fuerst.ulrich" password "RKYJO55" is "ulrich" fetchall
> user "backports" password "KntaTO1" is "ulrich" fetchall
> # user "firewall-liste" password "DthyJV2" is "ulrich" fetchall
> # user "kde-liste" password "EtreVV9" is "ulrich" fetchall
>
> #poll pop3.web.de protocol POP3
> # user "heimwill" password "comeon" is "ulrich" fetchall
>
>
> defaults:
> antispam -1
> batchlimit 100
>
> #postconnect "irgendwas mit exim"
^^^^^^^^^^^^^^^^^^^^
Da muss ich erst noch rausfinden was da hin gehört... dürfte aber doch
für mein obiges Problem egal sein!?
TIA Ulrich
--
Haeufig gestellte Fragen und Antworten (FAQ):
http://www.de.debian.org/debian-user-german-FAQ/
Zum AUSTRAGEN schicken Sie eine Mail an debian-user-g...@lists.debian.org
mit dem Subject "unsubscribe". Probleme? Mail an listm...@lists.debian.org (engl)
Bjoern Schmidt
> Also anscheinend holt fetchmail keine mails ab
> fetchmail -a -v -L /var/log/fetchmail
> ergibt keinen output auf der console und ein logfile /var/log/fetmail
> existiert auch nicht. (als root durchgeführt)
>
> Ich gehe mal davon aus, dass die mails in /var/mail/ulrich landen
> müssten und ich sie dann durch ein einfaches "mail" als user auf der
> console lesen können müsste?
>
> meine /etc/fetchmailrc
>
>> set no bouncemail
>> set daemon 300
>> set syslog
>>
>> poll mail.vr-web.de protocol POP3
>> # user "fuerst.ulrich" password "RKYJO55" is "ulrich" fetchall
>> user "backports" password "KntaTO1" is "ulrich" fetchall
>> # user "firewall-liste" password "DthyJV2" is "ulrich" fetchall
>> # user "kde-liste" password "EtreVV9" is "ulrich" fetchall
Das sind hoffentlich nicht Deine "richtigen" Zugangsdaten...???
--
Mit freundlichen Gruessen
Bjoern Schmidt
Ulrich Fürst
> Ulrich Fürst wrote:
>
>> Also anscheinend holt fetchmail keine mails ab
>> fetchmail -a -v -L /var/log/fetchmail
>> ergibt keinen output auf der console und ein logfile /var/log/fetmail
>> existiert auch nicht. (als root durchgeführt)
>>
>> Ich gehe mal davon aus, dass die mails in /var/mail/ulrich landen
>> müssten und ich sie dann durch ein einfaches "mail" als user auf der
>> console lesen können müsste?
>>
>> meine /etc/fetchmailrc
>>
>>> set no bouncemail
>>> set daemon 300
>>> set syslog
>>>
>>> poll mail.vr-web.de protocol POP3
>
>
>
>
Nein. Das sind alte...
... seit einigen Minuten.
Aber die neue /etc/fetchmailrc sieht (fast, eben bis auf die Passwörter)
genauso aus.
Gruß Ulrich
Vermutlich hat diese Datei deshalb nur leserechte für root? Nur
dummerweise hatte ich die gerade eh schon offen...
Bjoern Schmidt
>>>> poll mail.vr-web.de protocol POP3
>>>> user "backports" password "KntaTO1" is "ulrich" fetchall
Versuch es doch mal so:
poll mail.vr-web.de protocol POP3
user "backports" there with password "XXXXXXXX"
Und zum debuggen /etc/init.d/fetchmail debug-run ausführen!
root@kilobyte:/var/log# fetchmail -V
This is fetchmail release 6.2.5+NTLM+SDPS+SSL+NLS
--
Mit freundlichen Gruessen
Bjoern Schmidt
Ulrich Fürst
und dann mit der Testfunktione von fetchmailconf getestet. Das schien zu
funktionieren. Wenn man mal davon absieht das keinen Mails auf der
Platte erschienen sind. Aber die Meldungen waren alle o.k.
ein "fetchmail -a -v" auf der console tut aber weiterhin nichts.
Was mach ich da falsch.
Gruß Ulrich
Ulrich Fürst
> Ulrich Fürst wrote:
>
>>>>> poll mail.vr-web.de protocol POP3
>>>>> user "backports" password "KntaTO1" is "ulrich" fetchall
>
>
> Versuch es doch mal so:
>
> poll mail.vr-web.de protocol POP3
> user "backports" there with password "XXXXXXXX"
>
> Und zum debuggen /etc/init.d/fetchmail debug-run ausführen!
>
> /etc/init.d/fetchmail: Stopping the service...
> Stopping mail retrieval agent: system-wide fetchmail not running.
> /etc/init.d/fetchmail: exit status of service stop was: 0
> /etc/init.d/fetchmail: RUNUSER is fetchmail
> /etc/init.d/fetchmail: OPTIONS would be --daemon 300 --syslog -f /etc/fetchmailrc -i /var/mail/.fetchmail-UIDL-cache
> /etc/init.d/fetchmail: Starting service in nodetach mode, hit ^C (SIGINT/intr) to finish run...
> /etc/init.d/fetchmail: End of service run. Exit status was: 5
Dann hab ich noch
set logfile "/var/log/fetchmail"
in die /etc/fetchmailrc eingefügt was leider nichts bewirkt.
>
> root@kilobyte:/var/log# fetchmail -V
> This is fetchmail release 6.2.5+NTLM+SDPS+SSL+NLS
>
Bei mir Version 5.9.11+NTLM+SDPS+NLS
Ulrich
Michelle Konzack
>Nein. Das sind alte...
>
>... seit einigen Minuten.
:-/
>Aber die neue /etc/fetchmailrc sieht (fast, eben bis auf die Passwörter)
>genauso aus.
>
>Gruß Ulrich
>
>Vermutlich hat diese Datei deshalb nur leserechte für root? Nur
>dummerweise hatte ich die gerade eh schon offen...
Die Datei MUSS (!!!) chmod 600 haben (siehe manpage)
Greetings
Michelle
--
Linux-User #280138 with the Linux Counter, http://counter.li.org/
Michelle Konzack Apt. 917 ICQ #328449886
50, rue de Soultz MSM LinuxMichi
0033/3/88452356 67100 Strasbourg/France IRC #Debian (irc.icq.com)
Ulrich Fürst
>>
>>Vermutlich hat diese Datei deshalb nur leserechte für root? Nur
>>dummerweise hatte ich die gerade eh schon offen...
>
>
> Die Datei MUSS (!!!) chmod 600 haben (siehe manpage)
(die hat seit anfang an 600)
Gruß Ulrich
Michael Gerhards
>
> Also anscheinend holt fetchmail keine mails ab
> fetchmail -a -v -L /var/log/fetchmail
> ergibt keinen output auf der console und ein logfile /var/log/fetmail
> existiert auch nicht. (als root durchgeführt)
Ich vermute mal, daß Du Dich hier ebenfalls auf meine IMAP-Anleitung
beziehst, oder? Dort wird als Konfigurationsdatei für Fetchmail
/etc/fetchmailrc benutzt, das ist die Datei, die der Daemon
standardmäßig verwendet.
Dann solltest Du als root den Befehl
fetchmail -v -f /etc/fetchmailrc
benutzen. Denn wenn Du die fetchmailrc nicht explizit angibst, wird (bei
Aufruf als root) die Datei /root/.fetchmailrc verwendet.
> Ich gehe mal davon aus, dass die mails in /var/mail/ulrich landen
> müssten
Ja
> und ich sie dann durch ein einfaches "mail" als user auf der
> console lesen können müsste?
Ja
> meine /etc/fetchmailrc
Da liegt das Problem ;-)
>> set no bouncemail
>> set daemon 300
>> set syslog
>>
>> poll mail.vr-web.de protocol POP3
>> # user "fuerst.ulrich" password "RKYJO55" is "ulrich" fetchall
>> user "backports" password "KntaTO1" is "ulrich" fetchall
>> # user "firewall-liste" password "DthyJV2" is "ulrich" fetchall
>> # user "kde-liste" password "EtreVV9" is "ulrich" fetchall
>>
>> #poll pop3.web.de protocol POP3
>> # user "heimwill" password "comeon" is "ulrich" fetchall
Soweit sollte das dann alles funktionieren.
>> defaults:
>> antispam -1
>> batchlimit 100
>>
>> #postconnect "irgendwas mit exim"
> ^^^^^^^^^^^^^^^^^^^^
Was willst Du mit diesen Befehlen denn erreichen?
HTH,
Michael
Daniel Leidert
> Also jetzt hab ich mal noch eine ~/.fetchmailrc angelegt.
> und dann mit der Testfunktione von fetchmailconf getestet. Das schien zu
> funktionieren. Wenn man mal davon absieht das keinen Mails auf der
> Platte erschienen sind. Aber die Meldungen waren alle o.k.
>
> ein "fetchmail -a -v" auf der console tut aber weiterhin nichts.
> Was mach ich da falsch.
2 mögliche Ursachen:
1. In deiner fetchmailrc steht, dass er das Syslog benutzen soll (das
gehört IMO eher in /etc/default/fetchmail). Und in diesem Fall
missachtet er IIRC die Option -L und schreibt auch nichts auf die
Console. Entweder soll er in das Syslog schreiben oder in ein separates
Logfile. Schau mal, ob sich fetchmail im Syslog verewigt, wenn du es
aufrufst.
2. Übergib ihm den Ort der fetchmailrc mittels -f /etc/fetchmailrc.
MfG Daniel
--
Ulrich Fürst
/var/log/fetchmail nehmen soll. Also verwendet er wohl /etc/fetchmailrc
nicht.
> 2. Übergib ihm den Ort der fetchmailrc mittels -f /etc/fetchmailrc.
>
als root:
> debian:~# fetchmail -v -a -f /etc/fetchmailrc
> File /etc/fetchmailrc must be owned by you.
>
> debian:~# ll /etc/fetchmailrc
> -rw------- 1 fetchmai root 287 13. Jun 18:18 /etc/fetchmailrc
hm, soll ich jetzt die /etc/fetchmailrc root geben (die Einstellung
stammt aber wohl vom Packet).
> debian:~# cp /etc/fetchmailrc /root/.fetchmailrc
>
> debian:~# ll /root/.fetchmailrc
> -rw------- 1 root root 287 13. Jun 22:53 /root/.fetchmailrc
>
>
> debian:~# fetchmail -v -a -f /root/fetchmailrc
> fetchmail: es wurden keine Mailserver spezifiziert.
>
/root/fetchmailrc
> # Configuration created Sun Jun 13 13:40:52 2004 by fetchmailconf
> set logfile "/var/log/fetchmail"
> set postmaster "ulrich"
> set bouncemail
> set no spambounce
> set properties ""
> set daemon 300
>
> poll mail.vr-web.de protocol POP3
> user "backports" password "jetzt_anders" is "ulrich" fetchall
>
2. Variante
> poll mail.vr-web.de protocol POP3
> user "backports" there with password "password" is "ulrich" here options fetchall
bringt auch nichts.
Ulrich Fürst
>>Ich gehe mal davon aus, dass die mails in /var/mail/ulrich landen
>>müssten
>
>
> Ja
/var/mail/ulrich hat 0 Byte obwohl vorhin angeblich 13 mails also so 50
bis 60 kbyte drin sein müssten (waren listen-Mails dieser liste)
>
>
>>und ich sie dann durch ein einfaches "mail" als user auf der
>>console lesen können müsste?
>
>
> Ja
mail sagt:
No mail for user ulrich.
>
>
>>meine /etc/fetchmailrc
>
>
> Da liegt das Problem ;-)
>
>>>defaults:
>>> antispam -1
>>> batchlimit 100
>>>
>>>#postconnect "irgendwas mit exim"
>>
>> ^^^^^^^^^^^^^^^^^^^^
>
>
> Was willst Du mit diesen Befehlen denn erreichen?
>
also die waren alle schon drin. Nur das ich postconnect auskommentiert
habe da dort als argument 'sendmail -q' stand. Da ich sendmail nicht
installiert habe...
bis ich dann gemerkt habe, das das eine aufrufmöglichkeit für exim ist.
Inzwischen steht da wieder
postconnect "sendmail -q"
so wie das ursprünglich der Fall war. Außerdem bewirkt das doch soweit
ich das verstanden habe das die mails in der warteschleife nach dem
abholen nach draußen gehen!?
Gruß Ulrich
Dieter Franzke
Wenn du schon fetchmail als root ausführen willst:
ein kleiner Tip: leg dir eine .fetchmailrc (Punkt davor!) in dein root
Verzeichnis, dann kannst du fetchmail einfach per
fetchmail
als root aufrufen.
Also als root:
cp /etc/fetchmailrc /root/.fetchmailrc
chmoid 600 /root/.fetchmailrc
Ulrich Fürst
>>>Am So, den 13.06.2004 schrieb Ulrich Fürst um 15:38:
>>>
>>>debian:~# cp /etc/fetchmailrc /root/.fetchmailrc
>>>
>>
>
will, wird das ja von root ausgeführt (oder liege ich da falsch?).
Außerdem möchte ich ja alle Konten abfragen egal ob welcher user dann
später welches Mail-Konto aufruft.
> ein kleiner Tip: leg dir eine .fetchmailrc (Punkt davor!) in dein root
> Verzeichnis, dann kannst du fetchmail einfach per
> fetchmail
> als root aufrufen.
> Also als root:
> cp /etc/fetchmailrc /root/.fetchmailrc
> chmoid 600 /root/.fetchmailrc
>
Hab ich ja, nur bringt das auch keinen Erfolg.
Gruß Ulrich
Daniel Leidert
Das ist richtig. Wird der fetchmail-Daemon gestartet (und es wurde
angegeben, dass er nicht als root laufen soll, was der Standard in allen
Howtos ist, auch dem von MG), übernimmt fetchmail den Besitz der
/etc/fetchmailrc. Um fetchmail nun als root aufzurufen, müsstest du dir
kurzzeitig die Leserechte und Schreibrechte von /etc/fetchmailrc auf
root.root übertragen. So sollte es jetzt funktionieren:
debian:~# chown root.root /etc/fetchmailrc
debian:~# fetchmail -a -v -f /etc/fetchmailrc
Die Optionen für den Daemon passt du in /etc/default/fetchmail an.
/etc/default/fetchmail
> SERVICE=true
> CONFFILE=/etc/fetchmailrc
> OPTIONS="--daemon 600 --syslog"
> RUNASROOT=false
Der Daemon liest dann also die Infos aus /etc/fetchmailrc. Wenn du keine
Probleme mit Accounts hast, die POP-before-SMTP benötigen, kannst du den
Zeitrahmen des Abrufens auf 1200 Sekunden oder mehr verändern. Man merkt
bei großen Mail-Aufkommen schon die Arbeit der Spam-Filter.
Nachdem du nun die Rechte der fetchmailrc geändert hast, kann der
fetchmail-Daemon nicht mehr diese Datei lesen und damit auch keine
E-Mails abholen. Ein einfaches
debian:~# /etc/init.d/fetchmail restart
startet den Daemon neu und dabei werden die Rechte von /etc/fetchmailrc
wieder für den User fetchmail gesetzt
debian:~# ll /etc/fetchmailrc
-rw------- 1 fetchmai root 287 13. Jun 18:18 /etc/fetchmailrc
> hm, soll ich jetzt die /etc/fetchmailrc root geben (die Einstellung
> stammt aber wohl vom Packet).
Stammt nicht vom Paket, sondern von deinen Einstellungen. Und ja, für
manuelle Aufrufe musst du das, außer der fetchmail-Service soll unter
root laufen, was nicht zu empfehlen ist.
BTW: Wird das ein separater Mailserver oder läuft das Mail-System auf
einer Workstation?
MfG Daniel
--
Daniel Leidert
> Dieter Franzke schrieb:
> >>>Am So, den 13.06.2004 schrieb Ulrich Fürst um 15:38:
> >>>
> >>>debian:~# cp /etc/fetchmailrc /root/.fetchmailrc
> >>>
> >>
> >
> > Wenn du schon fetchmail als root ausführen willst:
> Naja, wenn ich die Mails über ein Script in /etc/ppp/ip-up.d/ holen
> will, wird das ja von root ausgeführt (oder liege ich da falsch?).
> Außerdem möchte ich ja alle Konten abfragen egal ob welcher user dann
> später welches Mail-Konto aufruft.
Ein schönes Howto, dass dir evtl. auch beim Einrichten von Exim hilft
(z.B. Automatisieren der SMTP-Server zum Versenden):
http://www.linuxer.onlinehome.de/apps/exim.htm
MfG Daniel
--
Ulrich Fürst
Ich nutze das Abrufen als root nur zum testen. Eigentlich soll das dann
schon als Daemon laufen. In /etc/pp/ip-up.d/fetchmail steht dann auch
nur etwas von awaken. Da wird soweit ich das verstanden habe der Daemon
zum Leben erweckt und dann in den ersten Abrufzyklus geschickt.
Daniel Leidert schrieb:
> debian:~# chown root.root /etc/fetchmailrc
> debian:~# fetchmail -a -v -f /etc/fetchmailrc
>
Ich hab die /etc/fetchmailrc lieber nach /root/.fetchmailrc kopiert. Die
hat dort auch 600 und ist root:root
und dann eben fetchmail -a -v -f /root/.fetchmailrc
gut, dass die Mail noch nicht raus war:
diesmal klappte ein
fetchmail -a -v -f /root/.fetchmailrc
mit folgendem Ergebnis in /var/log/fetchmail:
--- snip ---
> fetchmail: reading message back...@mail.vr-web.de:112 of 112 (4194 octets)
> fetchmail: SMTP> MAIL FROM:<bounce-debian-user-german=backports=vr-w...@lists.debian.org> SIZE=4194
> fetchmail: SMTP< 250 <bounce-debian-user-german=backports=vr-w...@lists.debian.org> is syntactically correct
> fetchmail: SMTP> RCPT TO:<ulrich@localhost>
> fetchmail: SMTP< 250 <ulrich@localhost> verified
> fetchmail: SMTP> DATA
> fetchmail: SMTP< 354 Enter message, ending with "." on a line by itself
> fetchmail: SMTP>. (EOM)
> fetchmail: SMTP< 250 OK id=1BZyFz-0000m3-00
> fetchmail: flushed
> fetchmail: POP3> DELE 112
> fetchmail: POP3< +OK Deleted.
> fetchmail: POP3> QUIT
> fetchmail: POP3< +OK Bye-bye.
> fetchmail: 5.9.11 querying mail.vr-web.de (protocol POP3) at Mon Jun 14 22:40:39 2004: poll completed
> fetchmail: SMTP> QUIT
> fetchmail: SMTP< 221 debian closing connection
> fetchmail: sleeping at Mon Jun 14 22:40:39 2004
--- snip ---
Das sieht doch so aus, als würde das klappen.
> Die Optionen für den Daemon passt du in /etc/default/fetchmail an.
>
> /etc/default/fetchmail
>
>>SERVICE=true
>>CONFFILE=/etc/fetchmailrc
>>OPTIONS="--daemon 600 --syslog"
>>RUNASROOT=false
Außer das ich ...--daemon 900 habe stimmen die überein. (Web.de verlangt
eine Pause von 15 Min. bis zum nächsten einloggen)
> BTW: Wird das ein separater Mailserver oder läuft das Mail-System auf
> einer Workstation?
Einzeln stehender Computer als lokaler Mailserver damit verschiedene
User-Accounts auf diesem Computer auf die gleichen Mailkonten zugreifen
können ohne diese doppelt runterladen zu müssen, etc.
Gruß Ulrich
P.S. werd mir jetzt mal Deinen Link zu Gemüte führen...
Daniel Leidert
> Hallo Daniel, erst mal zum Anfang eine kurze Erklärung:
> Ich nutze das Abrufen als root nur zum testen.
Das war mir schon klar :-)
Wenn aber der fetchmail-Daemon einmal gestartet wird, übernimmt er den
Besitz von /etc/fetchmailrc. Wenn man fetchmail dann als root zum Testen
aufrufen will, muss man sich kurzfristig wieder die Datei übereignen.
Ein Restart des Daemons stellt wieder die Besitzrechte für fetchmail
her.
> Eigentlich soll das dann
> schon als Daemon laufen. In /etc/pp/ip-up.d/fetchmail steht dann auch
> nur etwas von awaken. Da wird soweit ich das verstanden habe der Daemon
> zum Leben erweckt und dann in den ersten Abrufzyklus geschickt.
>
> Daniel Leidert schrieb:
> > debian:~# chown root.root /etc/fetchmailrc
> > debian:~# fetchmail -a -v -f /etc/fetchmailrc
> >
> Ich hab die /etc/fetchmailrc lieber nach /root/.fetchmailrc kopiert. Die
> hat dort auch 600 und ist root:root
> und dann eben fetchmail -a -v -f /root/.fetchmailrc
> gut, dass die Mail noch nicht raus war:
> diesmal klappte ein
> fetchmail -a -v -f /root/.fetchmailrc
> mit folgendem Ergebnis in /var/log/fetchmail:
[Log gesnippt]
> Das sieht doch so aus, als würde das klappen.
Sieht doch gut aus.
> > BTW: Wird das ein separater Mailserver oder läuft das Mail-System auf
> > einer Workstation?
>
> Einzeln stehender Computer als lokaler Mailserver damit verschiedene
> User-Accounts auf diesem Computer auf die gleichen Mailkonten zugreifen
> können ohne diese doppelt runterladen zu müssen, etc.
Aha. BTW: Schau, dass du die IP-Bindungen sinnvoll setzt.
> Gruß Ulrich
>
> P.S. werd mir jetzt mal Deinen Link zu Gemüte führen...
Wenn du zusätzlich zu Michael Gerhards Anleitung noch Razor, Pyzor und
den DCC-Client in SpamAssassin integrieren willst, dann würde ich dir
zusätzlich noch http://www.xmission.com/~jmcrc/spamfilter20040201.html
als Lesestoff empfehlen. Und ein kleiner Hinweis zu Bogofilter: Die
Versionen 0.90 und 0.91.1 waren ziemlich buggy. Mit der
Vorgänger-Version oder der aktuellen 0.91.2 solltest du besser fahren,
wenn du Bogofilter einsetzen willst.
MfG Daniel
--
Ulrich Fürst
>>>BTW: Wird das ein separater Mailserver oder läuft das Mail-System auf
>>>einer Workstation?
>>
>>Einzeln stehender Computer als lokaler Mailserver damit verschiedene
>>User-Accounts auf diesem Computer auf die gleichen Mailkonten zugreifen
>>können ohne diese doppelt runterladen zu müssen, etc.
>
>
> Aha. BTW: Schau, dass du die IP-Bindungen sinnvoll setzt.
Sorry, mit der Aussage kann ich nichts Anfangen. Wo mach ich das, für
welches Programm soll ich das machen...?
Aber vielleicht meinst Du ja damit genau das was mir gerade eingefallen
ist. Siehe [Solved]-Mail in diesem Thread?
>
> Wenn du zusätzlich zu Michael Gerhards Anleitung noch Razor, Pyzor und
> den DCC-Client in SpamAssassin integrieren willst, dann würde ich dir
Spamassassin lässt sich in woody irgendwie nicht installieren (auch
nicht von backports.org)
> zusätzlich noch http://www.xmission.com/~jmcrc/spamfilter20040201.html
> als Lesestoff empfehlen. Und ein kleiner Hinweis zu Bogofilter: Die
> Versionen 0.90 und 0.91.1 waren ziemlich buggy. Mit der
> Vorgänger-Version oder der aktuellen 0.91.2 solltest du besser fahren,
> wenn du Bogofilter einsetzen willst.
Dann dürfte es da keine Probleme geben, ich habe die "Weit-Vorgänger"-
Version ;-)
bogofilter:
Installed: 0.17.4-0.backports.org.1
Gruß Ulrich
Ulrich Fürst
> Mahlzeit!
>
> Also anscheinend holt fetchmail keine mails ab
> fetchmail -a -v -L /var/log/fetchmail
> ergibt keinen output auf der console und ein logfile /var/log/fetmail
> existiert auch nicht. (als root durchgeführt)
wie schon bei wwwoffle ist die Lösung, den Daemon nach Aufbau der
Internetverbindung neu zu starten da sich die DNS-Adressen ändern.
>
> Ich gehe mal davon aus, dass die mails in /var/mail/ulrich landen
> müssten und ich sie dann durch ein einfaches "mail" als user auf der
> console lesen können müsste?
>
Nur das tun sie immer noch nicht. Ist aber wohl ein exim-Problem?
Gruß Ulrich
Christian Schmidt
> wie schon bei wwwoffle ist die Lösung, den Daemon nach Aufbau der
> Internetverbindung neu zu starten da sich die DNS-Adressen ändern.
Damit bekaempfst Du aber nur Symptome.
Wenn Du dafuer sorgst, dass sich die bei Dir eingetragenen
Nameserver nicht aendern, kannst Du Dir das Gehampel vermutlich
sparen.
Die IP-Adressen von Nameservern aendern sich fuer gewohnlich nicht
alle drei Tage...
Gruss,
Christian
--
Christian Schmidt | Germany
christia...@chemie.uni-hamburg.de
Michelle Konzack
>Spamassassin lässt sich in woody irgendwie nicht installieren (auch
>nicht von backports.org)
Dan trage zusätzlich in Deine /etc/apt/sources.list
deb http://www.backports.org/debian woody debhelper
ein.
>Gruß Ulrich
Norbert Tretkowski
> Daniel Leidert schrieb:
> > und den DCC-Client in SpamAssassin integrieren willst, dann würde
> > ich dir
>
> Spamassassin lässt sich in woody irgendwie nicht installieren (auch
> nicht von backports.org)
Warum nicht?
Norbert
Norbert Tretkowski
> Am 2004-06-15 11:01:12, schrieb Ulrich Fürst:
>
> >Spamassassin lässt sich in woody irgendwie nicht installieren (auch
> >nicht von backports.org)
>
> Dan trage zusätzlich in Deine /etc/apt/sources.list
>
> deb http://www.backports.org/debian woody debhelper
>
> ein.
Wozu? Spamassassin braucht kein debhelper. Und die debconf Dependency
wird ueber den Spamassassin Eintrag in der sources.list erschlagen.
Norbert
Bjoern Schmidt
>> Ich gehe mal davon aus, dass die mails in /var/mail/ulrich landen
>> müssten und ich sie dann durch ein einfaches "mail" als user auf der
>> console lesen können müsste?
>
> Nur das tun sie immer noch nicht. Ist aber wohl ein exim-Problem?
WO landen sie statt dessen?
--
Mit freundlichen Gruessen
Bjoern Schmidt
Clemens Wohld
Warum nicht root fetchen lassen?? Ich wuerde mein pop/smtp-auth
nicht jedem user ins $HOME packen!
> ein kleiner Tip: leg dir eine .fetchmailrc (Punkt davor!) in dein root
> Verzeichnis, dann kannst du fetchmail einfach per
> fetchmail
> als root aufrufen.
> Also als root:
> cp /etc/fetchmailrc /root/.fetchmailrc
> chmoid 600 /root/.fetchmailrc
$ chmod 600 /root/.fetchmailrc \
&& chown root:root /root/.fetchmailrc
Nur so... Denn die sollte genauso gesichert sein wie jedes andere
passwd-file.
Gruss, Clemens Wohld
--
sig_37
Ein kl. Vorgeschmack auf die Fülle von Progs
unter "X" gibt: [Info: man ls; man X]
$ ls /usr/bin/X11/*
[ XPage =>> http://urlz.de/xpage ]
---------------------------------------------
Ulrich Fürst
> Ulrich Fürst wrote on 15.06.2004 (d.m.y):
>
>
>>wie schon bei wwwoffle ist die Lösung, den Daemon nach Aufbau der
>>Internetverbindung neu zu starten da sich die DNS-Adressen ändern.
>
>
> Damit bekaempfst Du aber nur Symptome.
> Wenn Du dafuer sorgst, dass sich die bei Dir eingetragenen
> Nameserver nicht aendern, kannst Du Dir das Gehampel vermutlich
> sparen.
>
> Die IP-Adressen von Nameservern aendern sich fuer gewohnlich nicht
> alle drei Tage...
>
Also bei wwwoffle war das so: (so hab ich zumindest verstanden)
wwwoffle versucht die Adressen aus /etc/ppp/resolve.conf zu nehmen. Da
sich diese aber bei jeder Einwahl (modem, versch. Provider) ändern. Kann
er sie eben nicht auflösen. Darauf wurde mir (der Thread war, glaub ich,
unbedeutend kürzer, leider) geraten einfach nach der Einwahl wwwoffle
neu zu starten. DAnach hat's geklappt. Bis heute :-))))
Und das gleiche hab ich jetzt eben mit fetchmail gemacht. Ich bin aber
jederzeit für bessere Lösungen offen...
Gruß Ulrich
Ulrich Fürst
> Ulrich Fürst wrote:
>
>>> Ich gehe mal davon aus, dass die mails in /var/mail/ulrich landen
>>> müssten und ich sie dann durch ein einfaches "mail" als user auf der
>>> console lesen können müsste?
>>
>>
>> Nur das tun sie immer noch nicht. Ist aber wohl ein exim-Problem?
>
>
> WO landen sie statt dessen?
>
herunterladen hat mir da keine Antwort gebracht.
(Auf jeden Fall gibt's weder für die zwei user noch für root mails)
Seit einiger Zeit (dummerweise weiß ich leider nicht seit wann, kommen
auch keine mails von cron-jobs u.ä.)
Gruß Ulrich
Ulrich Fürst
> * Ulrich Fürst wrote:
>
>>Daniel Leidert schrieb:
>>
>>>Wenn du zusätzlich zu Michael Gerhards Anleitung noch Razor, Pyzor
>>>und den DCC-Client in SpamAssassin integrieren willst, dann würde
>>>ich dir
>>
>>Spamassassin lässt sich in woody irgendwie nicht installieren (auch
>>nicht von backports.org)
>
>
> Warum nicht?
>
...weil ich mein Pinning nicht im Griff hab. :-( Ich habe zwar für
spamassassin deine Version angegeben habe aber nicht für debconf, also:
"apt-get install spamassassin=2.63-0.backports.org.1 debconf"
Ergo will er debconf aus woody/main nehmen. Und das geht natürlich nicht.
Mit
apt-get -s install spamassassin=2.63-0.backports.org.1 debconf=1.2.35
klappts wunderbar. (spamc kommt auch noch mit)
Sorry,
Ulrich
P.S. Mal von dieser Meldung abgesehen
> The following packages will be REMOVED:
> debconf-utils debhelper
ersteres ist wohl ziemlich egal, bei debhelper würde mir dselect auch
noch alsa-source removen, nur wäre das auch wiederum unwichtig.
Christian Schmidt
Ulrich Fürst, 15.06.2004 (d.m.y):
> Also bei wwwoffle war das so: (so hab ich zumindest verstanden)
> wwwoffle versucht die Adressen aus /etc/ppp/resolve.conf zu nehmen. Da
^ Typo?
> sich diese aber bei jeder Einwahl (modem, versch. Provider) ändern. Kann
> er sie eben nicht auflösen.
Die in der resolv.conf aufgefuehrten IP-Adressen werden nicht
"aufgeloest", sondern zwecks DNS-Anfragen kontaktiert.
> Darauf wurde mir (der Thread war, glaub ich,
> unbedeutend kürzer, leider) geraten einfach nach der Einwahl wwwoffle
> neu zu starten. Danach hat's geklappt. Bis heute :-))))
Fuer wwwoffle gibt es doch AFAIK das Kommando "wwwoffle -online" oder
so aehnlich, was man in der ip-up unterbringen kann...
> Und das gleiche hab ich jetzt eben mit fetchmail gemacht. Ich bin aber
> jederzeit für bessere Lösungen offen...
Du kannst bis zu drei Nameserver in die resolv.conf eintragen...
Gruss,
Christian
--
Was die neuen Unwissenden holen müssen:
Fertigfugen
Gerhard Gaussling
> WO landen sie statt dessen?
Vielleicht kannst Du den Mail Queue mit eximon oder watch beobachten.
watch tail /var/spool/mail/ulrich o.ä.
sudo xterm -e tail -f /var/log/exim/mainlog & oder andere logdateien
ciao
Gerhard
Christian Schmidt
Gerhard Gaussling, 17.06.2004 (d.m.y):
> Am Dienstag 15 Juni 2004 12:41 schrieb Bjoern Schmidt:
> > WO landen sie statt dessen?
> Ähem... sortiert procmail oder exim direkt nach $HOME/Mail ?
Das kommt auf die jeweilige Konfiguration an. Beide koennen es.
Gruss,
Christian
--
Hier geht nicht's, aber das mit System.
Bjoern Schmidt
> Hallo Gerhard,
>
> Gerhard Gaussling, 17.06.2004 (d.m.y):
>
>
>>Am Dienstag 15 Juni 2004 12:41 schrieb Bjoern Schmidt:
>>
>>>WO landen sie statt dessen?
>
>
>>Ähem... sortiert procmail oder exim direkt nach $HOME/Mail ?
>
> Das kommt auf die jeweilige Konfiguration an. Beide koennen es.
Ich denke die Frage ging an Ulrich, der immer noch in /var/mail sucht
obwohl die Mails evtl. schon im Home sind. Die Frage war ob procmail
oder exim direkt nach $HOME/Mail sortiert und NICHT nach /var/mail.
Zumindest war es dass was ich wissen wollte...
Ulrich Fürst
> Hallo Ulrich,
>
> Ulrich Fürst, 15.06.2004 (d.m.y):
>
>
>>Also bei wwwoffle war das so: (so hab ich zumindest verstanden)
>>wwwoffle versucht die Adressen aus /etc/ppp/resolve.conf zu nehmen. Da
>
> ^ Typo?
>
> Fuer wwwoffle gibt es doch AFAIK das Kommando "wwwoffle -online" oder
> so aehnlich, was man in der ip-up unterbringen kann...
>
> Du kannst bis zu drei Nameserver in die resolv.conf eintragen...
>
Stimmt da die bei Einwahl aber jeweils zwei neue dazukommen bräuchte ich
nach einer Woche und 2mal tgl. Mails abrufen 98 Einträge. Und es werden
immer mehr.
Ich hab das mal mitverfolgt. Die resolv.conf wird bei jeder einwahl mit
neuen nameserver-einträgen überschrieben.
Nur wwwoffel -online / -offline bringt keinen Erfolg. Das war ja der
Originalzustand.
Gerhard Gaussling
> Zumindest war es dass was ich wissen wollte...
schließlich bleiben, oder sortiert procmail bei dieser speziellen
Konfiguration etwa fein nach /dev/null ? Ich denke nicht ... ;-)
ciao
Gerhard
Christian Schmidt
Ulrich Fürst, 16.06.2004 (d.m.y):
> Christian Schmidt schrieb:
> >
> >Du kannst bis zu drei Nameserver in die resolv.conf eintragen...
> >
>
> Stimmt da die bei Einwahl aber jeweils zwei neue dazukommen bräuchte ich
> nach einer Woche und 2mal tgl. Mails abrufen 98 Einträge. Und es werden
> immer mehr.
Du hast mich nicht verstanden: Ein Provider wird _nicht_ in
monatlichem, woechentlichen oder gar taeglichen Rhythmus die
IP-Adressen seiner Nameserver aendern.
> Ich hab das mal mitverfolgt. Die resolv.conf wird bei jeder einwahl mit
> neuen nameserver-einträgen überschrieben.
Dann achte mal darauf, wie diese Eintraege aussehen. Ich vermute mal,
dass sie sich von Einwahl zu Einwahl nicht unterscheiden werden.
Und das heisst: Du kannst sie auch fest eintragen und Deinem System
mitteilen, dass es bei der Einwahl die Finger von der Datei lassen
soll.
Gruss,
Christian
--
Wie man sein Kind nicht nennen sollte:
Phil O. Soph
Gerhard Gaussling
> Ich hab das mal mitverfolgt. Die resolv.conf wird bei jeder einwahl
> mit neuen nameserver-einträgen überschrieben.
Schau mal hier:
$ cat /etc/ppp/ip-up.d/0dns-up
ciao
Gerhard
Gerhard Gaussling
> > Stimmt da die bei Einwahl aber jeweils zwei neue dazukommen
> > bräuchte ich nach einer Woche und 2mal tgl. Mails abrufen 98
> > Einträge. Und es werden immer mehr.
>
> Du hast mich nicht verstanden: Ein Provider wird _nicht_ in
> monatlichem, woechentlichen oder gar taeglichen Rhythmus die
> IP-Adressen seiner Nameserver aendern.
Ein DNS sollte ja eigentlich reichen, um die Adressen auzulösen.
ciao
Gerhard
Gerhard Gaussling
> dass sie sich von Einwahl zu Einwahl nicht unterscheiden werden.
/etc/resolv.conf:nameserver 195.93.73.134
Die nächste Einwahl:
$ sudo grep `cat /etc/resolv.conf|awk '{print$2}'` /etc/
/etc/ppp/resolv.conf:nameserver 62.104.191.241
/etc/resolv.conf:nameserver 62.104.191.241
ciao
Gerhard
Gerhard Gaussling
> Die IP-Adressen von Nameservern aendern sich fuer gewohnlich nicht
> alle drei Tage...
Bei dynamischer Vergabe durch den provider kann das schon mal vorkommen,
macht aber AFAIK den Kohl auch nicht fett.
ciao
gerhard
Christian Schmidt
Gerhard Gaussling, 17.06.2004 (d.m.y):
> Am Donnerstag 17 Juni 2004 20:19 schrieb Christian Schmidt:
Ja. Allerdings kann ein Server auch mal ausfallen - trotz aller
moeglicher Vorsorge. Eben deshalb betreibt man als Provider auch
(mindestens) zwei Nameserver.
Gruss,
Christian
--
Aufklärung:
der Vorgang, bei dem ein Erwachsener mit Hilfe aller seiner Kenntnisse
dem Kind ein Viertel von dem erzählt, was es schon weiß.
Christian Schmidt
Gerhard Gaussling, 17.06.2004 (d.m.y):
> Am Donnerstag 17 Juni 2004 20:19 schrieb Christian Schmidt:
OK, die Nameserver gehoeren aber wohl dem gleichen Provider, oder?
(Bin jetzt zu faul, das selbst zu pruefen...)
Gerhard Gaussling, 17.06.2004 (d.m.y):
> Am Dienstag 15 Juni 2004 11:29 schrieb Christian Schmidt:
> > Die IP-Adressen von Nameservern aendern sich fuer gewohnlich nicht
> > alle drei Tage...
>
> Bei dynamischer Vergabe durch den provider kann das schon mal vorkommen,
Ja: Dass Dir andere IP-Adressen _uebermittelt_ werden. Aber auch wenn
ein ISP einen "Pool" von Nameservern (also mehrere "Paare") betreibt,
werden sich die IP-Adressen der verschiedenen Nameserver nicht alle
naslang aendern.
> macht aber AFAIK den Kohl auch nicht fett.
Wenn es jeweils der gleiche Provider ist, sollte man IMO auch mit
dauerhaft eingetragenen Nameserver-IP-Adressen klarkommen.
Gruss,
Christian
--
Hardware scheppert, wenn man dagegen tritt.
Ulrich Fürst
Hm, also wenn ich das richtig verstehe, muss ich die Name-Server nicht
in /etc/ppp/resolv.conf eintragen, sondern in /etc/ppp/resolv/Provider
Folglich kann ich pro Provider zwei Einträge machen.
> # Tell nscd about what we've done.
Ist das schlecht, wenn ich das nicht installiert habe oder funktioniert
das ganze trotzdem?
Ulrich Fürst
> Am Dienstag 15 Juni 2004 12:41 schrieb Bjoern Schmidt:
>
>>WO landen sie statt dessen?
>
> Ähem... sortiert procmail oder exim direkt nach $HOME/Mail ?
find / -amin 5 müsste aber (direkt nach einem erfolgreichen
herunterladen ausgeführt) doch die Mails finden. Es sei denn sie sind in
/dev/null?
Gruß Ulrich
P.S. Vielen Dank (und Sorry) für die Mühe an Euch alle, aber ich glaub
das ist ein Paar Level zu hoch für mich, ich lass das lieber mit dem
Mail-Server...
Vielleicht lese ich mich weiter in das Thema ein und probier das in ein
paar Monaten/Jahren noch mal...
Am liebsten wäre mir glaub ich wenn allerdings die lokale Zustellung
wieder klappen würde (ich bekomme nämlich auch keine Systemmails mehr
von Cron und Co).
eximconfig hab ich ausgeführt mit Option 4 (nur lokale Mailzustellung)
Christian Schmidt
Ulrich Fürst, 18.06.2004 (d.m.y):
> Gerhard Gaussling schrieb:
> >Am Mittwoch 16 Juni 2004 15:58 schrieb Ulrich Fürst:
> >
> >>Ich hab das mal mitverfolgt. Die resolv.conf wird bei jeder einwahl
> >>mit neuen nameserver-einträgen überschrieben.
> >
> >
> >Schau mal hier:
> >$ cat /etc/ppp/ip-up.d/0dns-up
Diese Datei duerfte dafuer verantwortlich sein, dass Dein System im
Zuge der Einwahl die Nameserver-Adressen erfragt.
> Hm, also wenn ich das richtig verstehe, muss ich die Name-Server nicht
> in /etc/ppp/resolv.conf eintragen, sondern in /etc/ppp/resolv/Provider
Keine Ahnung - die jeweils _aktuell_ zu verwendenden Nameserver
muessen aber auf jeden Fall in die /etc/resolv.conf.
> Folglich kann ich pro Provider zwei Einträge machen.
Die /etc/resolv.conf bzw. das System kann max. drei Eintraege
"beruecksichtigen".
Gruss,
Christian
--
Es ist oft sehr gefährlich, von seinem Verstande und Herzen zu
schlecht zu denken - der Irrtum schafft die Wahrheit.
-- Jean Paul
Gerhard Gaussling
> Keine Ahnung - die jeweils _aktuell_ zu verwendenden Nameserver
> muessen aber auf jeden Fall in die /etc/resolv.conf.
das erledigt aber das script. Das heißt Ulrich muß, falls er einen fixen
Eintrag will das woanders als in der /etc/resolv.con machen.
Es gibt dafür mit Sicherheit ein passendes dpkg-reconfigure, das mir im
Moment entfallen ist.
siehe auch Ganten Seite 616.
Ulrich hat das System so konfiguriert, dass es sich den für den provider
zu verwendenden nameserver bei jeder Einwahl vom Provider mitteilen
lässt.
Schau mal unter /etc/network
ciao
Gerhard
Gerhard Gaussling
> Es sei denn sie sind in
> /dev/null?
Glaube ich nicht.
Das mit /dev/null war eigendlich ein Scherz. Du solltest mit
sudo xterm -e tail -f /var/log/exim/mainlog &
sudo xterm -e tail -f /var/log/mail.log &
sudo xterm -e tail -f /var/log/messages &
Hinweise bekommen. Je nach Konfiguration xterm oder sudo, dann aber auch
das "&" weglassen.
ciao
Gerhard
Gerhard Gaussling
> Wenn es jeweils der gleiche Provider ist, sollte man IMO auch mit
> dauerhaft eingetragenen Nameserver-IP-Adressen klarkommen.
Ja, denke ich auch, ich habe leider bvergessen wie man nameserver fest
einbindet (etwas peinlich: google könnte aber helfen).
AFAIK ist die konfiguration der dynamischen Vergabe aber durchaus
sinnvoll. Was spricht dagegen sich beii Einwahl einen nameserver vom
provider mitteilen zu lassen?
ciao
Gerhard
Christian Schmidt
Gerhard Gaussling, 19.06.2004 (d.m.y):
> Am Freitag 18 Juni 2004 20:57 schrieb Christian Schmidt:
> > Keine Ahnung - die jeweils _aktuell_ zu verwendenden Nameserver
> > muessen aber auf jeden Fall in die /etc/resolv.conf.
>
> das erledigt aber das script.
Das ist mir klar.
> Das heißt Ulrich muß, falls er einen fixen
> Eintrag will das woanders als in der /etc/resolv.con machen.
...oder halt das Skript "deaktivieren".
> Es gibt dafür mit Sicherheit ein passendes dpkg-reconfigure, das mir im
> Moment entfallen ist.
Das wird die Nameserver aber mit ziemlicher Sicherheit in der
/etc/resolv.vonf verewigen.
> siehe auch Ganten Seite 616.
>
> Ulrich hat das System so konfiguriert, dass es sich den für den provider
> zu verwendenden nameserver bei jeder Einwahl vom Provider mitteilen
> lässt.
Ist mir klar.
> Schau mal unter /etc/network
Nein, ich schaue gar nicht - ich habe ja kein Problem mit meinen fixen
DNS-Eintraegen. ;-)
Gruss,
Christian
--
Wie man sein Kind nicht nennen sollte:
Terry Er
Gerhard Gaussling
> > Schau mal unter /etc/network
>
> Nein, ich schaue gar nicht - ich habe ja kein Problem mit meinen
> fixen DNS-Eintraegen. ;-)
War auch an Ulrich gerichtet. Mit google dürfte er durch unsere Hinweise
ja fündig werden.
Zum Beispiel mit diesem Suchstring:
ciao
Gerhard
Christian Schmidt
Gerhard Gaussling, 19.06.2004 (d.m.y):
> Am Freitag 18 Juni 2004 18:45 schrieb Christian Schmidt:
Dass der OP mit diesem Szenario offensichtlich irgendwelche Probleme
hat...
Gruss,
Christian
--
Letzte Worte eines Großwildjägers:
"Eben war er noch da drüben."
Gerhard Gaussling
Am Samstag 19 Juni 2004 15:12 schrieb Christian Schmidt:
> Dass der OP mit diesem Szenario offensichtlich irgendwelche Probleme
> hat...
Mit dem anderen Szenario scheinbar ebenfalls...
ciao
Gerhard
Gerhard Gaussling
> > # Tell nscd about what we've done.
>
> Ist das schlecht, wenn ich das nicht installiert habe oder
> funktioniert das ganze trotzdem?
also hier ist es nicht installiert, und ich habe mit meiner
Konfiguration hier keine Probleme (dynamische Vergabe des nameservers
durch den Provider (compuserv freenet arcor).
ciao
Gerhard
Ulrich Fürst
nehme mal an Du meinst den ersten Treffer?)
Gruß
Ulrich