Plesk und Postmaster-Email-Account

D

Dawn

Registered User
Ich bin sicher ihr kennt das Problem ebenfalls. Ich erhalte täglich sehr viele der folgenden Mails:

-------->
Hi. This is the qmail-send program at ispdomain.com.
I tried to deliver a bounce message to this address, but the bounce bounced!
....
-------->

Diese treten auf weil jemand (mit einem falschen Absender) einem meiner Kunden ein Mail schickt und das an eine Email-Adresse welche nicht existiert. Schlussendlich landen Sie also wieder bei mir, bei postmaster@ispdomain.com (welchen ich zu meiner tatsächlen Email-Adresse umleite). Klar könnte ich einfach den Postmaster-Email-Account meines ISP-Domains löschen, doch diese Lösung halte ich für äusserst unsauber.

Darum meine Frage: Wie löst ihr dieses Problem?

Gruss,
Dawn
 
Sehe ich richtig, daß "ispdomain.com" Deine Domain ist?

Falls ja, stellt sich die Frage, wieso es überhaupt zu einer Double-Bounce kommt.

Normalerweise lehnt man doch solche Mails direkt im SMTP-Dialog ab, so daß gar keine Bounce entsteht (bei Plesk z.B. mittels relaylock). Falls Du nicht gerade ein sehr komplexes Weiterleitungsszenario hast (und auch brauchst), sieht mir das einfach nach einer Fehlkonfiguration (z.B. ein Backup-MX, der erstmal alles frißt) aus.
 
Danke für deine Antwort :)

ispdomain.com habe ich nur als Beispiel für meinen tatsächlichen Domainnamen verwendet. Ich habe tatsächlich auch einen Backup-MX-Server, aber liegt es wirklich daran?

Für mich ist der Ablauf relativ logisch und ergibt einen Sinn, nur auf eine vernünftige Lösung komme ich nicht:

  1. Spamer sendet Email mit gefakter Reply-Adresse auf "gut Glück" an eine Email-Adresse eines Kunden.
  2. Diese Email Adresse existiert nicht bzw. existiert nicht mehr. Mailserver bounct diese Mail. Da aber die Reply-Adresse gefakt ist wird die Email wiederum gebounct.
  3. Email landet über den Mailer-Deamon per Default an postmaster@[meine ISP Domain].com
  4. postmaster@[meine ISP Domain].com habe ich zu meiner persönlichen Adresse weitergeleitet, damit ich nicht X Email-Konten abfragen muss und auf dem Laufenden bleibe.

Übersehe ich da irgend etwas, aber ich verstehe wirklich nicht was der MX-Backup-Server damit zu tun haben soll...

Gruss,
Dawn
 
Hallo!
Also das Programm relaylock gehört doch zu qmail. Und in diesem Zusammenhang habe ich den Artikel von Huschi im Hinterkopf.

mfG
Thorsten
 
Hi Thorsten,

Sei mir nicht böse, aber was hat denn das bitte Relaylock damit zu tun?

Vielleicht habe ich auch ein wenig zu knapp formuliert. Ich erhalte dutzende solcher Mails:

Code: 
Subject: failture notice
From: MAILER-DAEMON@meineispdomain.com
To: postmaster@meineispdomain.com

Hi. This is the qmail-send program at meineispdomain.com.
I tried to deliver a bounce message to this address, but the bounce bounced!

<spamer@spamerdomain.com>:
217.74.65.64 does not like recipient.
Remote host said: 550 User not found
Giving up on 217.74.65.64.

--- Below this line is the original bounce.

Return-Path: <>
Received: (qmail 6624 invoked for bounce); 7 Jan 2009 18:40:30 +0100
Date: 7 Jan 2009 18:40:30 +0100
From: MAILER-DAEMON@meineispdomain.com
To: spamer@spamerdomain.com
Subject: failure notice

Hi. This is the qmail-send program at meineispdomain.com.
I'm afraid I wasn't able to deliver your message to the following addresses.
This is a permanent error; I've given up. Sorry it didn't work out.

<rss-abo@kundendomain.de>:
This address no longer accepts mail.

--- Below this line is a copy of the message.

Return-Path: <spamer@spamerdomain.com>
Received: (qmail 6618 invoked from network); 7 Jan 2009 18:40:30 +0100

....

Gruss,
Dawn
 
Hallo!
Sorry Dawn, absolut nichts. Ich habe im flaschen Thread geantwortet. Werde das später korrigieren.

