• Willkommen im Linux Club - dem deutschsprachigen Supportforum für GNU/Linux. Registriere dich kostenlos, um alle Inhalte zu sehen und Fragen zu stellen.

fetchmail - Problem!

Status
Für weitere Antworten geschlossen.
P

pft

Also, jetzt wissen wir wenigstens dass er keine local matches findet und deshalb an mailadmin weiterleitet (lag auch nahe)
About to rewrite To: musterfrau@firma.de
Rewritten version is To: musterfrau@firma.de

fetchmail: no local matches, forwarding to mailadmin
fetchmail: forwarding to localhost
Zum Vergrößern anklicken....

Die Frage ist warum.
Das mit den localdomains hast Du falsch verstanden (fetchmail man-page lesen!!)
Du sendest die Mails doch an firma.de warum schreibst Du dann firma.local ?

Schreib bitte "firma.de" und lass uns nachher darüber diskutieren, warum
das mit local blödsin ist.
 
OP
M

magic_halli

Teilerfolg?!?!

Mail jeweils an musterfrau@firma.de und musterkind@firma.de geschickt und keine Fehlermeldung im Log - nachdem ich localdomains geändert habe:
Code: 
poll pop.kundenserver.de with proto POP3
no dns
localdomains firma.de
user 'm0815' with pass 'geheim1' is user musterfrau musterkind
here keep
antispam 554

...es werden aber die Mails durch das localdomains irgendwie nochmal zum ISP geschickt - d.h. statt 2 Mails (jeweils einmal an musterfrau und musterkind) existieren diese nun doppelt beim Provider, aber sie werden trotzdem nicht lokal verteilt. Wie ich's im manual verstanden habe, führt man unter localdomains eine Liste derer Domains auf, welche als lokal betrachtet werden sollen?! Was hat das hier für einen Zweck? Es sollte doch als lokale Domaine eigentlich meine firma.local betrachtet werden? Naja....
Hier mal das Log:
Code: 
fetchmail: 5.9.13 querying pop.kundenserver.de (protocol POP3) at Mon, 06 Nov 2006 11:34:07 +0100 (CET): poll started
fetchmail: POP3< +OK POP server ready H mimap27
fetchmail: POP3> CAPA
fetchmail: POP3< +OK Capability list follows
fetchmail: POP3< TOP
fetchmail: POP3< USER
fetchmail: POP3< UIDL
fetchmail: POP3< STLS
fetchmail: POP3< IMPLEMENTATION nemesis
fetchmail: POP3< .
fetchmail: POP3> STLS
fetchmail: POP3< +OK Begin TLS negotiation
fetchmail: pop.kundenserver.de key fingerprint: 30:AC:79:A3:51:86:A2:42:69:5A:F3:A2:5A:1D:2F:B6
fetchmail: POP3> USER m42240557-6
fetchmail: POP3< +OK password required for user "m0815"
fetchmail: POP3> PASS
fetchmail: POP3< +OK mailbox "m0815" has 2 messages (2806 octets) H mimap27 N
fetchmail: selecting or re-polling default folder
fetchmail: POP3> STAT
fetchmail: POP3< +OK 2 2806
2 messages for m0815 at pop.kundenserver.de (2806 octets).
fetchmail: POP3> LIST
fetchmail: POP3< +OK 2 messages (2806 octets)
fetchmail: POP3< 1 1318
fetchmail: POP3< 2 1488
fetchmail: POP3< .
fetchmail: POP3> RETR 1
fetchmail: POP3< +OK 1318 octets
reading message m0815@pop.kundenserver.de:1 of 2 (1318 octets)
About to rewrite Return-Path: <externer_user@web.de>
Rewritten version is Return-Path: <externer_user@web.de>

fetchmail: analyzing Received line:
Received: from [217.72.192.184] (helo=fmmailgate09.web.de)
        by mx.kundenserver.de (node=mxeu7) with ESMTP (Nemesis),
        id 0MKsxo-1Gh1lZ1Rz2-0006L0 for musterfrau@firma.de; Mon, 06 Nov 2006 11:31:46 +0100
fetchmail: line rejected, mx.kundenserver.de is not an alias of the mailserver
fetchmail: analyzing Received line:
Received: from [84.180.114.162] by freemailng0902.web.de with HTTP;
 Mon, 06 Nov 2006 11:31:44 +0100
fetchmail: line rejected, freemailng0902.web.de is not an alias of the mailserver
About to rewrite From: Rico Hallbauer <externer_user@web.de>
Rewritten version is From: Rico Hallbauer <externer_user@web.de>

