Archiv verlassen und diese Seite im Standarddesign anzeigen : bekomme die Mailverteilung einfach nicht hin
Hi@all,
nachdem ich nun schon ewig damit herum experimentiere und es einfach nicht schaffe das Problem zu lösen wende ich mich damit nochmal an euch.
Ich habe einen Mailserver aufgesetzt mit cyrus IMAP, Postfix und fetchmail aufgesetzt. Beim Provider gibt es lediglich eine Sammelbox in welcher alle Mails landen. Die Verteilung soll dan auf dem lokalen Server mittels Sieve erfolgen.
Die Sammelbox beim ISP lautet '@externe_domain.de'. Auf dem lokalen IMAP-Server gibt es die Mailbox:
user.sven
Nun sende ich von extern eine Mail an 'sven@externe_domain.de'. Im Webinterface beim Provider kann ich auch kontrollieren das sie eintrifft.
Nun hole ich die Mail mit dem Befehl:
fetchmail -v --smtpaddress dreampixel.de -f /etc/fetchmailrc
ab. Die Datei /etc/fetchmailrc sieht so aus:
poll "pop3.externe_domain.de" protocol POP3 aka externe_domain.de : user "@externe_domain.de" there with password "geheim" is "*" here ;
Meine /etc/postfix/main.cf sieht so aus:
command_directory = /usr/sbin
daemon_directory = /usr/lib/postfix
mail_owner = postfix
unknown_local_recipient_reject_code = 450
debug_peer_level = 2
debugger_command =
PATH=/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin
xxgdb $daemon_directory/$process_name $process_id & sleep 5
sendmail_path = /usr/sbin/sendmail
newaliases_path = /usr/bin/newaliases
mailq_path = /usr/bin/mailq
setgid_group = maildrop
manpage_directory = /usr/share/man
sample_directory = /usr/share/doc/packages/postfix/samples
readme_directory = /usr/share/doc/packages/postfix/README_FILES
mail_spool_directory = /var/mail
canonical_maps = hash:/etc/postfix/canonical
virtual_maps = hash:/etc/postfix/virtual
relocated_maps = hash:/etc/postfix/relocated
transport_maps = hash:/etc/postfix/transport
sender_canonical_maps = hash:/etc/postfix/sender_canonical
masquerade_exceptions = root
masquerade_classes = envelope_sender, header_sender, header_recipient
myhostname = postgirl.dreampixel
program_directory = /usr/lib/postfix
inet_interfaces = all
masquerade_domains = dreampixel.de
mydestination = $myhostname,localhost.$mydomain,$mydomain
defer_transports =
disable_dns_lookups = no
relayhost = smtp.dreampixel.de
content_filter =
mailbox_command =
mailbox_transport = lmtp:unix:/var/lib/imap/socket/lmtp
smtpd_sender_restrictions = hash:/etc/postfix/access
smtpd_client_restrictions =
smtpd_helo_required = no
smtpd_helo_restrictions =
strict_rfc821_envelopes = no
smtpd_recipient_restrictions = permit_mynetworks,reject_unauth_destination
smtp_sasl_auth_enable = yes
smtpd_sasl_auth_enable = no
smtpd_use_tls = no
smtp_use_tls = no
alias_maps = hash:/etc/aliases
mailbox_size_limit = 0
message_size_limit = 10240000
smtp_sasl_security_options =
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
Mein sieve Skript sieht so aus:
require "fileinto";
if header :contains ["to"] "sven" {
fileinto "user.sven.INBOX";
}
Das Filtersktipt ist auch aktiv. Nachdem dem Aufruf von fetchmail ist die Mail beim Provider auch weg. Jedoch kommt in:
user.sven.INBOX nichts an. Hat jemand eine Idee für mich :rolleyes:
Viele Grüße
pixel
Gibt es einen bestimmten Grund dafür, dass Du das nicht von Postfix erledigen lässt? Ich weiss es nicht auswendig, aber die virtual-table müsste dafür zuständig sein. Jedenfalls klappt das bei mir relativ gut. Was nicht funktioneirt, sind die forwarder, also wenn userX von seiner Domain ein forward auf das Sammelpostfach einrichtet, klappt das nicht sauber, allerdings verschwinden auch diese Mails nicht.
mamue
Hi@all,
Gibt es einen bestimmten Grund dafür, dass Du das nicht von Postfix erledigen lässt?
Eigentlich nicht. Ich hatte es zuerst auch mit den virtual tables versucht und damit hat es auch nicht geklappt.
Nun habe ich folgendes gemacht:
Die sieve Regeln wieder komplett gelöscht und in /etc/postfix/virtual den Eintrag:
@[externe_domain] @[hostname].[interne_domain]
angefügt und anschließend postfix neu gestartet. Nun habe ich wieder ein Mail an das externe Postfach geschickt und wiederum die Mails mit:
fetchmail -v --smtpaddress [interne_domain] -f /etc/fetchmailrc
ab. Ist der fetchmail-Aufruf bzw. die fetchmailrc den richtig. In der fetchmailrc steht ..... aka externe_domain.de .......
Ist es richtig hier die extrne Domain anzugeben?
Hier noch ein Auszug aus der fetchmail-Ausgabe:
[...]
fetchmail: POP3> DELE 9
fetchmail: POP3< +OK Deleted.
fetchmail: POP3> LIST 10
fetchmail: POP3< +OK 10 1479
fetchmail: POP3> TOP 10 99999999
fetchmail: POP3< +OK headers follow.
reading message @dreampixel.de@pop3.dreampixel.de:10 of 14 (1479 octets)
fetchmail: SMTP> MAIL FROM:<test@dreampixel.de> BODY=8BITMIME SIZE=1479
fetchmail: SMTP< 250 Ok
fetchmail: SMTP> RCPT TO:<*@dreampixel>
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 6F654821F64
flushed
fetchmail: POP3> DELE 10
[...]
Viele Grüße
pixel
Hi@all,
mamue hat mich in einer PM da auf ne Idee gebracht. Kann es daran liegen das die lokalen Benutzer nicht in passwd sondern NUR im LDAP existieren?
Das komplette PAM ist zwar auf den LDAP angepasst jedoch gibt es für Postfix keine Datei in:
/etc/pam.d/
kann es daran liegen das er die Empfänger nicht auflösen kann?
Viele Grüße
pixel
Terran Marine
27.09.04, 19:31
kann es daran liegen das er die Empfänger nicht auflösen kann?
l
Sowas müsste sich aber im Log finden lassen, schonmal probiert die Logausgabe in postfix zu erhöhen, indem du den Parameter -v (vv) in der master.cf angehängt hast ?
Gruß
Terran
indem du den Parameter -v (vv) in der master.cf angehängt hast ?
Wie einfach am ende in eine neue Zeile
[...]
-v
schreiben?
Viele Grüße
pixel
Terran Marine
27.09.04, 19:58
Wie einfach am ende in eine neue Zeile
[...]
-v
schreiben?
Viele Grüße
pixel
Sorry, nein.
in die Zeile mit smtp inet, ans ende der zeile aus dem "smtpd" ein "smtpd -v" machen.
Erhöht die Logausgabe für smtpd Komponente.
ok werde ich gleich mal testen. Nun habe ich mir selbst einen externen Account eingerichtet um mir auch selbst von außerhalb Testmail zusenden zu können und siehe da.
Obwohl die Mail an 'sven@interne_domain.de' abgeholt wurde bekommt der Absender folgende Fehlermeldung:
I'm sorry to have to inform you that the message returned
below could not be delivered to one or more destinations.
For further assistance, please send mail to <postmaster>
If you do so, please include this problem report. You can
delete your own text from the message returned below.
The Postfix program
<*@dreampixel.postgirl.dreampixel>: Name service error for
name=dreampixel.postgirl.dreampixel type=A: Host not found
Er mischt hier irgendwie die lokale Domain mit der externen und dem Hostnamen.
dreampixel.de ist die externe
dreampixel (ohne TopLevel) ist die interne
postgirl ist der hostname des lokalen Mailserver
woran kann das liegen?
ok. Mit Parameter -v habe ich versucht. Anschließend postfix neu gestartet aber es kommt keine einzige Zeile von postfix im Logfile
Viele Grüße
pixel
Terran Marine
27.09.04, 20:31
Deine conf sieht auch komisch aus,
du hast bsp. mydomain und myorigin nicht gesetzt.
myorigin (Absenderdomäne) ist damit auf myhostname gesetzt, d.h. alle internen Mails werden mit dem Absenderdoman postgirl.dreampixel abgeschickt.
Den Sinn von masquerade_domains kann ich auch nicht erkennen, sorry.
masquerade_domains ist für diesen Verwendungszweck schon richtig. Zumindest laut Postfix-Buch
[...]
Aus Markus@lektor.postfixbuch.de wird markus@postfixbuch.de
[...]
Alternativ können Sie aber auch schon Postfix auf den Clients anweisen Mailadressen nur mit der Maildomain, und nicht mit dem Hostnamen zu versehen. Postfix nutzt dafür die Variable $myorigin, ...
[...]
Wenn ich vom Client aus ein Mail über den lokalen Mailserver versende und mir dort wo sie ankommt den Head anschaue ist diese absolut richtig. Vom Hostname ist nichts zu sehen.
Viele Grüße
pixel
Hi@all,
ok ich habe was gefunden. Ich habe immer im syslog geschaut. Ein Blick in /var/log/mail wird da schon mehr bringen. Sorry.
Beim fetchmail Aufruf mit:
fetchmail -D dreampixel -f /etc/fetchmailrc
steht im Log:
[CODE]Sep 27 23:13:42 postgirl postfix/smtpd[5223]: connect from localhost[127.0.0.1]
Sep 27 23:13:42 postgirl postfix/smtpd[5223]: 2D943821F5E: client=localhost[127.0.0.1]
Sep 27 23:13:42 postgirl postfix/cleanup[5225]: 2D943821F5E: message-id=<37458.217.229.94.58.1096317898.squirrel@217.229.94 .58>
Sep 27 23:13:42 postgirl postfix/qmgr[5078]: 2D943821F5E: from=<test@dreampixel.de>, size=1766, nrcpt=1 (queue active)
Sep 27 23:13:42 postgirl postfix/smtpd[5223]: disconnect from localhost[127.0.0.1]
Sep 27 23:13:43 postgirl postfix/smtp[5226]: 2D943821F5E: to=<*@dreampixel.postgirl.dreampixel>, orig_to=<*@dreampixel>, relay=smtp.dreampixel.de[193.178.169.58], delay=1, status=sent (250 Ok: queued as AD8D41C7379)
Sep 27 23:13:43 postgirl postfix/qmgr[5078]: 2D943821F5E: removed[/CODIch denke mal das die markierte Zeile das Problem ist jedoch babe ich nun keine Idee mehr wie es zu beheben ist.
Die virtuelle Domain ist ja für die Zuordnung der eingehenden Mails zuständig. Dort habe ich mitlerweile:
sven@dreampixel.de sven@localhost
simone@dreampixel.de simone@localhost
drin stehen da ich im Web einige Hinweise gefunden habe das dies richtig wäre.
Viele Grüße
pixel
Terran Marine
28.09.04, 08:59
Hi@all,
ok ich habe was gefunden. Ich habe immer im syslog geschaut. Ein Blick in /var/log/mail wird da schon mehr bringen. Sorry.
Beim fetchmail Aufruf mit:
fetchmail -D dreampixel -f /etc/fetchmailrc
steht im Log:
Sep 27 23:13:42 postgirl postfix/smtpd[5223]: connect from localhost[127.0.0.1]
Sep 27 23:13:42 postgirl postfix/smtpd[5223]: 2D943821F5E: client=localhost[127.0.0.1]
Sep 27 23:13:42 postgirl postfix/cleanup[5225]: 2D943821F5E: message-id=<37458.217.229.94.58.1096317898.squirrel@217.229.94 .58>
Sep 27 23:13:42 postgirl postfix/qmgr[5078]: 2D943821F5E: from=<test@dreampixel.de>, size=1766, nrcpt=1 (queue active)
Sep 27 23:13:42 postgirl postfix/smtpd[5223]: disconnect from localhost[127.0.0.1]
Sep 27 23:13:43 postgirl postfix/smtp[5226]: 2D943821F5E: to=<*@dreampixel.postgirl.dreampixel>, orig_to=<*@dreampixel>, relay=smtp.dreampixel.de[193.178.169.58], delay=1, status=sent (250 Ok: queued as AD8D41C7379)
Sep 27 23:13:43 postgirl postfix/qmgr[5078]: 2D943821F5E: removed
Er nimmt die Mail an, leitet sie an den relayhost smtp.dreampixel.de weiter und löscht sie dann wieder.
postfix zeigt also normales Verhalten, die Conf ist falsch.
Da dreampixel.postgirl.dreampixel nicht in mydestination eingetragen ist, schickt er die Mail an relayhost weiter.
(Alle Domänen, die nicht in mydestination stehen,werden bei gesetztem relayhost an diesen weitergeleitet)
Hi,
ich vetehe es leider nicht ganz und hoffe ich geh dir damit auf die Nerven :rolleyes:
Er nimmt die Mail an, leitet sie an den relayhost smtp.dreampixel.de weiter und löscht sie dann wieder.
Aber genau das soll er doch nicht machen. Er soll die Mail doch nicht wieder an den externen Mail-Server des Provider leiten? smtp.dreampixel.de ist der Server des Provider, nicht der im LAN.
Da dreampixel.postgirl.dreampixel nicht in mydestination eingetragen ist, schickt er die Mail an relayhost weiter.
Auch damit habe ich ein verständnis-Problem.
Die Variable ist wie folgt gesetzt:
mydestination = $myhostname,localhost.$mydomain,$mydomain
Wenn ich diese nun aufgrund der anderen Variablen auflöse erhalte ich:
myhostname = postgirl.dreampixel
Die Variable $mydomain ist in meiner main.cf nicht definiert. Was passiert nun hierdurch? Für mich ergeben sich drei durch Komma separierte Werte für mydestination
postgirl.dreampixel
localhost.[ungesetzte Variable]
[ungesetzte Variable]
Kann es evtl daran leigen denn mir ich nicht klar wie der Name:
to=<*@dreampixel.postgirl.dreampixel>
zustande kommt? Für mich sieht das aus als wüde er:
1. Den * aus der fetchmailrc nehmen
2. Anschließend das @ setzen da so der User vom Host getrennt wird
3. den Wert den ich beim fetchmail-Aufruf ...-D dreampixel ... übergeben habe
4. Und zu guter letzt $myhostname
setzen. Und diese Logik kapier ich einfach nicht.
Viele Grüße
pixel
Terran Marine
28.09.04, 10:38
Hi,
ich vetehe es leider nicht ganz und hoffe ich geh dir damit auf die Nerven :rolleyes:
Aber genau das soll er doch nicht machen. Er soll die Mail doch nicht wieder an den externen Mail-Server des Provider leiten? smtp.dreampixel.de ist der Server des Provider, nicht der im LAN.
Auch damit habe ich ein verständnis-Problem.
Die Variable ist wie folgt gesetzt:
mydestination = $myhostname,localhost.$mydomain,$mydomain
Wenn ich diese nun aufgrund der anderen Variablen auflöse erhalte ich:
myhostname = postgirl.dreampixel
Die Variable $mydomain ist in meiner main.cf nicht definiert. Was passiert nun hierdurch? Für mich ergeben sich drei durch Komma separierte Werte für mydestination
postgirl.dreampixel
localhost.[ungesetzte Variable]
[ungesetzte Variable]
Du hast drei Werte in mydestination stehen, aufgelöst sind das :
postgirl.dreampixel
localhost.dreampixel
dreampixel
(die letzen beiden ergeben sich durch : mydomain = myhostname - der ersten Komponente)
Die Mails die ankommen, stimmen mit keiner der drei Domänen überein, d.h. für postfix -> weiterleiten an relayhost.
Kann es evtl daran leigen denn mir ich nicht klar wie der Name:
to=<*@dreampixel.postgirl.dreampixel>
zustande kommt? Für mich sieht das aus als wüde er:
1. Den * aus der fetchmailrc nehmen
2. Anschließend das @ setzen da so der User vom Host getrennt wird
3. den Wert den ich beim fetchmail-Aufruf ...-D dreampixel ... übergeben habe
4. Und zu guter letzt $myhostname
setzen. Und diese Logik kapier ich einfach nicht.
Das ist in der Tat etwas komisch, standardmässig bekommen lokal generierte Mails $myorigin angehängt.
Hast du dir schonmal überlegt, ein schönes aktuelles postfix-Buch zu kaufen ?
to=<*@dreampixel.postgirl.dreampixel
Dies kann ich durch den Aufruf von fetchmail beeinflussen.
Wenn ich:
fetchmail -v -S postgirl.dreampixel -f /etc/fetchmailrc
aurufe wird die gleiche Fehlermeldung erzeugt jedoch mit:
.. to=<*@postgirl.dreampixel.....
im Empfänger. Bringt zwar nix da es nach wie vor noch nicht geht aber evtl. bringt das noch jemand auf eine Idee.
viele Grüße
pixel
Hi@all,
ich habe mich nochmal durch die Manpage von fetchmail gekämpft. Allerdings muß ich einräumen das mein Englisch sehr dürftig ist. Ich denke das Problem hängt mit der Auswertung des Mailheaders zusammen. Folgende Optionen könnten doch da von Bedeutung sein. Kann da mal jemand drüber lesen?
-E <line> | --envelope <line>
(Keyword: envelope) This option changes the header fetchmail assumes will carry a copy of the mail's enve-
lope address. Normally this is `X-Envelope-To' but as this header is not standard, practice varies. See the
discussion of multidrop address handling below. As a special case, `envelope "Received"' enables parsing of
sendmail-style Received lines. This is the default, and it should not be necessary unless you have globally
disabled Received parsing with `no envelope' in the .fetchmailrc file.
-Q <prefix> | --qvirtual <prefix>
(Keyword: qvirtual) The string prefix assigned to this option will be removed from the user name found in
the header specified with the envelope option (before doing multidrop name mapping or localdomain checking,
if either is applicable). This option is useful if you are using fetchmail to collect the mail for an entire
domain and your ISP (or your mail redirection provider) is using qmail. One of the basic features of qmail
is the
`Delivered-To:'
message header. Whenever qmail delivers a message to a local mailbox it puts the username and hostname of
the envelope recipient on this line. The major reason for this is to prevent mail loops. To set up qmail
to batch mail for a disconnected site the ISP-mailhost will have normally put that site in its `Virtual-
hosts' control file so it will add a prefix to all mail addresses for this site. This results in mail sent
to 'username@userhost.userdom.dom.com' having a `Delivered-To:' line of the form:
Delivered-To: mbox-userstr-username@userhost.userdom.dom.com
The ISP can make the 'mbox-userstr-' prefix anything they choose but a string matching the user host name is
likely. By using the option `envelope Delivered-To:' you can make fetchmail reliably identify the original
envelope recipient, but you have to strip the `mbox-userstr-' prefix to deliver to the correct user. This
is what this option is for.
Viele Grüße
pixel
Hiqall,
un so sieht der Mail-Header aus wenn die Mail beim Provider im Postfach ankommt:
Return-Path: <sven.gehr@kometmetall.de>
X-Original-To: sven@dreampixel.de
Delivered-To: sven@dreampixel.de
Received: from localhost (localhost [127.0.0.1])
by mail2.srv.syswebcom.net (Postfix) with ESMTP id AA20BA937B
for <sven@dreampixel.de>; Tue, 28 Sep 2004 12:06:28 +0200 (CEST)
Received: from mail2.srv.syswebcom.net ([127.0.0.1])
by localhost (mail2 [127.0.0.1]) (amavisd-new, port 10024) with ESMTP
id 13241-04 for <sven@dreampixel.de>; Tue, 28 Sep 2004 12:06:27 +0200 (CEST)
Received: from com.softwareschmied (D8791.d.pppool.de [80.184.135.145])
by mail2.srv.syswebcom.net (Postfix) with ESMTP id 1243919A60D
for <sven@dreampixel.de>; Tue, 28 Sep 2004 12:06:25 +0200 (CEST)
Received: by com.softwareschmied (Postfix, from userid 56641)
id D049124020E36; Tue, 28 Sep 2004 12:10:38 +0200 (CEST)
X-Mailer: OpenGroupware.org
date: Tue, 28 Sep 2004 10:10:38 -0000
content-type: text/plain
To: sven@dreampixel.de
Reply-To: "Sven Gehr" <sven.gehr@kometmetall.de>
From: "Sven Gehr" <sven.gehr@kometmetall.de>
subject: Test3
MIME-Version: 1.0
content-transfer-encoding: quoted-printable
Message-Id: <20040928101038.D049124020E36@com.softwareschmied>
X-Virus-Scanned: by amavisd-new at mail2.srv.syswebcom.net
Wie kann ich den nun fetchmail dazu bringen das Feld:
Delivered-To: sven@dreampixel.de
zumindest den Teil links von @ als lokalen Benutzernamen auszuwerten.
Viele Grüße
pixel
:) :) :) :) Ihr wisst was das bedeutet? Genau ES GEHT.
..... aka dreampixel.de dreampixel .... und schon geht es.
Terran Marine
28.09.04, 22:13
:) :) :) :) Ihr wisst was das bedeutet? Genau ES GEHT.
..... aka dreampixel.de dreampixel .... und schon geht es.
Wie hast du es jetzt genau gelöst ?
..... aka dreampixel.de dreampixel .... und schon geht es.
Ist allerdings nur ein Teil der Wahrheit. Ich konnte ein Problem das bei SuSE-9.1 bzw. der MTA-Yast-Konfiguration herausfinden welches allerdings nur in Zusammenhang mit Multidrop-Boxen besteht.
Wenn man den MTA mit Yast konfiguriert, was ich natürlich möchte, wird eine Zeile wie diese erzeugt:
poll "pop3.dreampixel.de" protocol POP3 : user "@dreampixel.de" there with password "geheim" is "*" here ;
So will man nun Multidrop benutzen muß hinter POP3 die Server-Option aka gefolgt von interner Domain und externer Domain. Dies wiederum setzt voraus das die Zieladresse beim Provider erhalten wird was nicht immer so ist. Bleibt sie nicht erhalten ist anstatt aka die Server-Option localdomains zu verwenden. Also würde die Zeile wie folgt aussehen:
poll "pop3.dreampixel.de" protocol POP3 aka dreampixel.de dreampixel : user "@dreampixel.de" there with password "geheim" is "*" here ;
So ist sie zumindest inhaltlich richtig. Allerdings wird es so nie funktionieren. Yast erzeugt den Teil mit dem lokalen User so:
"*"
entfernt man nun die Anführungszeichen, also nur * klappt alles. Der Preis dafür ist allerding das man anschließedn, wenn man Yast / MTA-Konfiguration startet beim Dialog wo man externen POP-Server etc eingibt nichts mehr sieht d.h. die Masken sind leer. Funktionieren tus aber trotzdem.
Alla, geht doch.
Viele Grüße
pixel
Powered by vBulletin® Version 4.2.5 Copyright ©2024 Adduco Digital e.K. und vBulletin Solutions, Inc. Alle Rechte vorbehalten.