Edit: Doch nicht versehen. Ich bezog das auf die Aussage von Whistler (Beitrag #2) und den Satz:
(bei Plesk z.B. mittels relaylock)
Click to expand...
Es hat eben nichts damit zu tun.

mfG
Thorsten
 
Last edited by a moderator:
Kein Problem.. ;) Dachte schon ich versteh die Linux-Welt nicht mehr *lach* Aber falls du Zeit/bzw. einen guten Vorschlag hast, würde ich mich natürlich sehr freuen.

Gruss,
Dawn
 
Es ist schon verlockend diesen Patch zu nutzen, alternativ könnte ich aber auch einfach postmaster@meineispdomain.com löschen und da ich keinen Catch-All in Plesk eingeschaltet habe, würden diese Mails im Nirvana verschwinden.

Bei Huschi habe ich noch folgendes gefunden: Plesk/Qmail: Bounce-Mails unterbinden - huschi.net

Aber beides ist doch keine "schöne" Lösung... Wie handhabt ihr denn das? Ich hoste momentan ca. 50 Domains und da kommen schon einige Mails zusammen. Ich kann mir kaum vorstellen das ihr euch diese Double-Bounce Mails wirklich anschaut bzw. in einer Mailbox speichert.

Gruss,
Dawn
 
Last edited by a moderator:
Hallo!
Dawn said:
Ich habe momentan ca. 50 Domains gehostet und da kommen schon einige Mails zusammen. Ich kann mir kaum vorstellen das ihr euch diese Double-Bounce Mails wirklich anschaut bzw. in einer Mailbox speichert.
Click to expand...
Bei 50+ Domains unterstelle ich einmal, du betreibst diese im Kundenauftrag. Und die Mails gehören dem Kunden - er sollte sie also auch lesen.

Bei meinen Domains lese ich beispielsweise alle NDNs. Eventuell hilft der Einsatz von SPF, das Ganze etwas einzudämmen.

mfG
Thorsten
 
Sorry, ich habe vermutlich etwas zu knapp geantwortet.

Dawn said:
Danke für deine Antwort :)
2. Diese Email Adresse existiert nicht bzw. existiert nicht mehr. Mailserver bounct diese Mail.
Click to expand...

Genau. Dafür gibt es zwei Möglichkeiten:

1. Dein Mailserver "merkt" es schon bei der Einlieferung.
Dann kann er direkt im SMTP-Dialog mit dem einliefernden Server diese Mail ablehnen.
Qmail z.B antwortet dabei mit einem
Code: 
550 sorry, no mailbox here by that name. (#5.7.17)
Der einliefernde Server ist informiert, keine Bounce-Mail nötig, Finito.

2. Der Mailserver nimmt die Mail erstmal an (Code 250).
In diesem Fall ist er für die weitere Zustellung "verantwortlich". Entscheidet er sich später anders, muß er den Absender darüber informieren, er schreibt eine Bouce.

Dawn said:
Return-Path: <>
Received: (qmail 6624 invoked for bounce); 7 Jan 2009 18:40:30 +0100
Date: 7 Jan 2009 18:40:30 +0100
From: MAILER-DAEMON@meineispdomain.com
To: spamer@spamerdomain.com
Subject: failure notice

Hi. This is the qmail-send program at meineispdomain.com.
I'm afraid I wasn't able to deliver your message to the following addresses.
This is a permanent error; I've given up. Sorry it didn't work out.

<rss-abo@kundendomain.de>:
This address no longer accepts mail.
Click to expand...

Wenn ich annehme, daß "meineispdomain.com" ein Platzhalter für eine von Dir betriebene Domain ist, scheint der 2. Fall zuzutreffen - Dein Server hat die Mail angenommen und erst später festgestellt, daß sie nicht zustellbar ist.

Das ist zumindest verwunderlich, weil Qmail - insbesondere im Zusammenspiel mit Plesk - normalerweise sehr viel Mühe darauf verwendet, Mails gleich anzunehmen oder abzulehnen (Fall 1) und eben nicht später zu bouncen. Insbesonders wenn kundendomain.de und meineispdomain.com auf demselben Server verwaltet werden, sollte sich die Entscheidung eigentlich immer sofort treffen lassen.

Den Backup-MX hatte ich nur deswegen ins Spiel gebracht, weil es eben eine einfache (wenn auch nicht optimale) Konfigurationsmöglichkeit ist, dort nur eine Liste von Kundendomains abzulegen und erstmal Messages mit beliebigem Localpart zu akzeptieren und zu puffern. Die Unzustellbarkeit fällt dann erst bei der Weiterleitung an den primären Mailserver auf -> Bounce nötig.
 
Ganz genau.. Ich habe ganz klein angefangen und mich zuerst 2 Jahre mit Linux im Servereinsatz auseinandergesetzt und mit meinen eigenen Domains "rumprobiert", danach habe ich einige Freunde dazu genommen und mitlerweile betreue ich auch einige Kunden. Sonst würde ich nicht auf 50 Domains kommen..

Ich weiss was du meinst mit "die gehören den Kunden", aber ich kann meine Kunden nicht dazu zwingen (könnte ich schon, aber das kann ja nicht die Lösung sein) Catch-All zu aktivieren, so landen diese Mails gewzungenermassen bei mir.

Ich verwende auf meinen DNS Server den SPF-Eintrag "v=spf1 mx/24 -all" für meine Domains. Der Einsatz von SPF kann ja scheinbar massive Probleme auslösen wie man z.B. hier Sender Policy Framework ? Wikipedia nachlesen kann.

Wenn selbst du und Huschi (hat sich zwar nicht geäussert, aber ich habe auf seiner Seite nichts dazu gefunden) keine "schöne" Lösung für diese Problematik kennen sehe ich keine andere Möglichkeit als dem Email-Account postmaster@meineispdomain.com wirklich eine Mailbox zu geben und dann 1x pro Woche das Ganze abzufragen und mittels Filterregeln auszusortieren.

Gruss und trotzdem big THX,
Dawn

EDIT: Besten Dank für deine Präzisierung Whistler. Ich verstehe ja auch nicht warum Plesk/Qmail dies nicht anders handhabt und denke es gibt sicher sehr viele Hoster welche mit diesem Problem kämpfen. Ich kann nur sagen dass ich Qmail nicht "umkonfiguriert" habe und die original Plesk-Pakete dafür verwende. Genau darum habe ich mich dazu entschlossen, mich hier ans Forum zu wenden...
 
Last edited by a moderator:
Wie weiter oben schon angedeutet habe ich das Problem nicht in diesem Umfang.

Sowas kann schonmal passieren, falls z.B. ein Kunde seine Mails nach T-Online weiterleitet und das dortige Postfach ist voll. Dann gibt es eine Bounce, die u.U. eine Double-Bounce nach sich zieht. In diesem Fall ist das aber auch gerechtfertigt.

Dein geschildertes Problem liegt aber anders.

Du solltest zunächst mal anhand der Logs herausfinden. was zwischen
Received: (qmail 6618 invoked from network); 7 Jan 2009 18:40:30 +0100
Click to expand...
und
Received: (qmail 6624 invoked for bounce); 7 Jan 2009 18:40:30 +0100
Click to expand...
passiert.

"rss-abo" klingt ein wenig nach einem Script oder automatisierten Prozeß - dann müßte man sich die Übergabe dahin ansehen.

Es könnte auch sein, daß qmail micht weiß, das "kundendomain.de" lokal ist und die Mail quasi übers Netzwerk an sich selbst zustellt.


Dein SPF-Record sieht übrigens auch merkwürdig aus.

Falls Du nicht wirklich einen Cluster aus 256 Mailservern betreibst, dürfte das "/24" überflüssig sein.

Stattdessen solltest Du Deine Kunden eventuell mal befragen, wie sie ihre Mails versenden. Falls sie nicht nur Deinen Server dazu benutzen, sondern auch den Smarthost des Providers (z.B. smtprelay.t-online.de), dann muß auch dieser im SPF-Record als legitimer Absender aufgelistet sein. Ansonsten wäre das "-all" massiv kontraproduktiv.
 
Ich glaube ehrlich gesagt nicht das etwas "falsch" konfiguriert ist, die frage ist einfach wie man mit einer solchen Situation umgeht. Wie gesagt, macht das Bouncing eigentlich absolut Sinn...

rss-abo, ist natürlich nur eines von sehr vielen Beispielen. Viele Spamer versuchen z.B. auch einfach blind an info@domain.com Adressen zu senden, und wenn sie dies mit einem gefakten Absender tun, landen dann ebenso die Mails bei mir. Wenn ich da jedem einzelnen Mail auf den Grund gehe, werde ich wohl auch kaum auf einen grünen Zweig kommen...

Ich gehe davon aus das Qmail durchaus weiss das "kundendomain.de" lokal ist, denn sonst würden ganz andere Dinge nicht funktionieren ;)

Ich erlaube nur den Versand direkt über meinen Mailserver. Das funktioniert so prima und ich hatte noch nie Beschwerden deswegen. Jeden "Smarthost" aufzunehmen wäre zudem ziemlich mühsam, wenn nicht sogar fast unmöglich.

Der SPF-Record wird mir von meinem DNS-Server-Anbieter so vorgegeben. Ich könne ihn manuell aber für jeden Domain anpassen. Inwiefern meinst du sei "-all" massiv kontraproduktiv?