About to rewrite To: musterfrau@firma.de
Rewritten version is To: musterfrau@firma.de

fetchmail: passed through musterfrau@firma.de matching tul-tec.de
fetchmail: SMTP< 220 slox ESMTP Postfix
fetchmail: SMTP> EHLO localhost
fetchmail: SMTP< 250-slox
fetchmail: SMTP< 250-PIPELINING
fetchmail: SMTP< 250-SIZE 30000000
fetchmail: SMTP< 250-VRFY
fetchmail: SMTP< 250-ETRN
fetchmail: SMTP< 250-XVERP
fetchmail: SMTP< 250 8BITMIME
fetchmail: forwarding to localhost
fetchmail: SMTP> MAIL FROM:<externer_user@web.de> BODY=7BIT SIZE=1318
fetchmail: SMTP< 250 Ok
fetchmail: SMTP> RCPT TO:<musterfrau@firma.de>
fetchmail: SMTP< 250 Ok
fetchmail: SMTP> DATA
fetchmail: SMTP< 354 End data with <CR><LF>.<CR><LF>
#*****fetchmail: SMTP>. (EOM)
fetchmail: SMTP< 250 Ok: queued as 62F63153F0
 not flushed
fetchmail: POP3> RETR 2
fetchmail: POP3< +OK 1488 octets
reading message m0815@pop.kundenserver.de:2 of 2 (1488 octets)
About to rewrite Return-Path: <externer_userr@web.de>
Rewritten version is Return-Path: <externer_user@web.de>

fetchmail: analyzing Received line:
Received: from [217.72.192.242] (helo=fmmailgate04.web.de)
        by mx.kundenserver.de (node=mxeu25) with ESMTP (Nemesis),
        id 0MKstg-1Gh1m23cjY-0005Zq for musterkind@firma.de; Mon, 06 Nov 2006 11:32:15 +0100
fetchmail: line rejected, mx.kundenserver.de is not an alias of the mailserver
fetchmail: analyzing Received line:
Received: from [84.180.114.162] by freemailng0902.web.de with HTTP;
 Mon, 06 Nov 2006 11:32:14 +0100
fetchmail: line rejected, freemailng0902.web.de is not an alias of the mailserver
About to rewrite From: Rico Hallbauer <externer_user@web.de>
Rewritten version is From: Rico Hallbauer <externer_user@web.de>

About to rewrite To: musterkind@firma.de
Rewritten version is To: musterkind@firma.de

fetchmail: passed through musterkind@firma.de matching tul-tec.de
fetchmail: forwarding to localhost
fetchmail: SMTP> MAIL FROM:<externer_user@web.de> BODY=8BITMIME SIZE=1488
fetchmail: SMTP< 250 Ok
fetchmail: SMTP> RCPT TO:<musterkind@firma.de>
fetchmail: SMTP< 250 Ok
fetchmail: SMTP> DATA
fetchmail: SMTP< 354 End data with <CR><LF>.<CR><LF>
#*****fetchmail: SMTP>. (EOM)
fetchmail: SMTP< 250 Ok: queued as B07A8153F1
 not flushed
fetchmail: POP3> QUIT
fetchmail: POP3< +OK POP server signing off
fetchmail: 5.9.13 querying pop.kundenserver.de (protocol POP3) at Mon, 06 Nov 2006 11:34:11 +0100 (CET): poll completed
fetchmail: not swapping UID lists, no UIDs seen this query
fetchmail: SMTP> QUIT
fetchmail: SMTP< 221 Bye
fetchmail: Writing fetchids file.
fetchmail: normal termination, status 0
fetchmail: Writing fetchids file.


PS.: Nochmal zur Erinnerung - beim ServiceProvider existiert lediglich ein Multidrop-Postfach *@firma.de!
 
P

pft

was heißt hier Teilerfolg? Aus meiner Sicht tut fetchmail jetzt.

Ein Duplizieren / Zurückschicken kann ich in diesem log nicht erkennen.
Würde mich aber nicht wundern wenn postfix da die Finger im Spiel hat - die config bzw. das verhalten kam mir gleich komisch vor.
Laß uns mal einen Blick auf config (main.cf) und log werfen.
An localdomains liegt es aus meiner Sicht nicht.

