Fetchmail und Envelope-to
Joern Bredereck
Hallo,
gibt's einen Trick, wie ich Fetchmail dazu bekommen kann, bei einem
Multidrop-Pop3-Account den Envelope-To:-Eintrag korrekt auszuwerten?
Meine .fetchmailrc sieht momentan so aus:
poll pop3-server
localdomains meine.domain.tld
envelope 1 Received
proto pop3
user username
pass geheim
is * here
E-Mail, bei denen der Empfaenger nur im Envelope steht, werden aber
weiterhin an den Postmaster geschickt.
Den "envelope 1 Received" Eintrag habe ich einem Posting entnommen, dass
ich bei Deja gefunden habe. Angeblich soll es damit funktionieren. Tuts
aber nicht. Weiss jemand Rat?
Gruss,
jb
Roland Hofmann-Tikkanen
Joern Bredereck <j...@x-networks.de> writes:
>
> Hallo,
>
> gibt's einen Trick, wie ich Fetchmail dazu bekommen kann, bei einem
> Multidrop-Pop3-Account den Envelope-To:-Eintrag korrekt auszuwerten?
In dem man eine richtige .fetchmailrc benutzt ;-)
>
> Meine .fetchmailrc sieht momentan so aus:
>
> poll pop3-server
> localdomains meine.domain.tld
^ ^ ^ Bist Du sicher daß Du das brauchst? Wie heißt Deine
Emailadresse und wie der pop3-server?
> envelope 1 Received
Received ist default und die 1 sagt, wenn ich mich recht erinnere,
daß nicht der letzte, sondern der vorletzte Received:-Header geparst
wird.
>
>
> E-Mail, bei denen der Empfaenger nur im Envelope steht, werden aber
> weiterhin an den Postmaster geschickt.
Entweder ist localdomain oder envelope oder beides falsch.
>
> Gruss,
>
> jb
>
Du hast 2 Alternativen:
Du startest fetchmail -v -v > file und suchst den Fehler dort oder
Du postest hier (oder mailst) Deine Received-Header ohne Änderungen.
Roland
--
------------------------------------------------------------------------
--- Linux auf 63°13,1' Nord 26°52,9' Ost ---
------------------------------------------------------------------------
Martin Lesser
> gibt's einen Trick, wie ich Fetchmail dazu bekommen kann, bei einem
> Multidrop-Pop3-Account den Envelope-To:-Eintrag korrekt auszuwerten?
>
> Meine .fetchmailrc sieht momentan so aus:
> [snip]
Zum Vergleich meine .fetchmailrc, mit der es funktioniert:
poll pop3-server with proto pop3 no dns envelope "Envelope-to"
localdomains ...
user "username" is root * here
password "geheim"
Joern Bredereck
Roland Hofmann-Tikkanen <roland.hofm...@heksela.pp.fi> wrote:
>> gibt's einen Trick, wie ich Fetchmail dazu bekommen kann, bei einem
>> Multidrop-Pop3-Account den Envelope-To:-Eintrag korrekt auszuwerten?
> In dem man eine richtige .fetchmailrc benutzt ;-)
Scherzkeks! :-)
>> Meine .fetchmailrc sieht momentan so aus:
>>
>> poll pop3-server
>> localdomains meine.domain.tld
> ^ ^ ^ Bist Du sicher daß Du das brauchst? Wie heißt Deine
> Emailadresse und wie der pop3-server?
Die Domain heisst "dhpgmbh.de". Der Pop3-Server heisst
"pop.kundenserver.de". Ich bin mir eigentlich ziemlich sicher, dass
Multidrop nur nach Angabe der lokalen Domain funktioniert.
>> envelope 1 Received
> Received ist default und die 1 sagt, wenn ich mich recht erinnere,
> daß nicht der letzte, sondern der vorletzte Received:-Header geparst
> wird.
Seltsam finde ich am Header, dass auf meinem System gleich 2
Received-Header eingfügt werden. Der dritte von Oben ist als erst der
Received-Header meines Providers. Oder ist das wieder relativ zu dem
Zeitpunkt, zu dem fetchmail die Mail pollt? Mir ist die Funktionsweise des
"envelope n Received"-Befehls irgendwie nicht ganz klar.
>> E-Mail, bei denen der Empfaenger nur im Envelope steht, werden aber
>> weiterhin an den Postmaster geschickt.
> Entweder ist localdomain oder envelope oder beides falsch.
Warum sollte localdomain falsch sein? Wenn das der Fall wäre, würden die
anderen Multidrop-Mails doch nicht korrekt gefetched und lokal zugestellt
werden, oder? 99 % aller E-Mails kommen ja an.
> Du hast 2 Alternativen:
> Du startest fetchmail -v -v > file und suchst den Fehler dort oder
> Du postest hier (oder mailst) Deine Received-Header ohne Änderungen.
Okay, hier der komplette Header einer E-Mail die fetchmail nicht korrekt
parsen konnte:
Return-Path: <EE...@CMNC.com>
Received: from localhost (root@localhost [127.0.0.1])
by gateway1.dhpgmbh.de (8.8.8/8.8.8) with ESMTP id HAA04407
for <postmaster@localhost>; Tue, 22 Feb 2000 07:15:25 +0100
Envelope-to: olaf....@dhpgmbh.de
Delivery-date: Mon, 21 Feb 2000 22:02:34 +0100
Received: from pop.kundenserver.de
by localhost with POP3 (fetchmail-5.1.2)
for postmaster@localhost (multi-drop); Tue, 22 Feb 2000 07:15:25 +0100
(CET)
Received: from [208.25.243.2] (helo=[208.25.243.2])
by mx00.kundenserver.de with smtp (Exim 2.12 #2)
id 12Mzxz-0008Lb-00
for olaf....@dhpgmbh.de; Mon, 21 Feb 2000 22:02:03 +0100
Received: from CM_NT_FPS02 by [208.25.243.2]
via smtpd (for mx00.kundenserver.de [195.20.224.67]) with SMTP; 21
Feb 2000 21:02:02 UT
Received: by CM_NT_FPS02 with Internet Mail Service (5.5.2232.9)
id <CPN7SRN6>; Mon, 21 Feb 2000 16:01:10 -0500
Message-ID: <6A884B9FF2B5D211804D00104B9B58470AA975@CM_NT_FPS02>
From: EVELYN EXUM <EE...@CMNC.com>
To: "'Olaf Meyer'" <olaf....@dhpgmbh.de>
Cc: BJ GROSSMAN <BGRO...@CMNC.com>,
"JOHANN PANAIT (CM INTL)"
<jpa...@aol.com>
Subject: InterCo Reconciliation
Date: Mon, 21 Feb 2000 16:01:10 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: multipart/mixed;
boundary="----_=_NextPart_000_01BF7CAE.C7C3C374"
X-Fetchmail-Warning: no recipient addresses matched declared local names
X-AntiVirus: scanned for viruses by AMaViS 0.2.0-pre6
(http://aachalon.de/AMaViS/)
X-UIDL: dd55691b7537c244fb329012abc7d5e3
Man beachte:
X-Fetchmail-Warning: no recipient addresses matched declared local names
Wie gesagt: dhpgmbh.de ist als lokale Domain deklariert und der User
olaf....@dhpgmbh.de steht auch korrekt in der virtusertable drin.
Bei 99 % der E-Mail klappt meine fetchmailrc auch. Nur ab und zu versagt
sie, so wie oben.
Ciao,
jb
Joern Bredereck
Martin Lesser wrote:
> > Meine .fetchmailrc sieht momentan so aus:
> > [snip]
>
> Zum Vergleich meine .fetchmailrc, mit der es funktioniert:
>
> poll pop3-server with proto pop3 no dns envelope "Envelope-to"
> localdomains ...
> user "username" is root * here
> password "geheim"
okay, ich habe den 'envelope "Envelope-to"'-Eintrag mal in meine
.fetchmailrc mit aufgenommen. Vielleicht hilfts was.
Vielen Dank jedenfalls.
Gruss,
jb
Joern Bredereck
>> > Meine .fetchmailrc sieht momentan so aus:
>> > [snip]
>>
>> Zum Vergleich meine .fetchmailrc, mit der es funktioniert:
>>
>> poll pop3-server with proto pop3 no dns envelope "Envelope-to"
>> localdomains ...
>> user "username" is root * here
>> password "geheim"
> okay, ich habe den 'envelope "Envelope-to"'-Eintrag mal in meine
> .fetchmailrc mit aufgenommen. Vielleicht hilfts was.
leider hat auch dieser Eintrag nichts geholfen. Die mail geht immernoch an
den "postmaster@localhost". :-(
Noch irgendwelche Tipps?
Ciao,
jb
Roland Hofmann-Tikkanen
Joern Bredereck <j...@x-networks.de> writes:
> Hallo Roland,
>
> Roland Hofmann-Tikkanen <roland.hofm...@heksela.pp.fi> wrote:
>
>> ^ ^ ^ Bist Du sicher daß Du das brauchst? Wie heißt Deine
>> Emailadresse und wie der pop3-server?
>
> Die Domain heisst "dhpgmbh.de". Der Pop3-Server heisst
> "pop.kundenserver.de". Ich bin mir eigentlich ziemlich sicher, dass
> Multidrop nur nach Angabe der lokalen Domain funktioniert.
Hast recht!
>
>>> envelope 1 Received
>> Received ist default und die 1 sagt, wenn ich mich recht erinnere,
>> daß nicht der letzte, sondern der vorletzte Received:-Header geparst
>> wird.
>
> Seltsam finde ich am Header, dass auf meinem System gleich 2
> Received-Header eingfügt werden. Der dritte von Oben ist als erst der
> Received-Header meines Providers. Oder ist das wieder relativ zu dem
> Zeitpunkt, zu dem fetchmail die Mail pollt? Mir ist die Funktionsweise des
> "envelope n Received"-Befehls irgendwie nicht ganz klar.
Die Received:-Header stehen in der umgedrehten zeitlichen Reihenfolge. Die
2 obersten Header schreibt Dein System rein, Den obersten hat Dein sendmail
und den nächsten vorher fetchmail reingeschrieben. Wer den Envelope-To:
reingeschieben hat, weiß ich nicht, ich vermute der Exim Deines Providers,
bei mir kommt das nicht vor.
Vermutlich gibt es hier wegen des Envelope-to 2 Möglichkeiten, ich beschränke
mich auf die, die ich aus eigener Erfahrung kenne - die Auswertung der
Received:-Header, wie es bei fetchmail default ist.
>
>
> Okay, hier der komplette Header einer E-Mail die fetchmail nicht korrekt
> parsen konnte:
>
> ....
Bis hier her hat Dein System reingeschrieben (Ausnahme: Envelope-To: ?), das
sieht fetchmail nicht, wichtig für fetchmail ist das folgende:
> Received: from [208.25.243.2] (helo=[208.25.243.2])
> by mx00.kundenserver.de with smtp (Exim 2.12 #2)
> id 12Mzxz-0008Lb-00
> for olaf....@dhpgmbh.de; Mon, 21 Feb 2000 22:02:03 +0100
Fetchmail wertet die Domain aus, die hinter 'by' steht (mx00...).
Das muß dann in der fetchmailrc vorkommen mit der Option 'aka'.
Deine fetchmailrc muß folgendermaßen im Serverteil aussehen, den Userteil
lasse ich weg:
poll pop.kundenserver.de
aka mx00.kundenserver.de
localdomains dhpgmbh.de
...
laß das `envelope ...' weg
Ich habe bei mir praktisch die gleichen Verhältnisse.
Ohne das aka kann es hier nicht gehen.
>
> Bei 99 % der E-Mail klappt meine fetchmailrc auch. Nur ab und zu versagt
> sie, so wie oben.
Wäre ganz interessant gewesen, wie der entscheidende Haeder bei Mails,
die klappen, aussieht. Eventuell ändert Dein Provider manchmal die
Aliasnamen des Servers.
>
> Ciao,
>
> jb
Joern Bredereck
Roland Hofmann-Tikkanen <roland.hofm...@heksela.pp.fi> wrote:
>> Received-Header meines Providers. Oder ist das wieder relativ zu dem
>> Zeitpunkt, zu dem fetchmail die Mail pollt? Mir ist die Funktionsweise des
>> "envelope n Received"-Befehls irgendwie nicht ganz klar.
> Die Received:-Header stehen in der umgedrehten zeitlichen Reihenfolge.
soweit hatte ich das noch kapiert.
> Die
> 2 obersten Header schreibt Dein System rein, Den obersten hat Dein sendmail
> und den nächsten vorher fetchmail reingeschrieben. Wer den Envelope-To:
> reingeschieben hat, weiß ich nicht, ich vermute der Exim Deines Providers,
> bei mir kommt das nicht vor.
ok.
>> Okay, hier der komplette Header einer E-Mail die fetchmail nicht korrekt
>> parsen konnte:
>>
>> ....
> Bis hier her hat Dein System reingeschrieben (Ausnahme: Envelope-To: ?), das
> sieht fetchmail nicht, wichtig für fetchmail ist das folgende:
>
>> Received: from [208.25.243.2] (helo=[208.25.243.2])
>> by mx00.kundenserver.de with smtp (Exim 2.12 #2)
>> id 12Mzxz-0008Lb-00
>> for olaf....@dhpgmbh.de; Mon, 21 Feb 2000 22:02:03 +0100
> Fetchmail wertet die Domain aus, die hinter 'by' steht (mx00...).
> Das muß dann in der fetchmailrc vorkommen mit der Option 'aka'.
mhm... eigentlich sollte man aber doch annehmen, dass diese "by
mxXX.kundenserver.de-Zeile IMMER drin steht, oder?
> Deine fetchmailrc muß folgendermaßen im Serverteil aussehen, den Userteil
> lasse ich weg:
> poll pop.kundenserver.de
> aka mx00.kundenserver.de
> localdomains dhpgmbh.de
> ...
> laß das `envelope ...' weg
> Ich habe bei mir praktisch die gleichen Verhältnisse.
> Ohne das aka kann es hier nicht gehen.
okay, habe ich mal so gemacht. Spätestens am Montag weiss ich, ob's
geklappt hat.
>> Bei 99 % der E-Mail klappt meine fetchmailrc auch. Nur ab und zu versagt
>> sie, so wie oben.
> Wäre ganz interessant gewesen, wie der entscheidende Haeder bei Mails,
> die klappen, aussieht.
einen entsprechenden Header werde ich mir mal besorgen, wenn es mit den
von dir eingeschlagenen Einstellungen nicht klappen sollte.
> Eventuell ändert Dein Provider manchmal die Aliasnamen des Servers.
Ja, mag sein... aber pop.kundenserver.de steht wohl nie drin. Von daher
wäre es unlogisch, dass es daran liegt.
Ciao,
jb
Roland Hofmann-Tikkanen
Joern Bredereck <j...@x-networks.de> writes:
> Hallo Roland,
>
> Roland Hofmann-Tikkanen <roland.hofm...@heksela.pp.fi> wrote:
>
>
>> Fetchmail wertet die Domain aus, die hinter 'by' steht (mx00...).
>> Das muß dann in der fetchmailrc vorkommen mit der Option 'aka'.
>
> mhm... eigentlich sollte man aber doch annehmen, dass diese "by
> mxXX.kundenserver.de-Zeile IMMER drin steht, oder?
Es könnte allerdings sein, daß das XX öfters wechselt, wie vor ca.
einem halben Jahr hier jemand gepostet hat. Dann muß die aka-Liste
länger werden.
>
>> Ohne das aka kann es hier nicht gehen.
>
> okay, habe ich mal so gemacht. Spätestens am Montag weiss ich, ob's
> geklappt hat.
Laß was hören.
>
>
> Ciao,
>
> jb
>
Als ich von Singledrop + Procmail auf Multidrop umgestiegen bin, hab'
ich die gleichen Probleme gehabt, bis ich durchgestiegen bin.
Nachdem ich dann 'fetchmail' mit '-v -v > irgend.ein.logfile' laufen
ließ, fand ich die Lösung ziemlich schnell.
Joern Bredereck
>>> Fetchmail wertet die Domain aus, die hinter 'by' steht (mx00...).
>>> Das muß dann in der fetchmailrc vorkommen mit der Option 'aka'.
>>
>> mhm... eigentlich sollte man aber doch annehmen, dass diese "by
>> mxXX.kundenserver.de-Zeile IMMER drin steht, oder?
> Es könnte allerdings sein, daß das XX öfters wechselt, wie vor ca.
> einem halben Jahr hier jemand gepostet hat. Dann muß die aka-Liste
> länger werden.
klar, es ist wohl nicht immer der gleiche MX. Mir ist die Systematik nicht
ganz klar. Ich sage meinem fetchmail er soll bei "pop.kundenserver.de"
pollen. Du vermutest, dass die "by blablabla"-Zeile des leitzten
Received-Headers nicht diesen Eintrag enthält und fetchmail deshalb
durcheinander kommt. Allerdings ist es ja so, dass NIEMALS
"pop.kundenserver.de" in dieser Zeile steht. Und trotzdem klappt es in den
meisten fällen. Das ist für mich einfach unlogisch.
>>> Ohne das aka kann es hier nicht gehen.
>>
>> okay, habe ich mal so gemacht. Spätestens am Montag weiss ich, ob's
>> geklappt hat.
> Laß was hören.
mach ich... bis jetzt gingen anscheinend alle Mails durch.
> Als ich von Singledrop + Procmail auf Multidrop umgestiegen bin, hab'
> ich die gleichen Probleme gehabt, bis ich durchgestiegen bin.
> Nachdem ich dann 'fetchmail' mit '-v -v > irgend.ein.logfile' laufen
> ließ, fand ich die Lösung ziemlich schnell.
okay, das werde ich auch mal machen.
Ciao,
jb
Florian Mühlbauer
Hallo ich hoffe das diesen Post noch jemand mit liest und mir jemand helfen kann.
Ich habe ein ähnliches Problem und zwar das die Nachrichten vom Server abgeholt werden
aber keinem Postfach zugeördnet werden auch nicht dem Postmaster.
meine "alten Domains" funktionieren ohne probleme nur
die neue Domain von all-inkl.com klappt leider nicht.
Hier mal der Header im WebMail
############################
Return-Path: <absenderadresse @me.com>
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on
1234.kasserver.com
X-Original-To: in...@neuedomain.de
Delivered-To: ab...@1234.kasserver.com
############################
Mein Fetchmail sieht wie folgt aus.
############################
poll xyz.kasserver.com with
proto POP3
aka 1234.kasserver.com
envelope "X-Orginal-To:"
localdomains neuedomain.de
user 'user' there with
password 'secret'
dropdelivered to * here
smtphost fw.altedomain.de
############################
Ich hoffe jemand hat einen Tip für mich
DANKE
Thomas Hochstein
> X-Original-To: in...@neuedomain.de
[...]
> envelope "X-Orginal-To:"
Ist der Typo da auch in der Datei oder nur hier im Posting?
--
Informationen rund um E-Mail und Mailserver:
<https://th-h.de/net/mail/>
Florian Mühlbauer
envelope 'X-Orginal-To:'
Habe die Anführungen mit ' oder " probiert leider ohne änderung meines problems.
Inzwischen bekomme ich einen Mailfehler zurück an den Absender
Diagnostic-Code: X-Postfix; mail forwarding loop for
us...@789.kasserver.com
Thomas Hochstein
> Thomas Hochstein schrieb am Donnerstag, 17. März 2022 um 20:15:03 UTC+1:
> > > envelope "X-Orginal-To:"
> >
> > Ist der Typo da auch in der Datei oder nur hier im Posting?
>
> envelope 'X-Orginal-To:'
Florian Mühlbauer
Leider liegt es noch wo anders da die mails immer zurück an den Absender gehen mit dem Mailloop
Florian Mühlbauer
Im Header steht zwar X-Original-To wenn man in der Fetchmailrc envelope "X-Envelope-To:" dann klappt es .......
Evtl. hilft das ja jemanden weiter.