Gruss,
Dawn
 
Hallo Ihr Lieben (?) :-)

Ich habe hier ein ähnliches Problem...das ist doch mehr als nen double bounce?!

Plesk 9.3.0 auf SuSE 11, lokaler Hostname ist c162. FQDN ist c162.bla.bla.bla.de, als Domain habe ich hier im text meine-domain.de angegeben, sonst sind die files unverändert. "Normale" bounces empfange ich auch - das klappt.

Jan 26 19:34:04 c162 spf filter[14337]: Starting spf filter...
Jan 26 19:34:05 c162 qmail: 1264530845.108541 bounce msg 57351 qp 14336
Jan 26 19:34:05 c162 qmail: 1264530845.108565 end msg 57351
Jan 26 19:34:05 c162 qmail: 1264530845.108900 new msg 57350
Jan 26 19:34:05 c162 qmail: 1264530845.108919 info msg 57350: bytes 644357 from <postmaster@c162> qp 14338 uid 2522
Jan 26 19:34:05 c162 qmail: 1264530845.221673 starting delivery 918: msg 57350 to remote postmaster@c162
Jan 26 19:34:05 c162 qmail: 1264530845.221696 status: local 1/10 remote 1/20
Jan 26 19:34:05 c162 qmail-remote-handlers[14339]: Handlers Filter before-remote for qmail started ...
Jan 26 19:34:05 c162 qmail-remote-handlers[14339]: from=postmaster@c162
Jan 26 19:34:05 c162 qmail-remote-handlers[14339]: to=postmaster@c162
Jan 26 19:34:05 c162 qmail: 1264530845.227410 delivery 918: failure: Sorry,_I_couldn't_find_any_host_named_c162._(#5.1.2)/
Jan 26 19:34:05 c162 qmail: 1264530845.227436 status: local 1/10 remote 0/20
Jan 26 19:34:05 c162 qmail-queue-handlers[14340]: Handlers Filter before-queue for qmail started ...
Jan 26 19:34:05 c162 qmail-queue-handlers[14340]: from=postmaster@c162
Jan 26 19:34:05 c162 qmail-queue-handlers[14340]: to=postmaster@c162
Jan 26 19:34:05 c162 spf filter[14341]: Starting spf filter...
Jan 26 19:34:05 c162 qmail: 1264530845.364857 bounce msg 57350 qp 14340
Jan 26 19:34:05 c162 qmail: 1264530845.364883 end msg 57350
Jan 26 19:34:05 c162 qmail: 1264530845.365212 new msg 57351
Jan 26 19:34:05 c162 qmail: 1264530845.365230 info msg 57351: bytes 644872 from <postmaster@c162> qp 14342 uid 2522
Jan 26 19:34:05 c162 qmail: 1264530845.488317 starting delivery 919: msg 57351 to remote postmaster@c162
Jan 26 19:34:05 c162 qmail: 1264530845.488338 status: local 1/10 remote 1/20
Jan 26 19:34:05 c162 qmail-remote-handlers[14343]: Handlers Filter before-remote for qmail started ...
Jan 26 19:34:05 c162 qmail-remote-handlers[14343]: from=postmaster@c162
Jan 26 19:34:05 c162 qmail-remote-handlers[14343]: to=postmaster@c162
Jan 26 19:34:05 c162 qmail: 1264530845.494115 delivery 919: failure: Sorry,_I_couldn't_find_any_host_named_c162._(#5.1.2)/
Jan 26 19:34:05 c162 qmail: 1264530845.494146 status: local 1/10 remote 0/20
Jan 26 19:34:05 c162 qmail-queue-handlers[14344]: Handlers Filter before-queue for qmail started ...
Jan 26 19:34:05 c162 qmail-queue-handlers[14344]: from=postmaster@c162
Jan 26 19:34:05 c162 qmail-queue-handlers[14344]: to=postmaster@c162
Jan 26 19:34:05 c162 spf filter[14345]: Starting spf filter...
Jan 26 19:34:05 c162 qmail: 1264530845.645339 bounce msg 57351 qp 14344
Jan 26 19:34:05 c162 qmail: 1264530845.645362 end msg 57351
Jan 26 19:34:05 c162 qmail: 1264530845.645674 new msg 57350
Jan 26 19:34:05 c162 qmail: 1264530845.645690 info msg 57350: bytes 645387 from <postmaster@c162> qp 14346 uid 2522
Jan 26 19:34:05 c162 qmail: 1264530845.766222 starting delivery 920: msg 57350 to remote postmaster@c162
Jan 26 19:34:05 c162 qmail: 1264530845.766243 status: local 1/10 remote 1/20
Jan 26 19:34:05 c162 qmail-remote-handlers[14347]: Handlers Filter before-remote for qmail started ...
Jan 26 19:34:05 c162 qmail-remote-handlers[14347]: from=postmaster@c162
Jan 26 19:34:05 c162 qmail-remote-handlers[14347]: to=postmaster@c162
Jan 26 19:34:05 c162 qmail: 1264530845.772040 delivery 920: failure: Sorry,_I_couldn't_find_any_host_named_c162._(#5.1.2)/
Jan 26 19:34:05 c162 qmail: 1264530845.772070 status: local 1/10 remote 0/20
Jan 26 19:34:05 c162 qmail-queue-handlers[14348]: Handlers Filter before-queue for qmail started ...
Jan 26 19:34:05 c162 qmail-queue-handlers[14348]: from=postmaster@c162
Jan 26 19:34:05 c162 qmail-queue-handlers[14348]: to=postmaster@c162
Jan 26 19:34:05 c162 spf filter[14349]: Starting spf filter...
Jan 26 19:34:05 c162 qmail: 1264530845.911255 bounce msg 57350 qp 14348
Jan 26 19:34:05 c162 qmail: 1264530845.911279 end msg 57350
Click to expand...