zu deiner Frage wg. localdomains:
Es sollte doch als lokale Domaine eigentlich meine firma.local betrachtet werden?
Zum Vergrößern anklicken....
Das ist doch Quark. Was soll denn bitte eine lokale Domäne sein? Du
willst Duoch die Mails an "firma.de" lokal, d.h. auf diesem Rechner empfangen, oder? Das Empfangen ist entscheidend nicht das Senden. Du schreibst Doch auch deine öffentlich bekannte Hausnummer draussen an die Tür und nicht die Adresse des Postboten.

fetchmail prüft die TO Zeile des Mail headers. Nur wenn er dort eine bekannte domain findet leitet er die Mail an localhost weiter. Da Du vermutlich hostname bzw. mydomain standardmäßig auf "firma.local" gesetzt hast, kann er ja nicht wissen, dass er "firma.de" lokal zustellen soll, also musst Du es ihm sagen.
Eigentlich hätte ich gedacht dass man die man-page durchaus dahingehend verstehen kann :wink: Lesen übt!

Darüber hinaus halte ich es für unsinnig intern undextern unterschiedliche Mailadressen zu verwenden. Wofür soll das gut sein?
Wenn Du dein System richtig konfigurierst (v.a. postfix) dann weiß es das Mails an firma.de lokal zugestellt werden. Dabei ist es wurscht ob die von draussen oder von drinnen kommen.
Du hast ein leistungsfähiges IT-System also belaste nicht deine User mit so 'nem Quatsch.
Im übrigen hättest Du dir dan die Probleme mit Fetchmail auch erspart.

Strenggenommen (nur mal zwecks der Logik - ohne praktischen Wert) müßtest Du alle domains für die Du Mailsempfangen willst bei localdomains eintragen also auch firma.local. Da die aber nur für internen versand verwendet wird sollten solche mails nicht bei fetchmail vorbeikommen.
 
OP
M

magic_halli

So, es geht nun mit folgender fetchmailrc:
Code: 
poll pop.kundenserver.de envelope 'Envelope-To:' with proto POP3
no dns
localdomains firma.de
user 'm0815' with pass 'geheim1' to 'k.musterkind'='musterkind' 'm.musterfrau'='musterfrau'
here keep
antispam 554
Jetzt wird je nach Empfängeradresse auf die internen Konten verteilt.
Das Duplizieren bzw. zurückschicken von Mails erfolgt dann, wenn eine Mail z.B. an postmaster@firma.de gesendet wurde, fetchmail alle Mails holt, aber der lokale User postmaster (dieser ist noch nicht angelegt) nicht angelegt ist! Soviel hab ich rausbekommen durchs testen.

Ergo: Ich muss also erstmal alle Benutzer lokal anlegen, für die auch eine Mailadresse existiert und in der fetchmailrc sämtliche Benutzer und deren Mailadress-Anfang (wie oben im fetchmailrc-Code) vereinbaren... Zum Glück sind wir hier nicht viele Leute :wink:

...was mich in dem Zuge interessiert: Wie macht man das, wenn die Firma z.B. 100 Mitarbeiter hat??? Für alle 100 in der fetchmailrc die Eintragungen vornehmen ist aber auch heftig!
Oder gibts da vielleicht noch eine andere Möglichkeit das Ganze zu vereinfachen (vielleicht irgendwie die zentrale Nutzerverwaltung anzapfen und mit Variablen arbeiten - nur so ein Gedanke?)?


Gruß.
 
P

pft

hallo,

von wegen zurückschicken von Mails unbekannter Nutzer
Das ist eine Frage der Konfiguration und läßt sich verhindern mit
Code: 
set no bouncemail
Wohin diese Mails gehen legst Du fest mit
Code: 
set postmaster name
Das ist aber noch was anderes als die angeblich duplizierten Mails von vorhin.

von wegen große Firma:
Diese Frage zeigt, dass Du nicht weißt was Du hier tust.
Multidrop Mailboxen sind dafür absolut der falsche Weg. Die haben nämlich ein paar massive Einschränkungen, vor allem bei BCC und mailing listen. bei großen und auch kleinen Firmen sieht der Mail-setup etwas anders aus.

Lies bitte dringend :evil: den Abschnitt dazu in der fetchmail man-page
http://fetchmail.berlios.de/fetchmail-man.html#35
vor allem
http://fetchmail.berlios.de/fetchmail-man.html#38
!! YOU HAVE BEN WARNED!!

