postfix hat ärger mit DNS

[kolvar]

Hallo,

ich sitze derzeit an einem debian-server, der bereits in Betrieb ist, den ich nicht selbst konfiguriert habe, von dem ich auch nur sehr langsam neben meiner normalen Arbeit etwas Ahnung bekomme und der auch schon mal richtig lief ... bis der externe DNS (uni-hannover) mal wieder unten war. Seitdem gibt es Probleme mit dem Mailversand. Damit überhaupt erst mal wieder was ging, habe ich chroot rausgenommen. Seitdem gehen die normalen Mails mit dem eingestellten Delay raus und rein. Nur die Admin-Mails (d.h. die, die von root an zwei externe Adressen gehen sollen) bleiben hängen. mailq gibt mir folgendes aus (namen entsprechend geändert):

E44052C00C85     1013 Fri Mar 31 11:10:39  root@server.dings.bums
(host auth.smtp.kundenserver.de[212.227.15.146] said: 421 dns lookup failed for
                                         admin1@dingser.de
                                         admin2@bumser.net

mail.log sagt folgendes dazu:

Mar 31 11:10:39 debian-server postfix/cleanup[5600]: E44052C00C85: message-id=<2
0060331090542.996602C00C86@server.dings.bums>
Mar 31 11:10:39 debian-server postfix/qmgr[1956]: E44052C00C85: from=<root@serve
r.dings.bums>, size=1013, nrcpt=2 (queue active)
Mar 31 11:10:39 debian-server postfix/local[5604]: CAF822C00C80: to=<root@server
.dings.bums>, relay=local, delay=0, status=sent (forwarded as E44052C00C85)
Mar 31 11:10:39 debian-server postfix/qmgr[1956]: E44052C00C85: to=<admin1@dingser.de>, orig_to=<root@server.dings.bums>, relay=none, de
lay=0, status=deferred (delivery temporarily suspended: deferred transport)
Mar 31 11:10:39 debian-server postfix/qmgr[1956]: E44052C00C85: to=<admin2@bumser.net>, orig_to=<root@server.dings.bums>, relay=none, delay=0, stat
us=deferred (delivery temporarily suspended: deferred transport)

main.cf:

# See /usr/share/postfix/main.cf.dist for a commented, more complete version

smtpd_banner = $myhostname ESMTP $mail_name (Debian/GNU)
biff = no

# appending .domain is the MUA's job.
append_dot_mydomain = no

# Uncomment the next line to generate "delayed mail" warnings
#delay_warning_time = 4h

myhostname = server.dings.bums
mydomain   = dings.bums
alias_maps = hash:/etc/aliases
alias_database = hash:/etc/aliases
myorigin = /etc/mailname
mydestination = localhost.dings.bums, localhost, dings.bums, server.dings.bums
defer_transports = smtp
disable_dns_lookups = yes
softbounce = yes
relayhost = auth.smtp.kundenserver.de
#fallback_relay = localhost
queue_run_delay = 300
mynetworks = 192.168.1.0/24, 127.0.0.1/24
mailbox_command = procmail -a "$EXTENSION"
message_size_limit = 20000000
recipient_delimiter = +
inet_interfaces = all
#
# this line was added to provide f-prot-scans
content_filter = smtp:[127.0.0.1]:10025

Was ich selbst sehe, ist, dass die DNS-Abfrage für die FROM-Adresse falsch läuft. Was ich jedoch nicht verstehe, ist, warum es ehemals lief und jetzt nicht mehr und was ich dagegen tun kann, ohne das System zu schräddern (da es ja live ist). Da ich, wie schon gesagt, wenig Ahnung von der Materie habe, traue ich mich entsprechend nicht, einfach wie wild herumzukonfigurieren und wäre sehr dankbar, wenn mir jemand einen Tipp (oder auch einen Ratschlag, Hilfe etc.) geben könnte.

(oder einen Hinweis darauf, wo ich ansonsten gute Infos dazu finden könnte)

Danke

 

[theton]

Wenn du in Zukunft oefter mit dem Mailserver zu tun hast, wuerde ich dir dringend raten dir das Postfixbuch (http://www.postfixbuch.de/) zuzulegen, denn wenn ich das richtig sehe, hat dein Server keine Authentifizierung drin und ist daher praedestiniert als Spam-Schleuder. Ansonsten tippe ich bei deinem Problem mal auf fehlende oder mit falschen Rechten versehene MBox-Dateien o.ae.. Dein log-Auszug ist da ja nicht sonderlich informativ. Checke auch mal durch, ob die Domains, fuer die der Server Mails entgegen nehmen soll, auch in der main.cf als mydestination eingetragen sind und ob die MX-Records fuer diese Domains noch stimmen. Durch dein (voellig legitimes) abaendern der Domains hast du da einige Verwirrung reingebracht vermute ich mal, da du in der mydestination dings.bums benutzt, aber im Log dann mit dingser.de und bumser.net weiter machst. So kann man natuerlich nicht erkennen, ob alles korrekt eingetragen ist.

Doku zu Postfix findest du z.B. hier:
http://www.kefk.net/Linux/Software/Daemons/Postfix/index.asp
http://www.postfix.org/docs.html

PS: Und sag deinem Chef, dass er dir Zeit geben soll, damit du dich mit Mailservern mal auf nem Test-Rechner vertraut machen sollen. Auch wenn es hart klingen mag, aber Leute wie du, die noch nie mit einem Mailserver zu tun hatten und diesen dann fuer den Produktivbetrieb einrichten sollen, stellen immer wieder sogenannte Open-Relays (also Mailserver, bei denen der Versand von Emails ohne Authentifizierung moeglich ist) ins Netz und sorgen so dafuer, dass die Spammer immer leichteres Spiel haben.

 

[kolvar]

Heissen Dank für die Antwort. Werde ich überprüfen.

Auch danke für den Ratschlag, aber eigentlich haben wir einen Admin, nur dass der unerreichbar Krank ist.

 

[theton]

Schlechter Admin *find*. Ich arbeite auch, wenn ich krank bin, und wenn ich mit nem Laptop im Bett sitzen wuerde. Ich muesste schon halbtot sein, damit ich meine Server-Babys unbeaufsichtigt lasse.

Nachtrag: Und nen Admin, der einen Mailserver ohne Auth aufsetzt, kann nicht gerade gut sein. *glaub*

 

[kolvar]

Er ist wohl halbtot.
Und er hat den nicht aufgesetzt, sondern ihn auch nur übernommen und sich ewig um andere Server kümmern müssen (ich muss ihn jetzt einfach mal in Schutz nehmen). Und frag jetzt nicht, was aus dem vorherigen geworden ist.

 

[theton]

Wahrscheinlich das gleiche, wie aus meinem Vorgaenger. Sitzt jetzt arbeitslos rum und weiss nichts mit sich anzufangen. War aber auch nicht persoenlich gemeint, ich mag nur halt solche potentiellen Spam-Schleudern nicht. Ich weiss ja selbst wie es ist, wenn man als Admin in eine Firma kommt, wo man ein vorhandenes Netzwerk uebernehmen muss, das vorher von jemandem eingerichtet wurde, der nur wenig bis garkeine Ahnung hatte.
Daher meine Empfehlung: Bau dort mal 'ne Authentifizierung fuer's SMTP ein.

 

[kolvar]

Wenn du in Zukunft oefter mit dem Mailserver zu tun hast, wuerde ich dir dringend raten dir das Postfixbuch (http://www.postfixbuch.de/) zuzulegen, denn wenn ich das richtig sehe, hat dein Server keine Authentifizierung drin und ist daher praedestiniert als Spam-Schleuder. Ansonsten tippe ich bei deinem Problem mal auf fehlende oder mit falschen Rechten versehene MBox-Dateien o.ae.. Dein log-Auszug ist da ja nicht sonderlich informativ. Checke auch mal durch, ob die Domains, fuer die der Server Mails entgegen nehmen soll, auch in der main.cf als mydestination eingetragen sind und ob die MX-Records fuer diese Domains noch stimmen. Durch dein (voellig legitimes) abaendern der Domains hast du da einige Verwirrung reingebracht vermute ich mal, da du in der mydestination dings.bums benutzt, aber im Log dann mit dingser.de und bumser.net weiter machst. So kann man natuerlich nicht erkennen, ob alles korrekt eingetragen ist.

So, sitze jetzt endlich wieder vor dem richtigen Computer, um daran zu arbeiten (hatte frei und habe keine Zugänge von aussen).
Intern läuft kein DNS, daran kann es schon mal nicht liegen, die Domänen dings.bums und dingser.de und bumser.net spezifizieren unterschiedliche domänen. dings.bums ist internes Netz, während dingser.de und bumser.net domänen im Netz sind, mit denen der Mailverkehr auch funktioniert. Es ist nur dings.bums, die interne, die verständlicherweise nicht vom externen DNS aufgelöst werden kann. Ich müßte jetzt also dafür sorgen, dass für diese Admin-Mails von root entweder eine Domäne, die es gibt, verwendet wird, oder keine DNS-Abfrage für das MAIL FROM stattfindet. Für letzteres weiss, ich, dass es einen schalter gibt, aber ich wollte es eigentlich nicht abschalten.

Hoffe, die Verwirrung mit den Domänenbezeichnungen, die ich vergeben habe, ist jetzt größer, äh beseitigt.

 

[slasher]

ich mag nur halt solche potentiellen Spam-Schleudern nicht.

woran hast du das ausgemacht ? Kennst du das Umfeld dieses Mailservers so gut, dass du sagen kannst "Spamschleuder"?

Ich weiss ja selbst wie es ist, wenn man als Admin in eine Firma kommt, wo man ein vorhandenes Netzwerk uebernehmen muss, das vorher von jemandem eingerichtet wurde, der nur wenig bis garkeine Ahnung hatte.

oha, hier sprudelt es ja massenhaft Selbstherrlichkeit ...das macht dich glücklich, was ?

Daher meine Empfehlung: Bau dort mal 'ne Authentifizierung fuer's SMTP ein.

Und immer noch ist dir das genaue Umfeld unklar, so dass diese Änderungen eventuell arge Probleme mit sich ziehen können.
Man kann nicht einfach was ändern . In solchen Fällen muss man den eigentlichen Admin kontaktieren und abklären, was geändert werden kann/soll, damit man kein Unheil anrichtet.

 

[theton]

@slasher: Das klaeren wir wohl besser per PM, denn es gehoert hier nicht wirklich zum Thema. Im uebrigen ist dein Beitrag nicht gerade sehr konstruktiv fuer dieses Problem.

@kolvar: Dein Problem ist, dass du keinen Einfluss auf das Mail-Relay des Server-Anbieters hast (kundenserver.de sind meines Wissensmeist root-Server). Du musst also dafuer sorgen, dass diese Mails lokal zugestellt werden. Dazu kannst du z.B. die Eintraege fuer das root-Forwarding (ich vermute mal, sie werden als Alias in der /etc/aliases stehen, wenn nicht dort, dann in der virtual-Tabelle) so aendern, dass sie nicht ueber die interne Domain verschickt werden.

 

[kolvar]

Hatte eine Sache ausprobiert, die aber nicht geklappt hat. ne virtual-table gibts im System nicht, müsste ich dann wohl anlegen. Die Syntax ist mir bisher nicht ganz klar und bin auch nicht sicher: Gilt das dann wirklich auch für MAIL FROM abfragen? Und dazu besteht noch ein Problem, dass die eine Adresse nicht Lokal ist, sonder zu einer anderen Firma gehört.
Für aliases steht eigentlich nur sachen, die direkt auf root (ohne Domain) verweisen.
Ich bin jetzt nur extrem unschlüssig, irgendwas auszuprobieren, weil das System eben schon läuft.