defaultdelivery
| /usr/bin/deliverquota ./Maildir
Click to expand...

locals
localhost
localhost.localdomain
Click to expand...

me (Plesk hatte hier keinen FQDN eingetragen, nur das c162)
meine-domain.de
Click to expand...

rcpthosts und rejectnonexist (vorher stand hier nur meine-domain.de, damit er die blöden Mails aber nicht jedes Mal extern versucht habe ich c162 mal mit eingetragen, ändert aber nichts - s. Log... die landen immer noch in der Remotequeue)
meine-domain.de
c162
Click to expand...

virtualdomains
meine-domain.de:12
Click to expand...

Jeglicher Mailverkehr intern und extern geht auch ... nur bekomme ich immer diese Dinger... PAUSENLOS. Sobald ich qmail starte fängt das wieder an. Es ist kein Open Relay oder sonstiges. Auch kann ich reguläre double bounces hiervon unterscheiden.

Als ich vorher mal die c162 in rejectnonexist eingetragen hatte, hatte er auch immer schön geSKIP-ed, da der postmaster account nicht aktiv ist.

Auch ein Anhalten von qmail und leeren der Warteschlange bringt nichts. Mir fällt bestimmt noch weiteres ein - trage ich dann nach. Oder, falls euch eine Info fehlt bitte fragen.

PS: wenn ich bouncefrom and bouncehost und/oder doublebouncefrom und doublebouncehost fülle, ändert sich zwar der Absender des "ersten" bounces aber der Empfänger bleibt IMMER postmaster@c162

Received: (qmail 16685 invoked for bounce); 26 Jan 2010 19:05:38 +0100
Date: 26 Jan 2010 19:05:38 +0100
From: MAILER-DAEMON@meine-domain.de
To: postmaster@c162
Subject: failure notice
Click to expand...

Wenn ich c162 in locals mit eintrage, empfängt er auch die mails lokal und er sendet eine benachrichtung an die in plesk eingestellt server admin adresse (extern) aber dort kommen nur komplett leere Mails an

Kann irgendjemand sehen woher das kommt? VIELEN DANK für jede Antwort!!
 
Last edited by a moderator:
HI genius777, Hallo an alle,

das gleiche Problem habe ich auch. Tausende von Mails an postmaster@plesk-domain.de

Dabei lief ein Core der vier immer auf 100% der Load ist entsprechend hoch.. Nachdem ich dann die postmaster@plesk-domain.de angelegt habe ist der Load runter und der Prozess von qmail-send hat sich beruhigt. :-) Aber iwann wird nun das Postfach voll laufen.

Hat noch jemand die Millionen Postmaster Mails? ICh denke es liegt am letzten Plesk Update, wenn ich mich richtig erinnere wurde da irgendwas in Bezug auf qmail geupdatet.

Bei mir läuft Plesk 9.3.0 unter Debian 4.

Auch das abstellen der Bouncemails wie bei huschi.net beschrieben funktioniert bringt leider nichts.

Gruß Sven
 
Dort laufen zur Zeit aber 1000000000 Mails hin, iwas scheint da nicht zu stimmen, ich kann nicht ausmachen was es ist. Werd mich dann wohl am Wochenende mal dran setzen.
 
You must log in or register to reply here.
Back
Top