sonst wirst Du dich evtl. noch heftig wundern, bzw. ärgern.
Du kannst probieren die Probleme durch Nutzung der envelope option teilweise zu beheben. geht bei mir zufriedenstellend, ist aber auch vom Provider abhängig.
Auf Nummer sicher gehst Du wenn du Multidrop gar nicht verwendest und alle user auf der providerseite explizit anlegst (statt *@firma.de). Voraussetzung ist dass Dein Vertrag das hergibt. Arbeit macht das schon.
 
OP
M

magic_halli

Ich hab die Einschränkungen zwecks BCC und Mailing-Listen schon gelesen (Mails können nicht beim User ankommen wg. nicht individueller recipient adress usw. - leuchtet mir auch ein), aber was soll ich machen, wenn wir nun mal so eine Multidrop-Mailbox haben?!?!
Bis vor kurzem hatten wir fest angelegte User-Mailboxen beim Provider, aber das ist jetzt umgestellt wurden und soll auch so bleiben! Also muss ich nun wohl oder übel damit leben :cry:



Du kannst probieren die Probleme durch Nutzung der envelope option teilweise zu beheben. geht bei mir zufriedenstellend...
Zum Vergrößern anklicken....
Wie behebst Du solche Probleme anhand der envelope option - hast Du ein Beispiel zur Hand?


EDIT: Hab mir grade EINE Mail von web.de an musterfrau- und musterkind@firma.de geschickt. Die kam bei beiden Usern im Postfach an!
 
P

pft

wg. envelope:
Du hast da ja schon was eingetragen. Es bleibt zu testen ob es hilft. Ein Blick in die Mail-Header zeigt Dir was der MTA deines Providers hier leistet, oder nicht. Woruaf Du achten musst weißt Du ja.
Wie das bei mir genau geht müßte ich nachsehen. Geht im Moment aber nicht :(

wg.
wenn wir nun mal so eine Multidrop-Mailbox haben
Zum Vergrößern anklicken....
Das ist Käse. Eine Multidrop Mailbox hat man nicht so einfach. Es ist ein freiwilliger Betriebsmodus. Es ist deine Entscheidung!

Normalerweise kannst Du durch administrative Tätigkleiten an der entsprechenden Oberfläche deines Providers den * durch einen Usernamen ersetzen.
Meistens/oft kann man sogar mehrere einrichten mit separatem Passwort. Wenn zu wenige Usernamen möglich sind, dann hast Du einfach den falschen Vertrag.
 
OP
M

magic_halli

Das ist Käse. Eine Multidrop Mailbox hat man nicht so einfach. Es ist ein freiwilliger Betriebsmodus. Es ist deine Entscheidung!
Zum Vergrößern anklicken....

Nein nein, Du verstehst mich falsch! Ich bin hier nicht der Chef - mein Chef hat das so entschieden und angelegt!!!
Bis letzte Woche hatten wir keine Multidrop, sondern für jeden User eine Mailbox mit Passwort beim Provider liegen - aber eben nur bis letzte Woche :cry:

Frag mich nicht warum, wieso, weshalb... mir wäre es mit festen Mailbox-Accounts für jeden User auch lieber.

Aber nochmal zum mailen: Ich hab inzwischen mehrere Mails mit jeweils mehreren Empfängern (an @firma.de und @web.de) von web.de aus losgeschickt. Egal wieviel Empfänger im Header (bei Envelope-To:) stehen, die Mail kommt immer beim richtigen User im lokalen Postfach an. Anscheinend gibts da bis jetzt keine Probleme bei mir?!
EDIT: ...ich weiß auch warum: In der Inbox beim Provider liegen bspw. 2 Mails, wenn ich von web.de aus in der "An"-Zeile musterfrau- und musterkind@firma.de reinschreibe!!! AHA-wieso das? Ist das auch Provider-Sache... das der das vielleicht, je nachdem, an wieviele Leute die Mail gehen soll, aufsplittet?
 
P

pft

wg. Chef: mußt Du wohl noch Überzeugungarbeit leisten :(

wg. envelope: ja wenn das in den Header geschrieben wird ist's ja gut, nur tun das nichtz alle MTA, . deswegen sagte ich ja es ist provider abhängig.
Das Poblem ist ja gerade, dass im Header nur TO und CC stehen, aber für die Zustellung ENVELOPE-TO gebraucht wird. der MTA deines Providers ist halt so nett und erstellt aus dem envelope eine zusätzliche optionale header-zeile.

Das gleiche gilt für die Anzahl der Mails bei zwei Adressaten aus dem Zuständigkeitsbereich Deiner Mailbox.
 
Status
Für weitere Antworten geschlossen.
Oben