• This forum has a zero tolerance policy regarding spam. If you register here to publish advertising, your user account will be deleted without further questions.

Qmail: Backscatter vermeiden

mantiz

New Member
Hallo,

ich kümmere mich für einen Bekannten ein wenig um seinen Root-Server. Leider verwendet dieser Server Qmail, womit ich mich überhaupt nicht auskenne.

Und zwar hat mein Bekannter nun eine Mail von 1&1 erhalten, dass sein Server für Backscatter missbraucht wird und entsprechend bei backscatter.org gelistet wird.

Ich hab' mir das ganz angesehen und nicht existente Adressen auf irgendwelche Domains werden ganz korrekt mit einem 550 No such user beantwortet, wenn man aber an einen lokalen Account schickt (postermaster, blub, etc.), dann wird dies akzeptiert (250 ok).

Die Validierung der Empfängeradressen für die virtuellen Domains funktioniert also, aber für die lokalen Konten findet anscheinend keine Validierung statt.
Leider stelle ich mich bei der Suche anscheinend auch zu blöd an, als dass ich dazu etwas finden könnte.

Kann mir jmd. sagen, wie ich Mails an nicht existente lokale User von außerhalb (oder generell) ablehnen kann?
 
Im Grunde ist mir das schon klar (denke/hoffe ich ;))

Mein Problem ist halt, dass der Server auf der Blacklist steht, angeblich zuletzt am 08.06.2010 um 21:25 Uhr getestet wurde, aber für jede auf dem Server befindliche Domain bereits seit geraumer Zeit eingerichtet ist, dass Mails an nicht existente Konten direkt abgelehnt werden sollen.

Wenn ich dies per telnet teste, dann erhalte ich auch direkt einen 550er für die nicht existente Adresse:
Code:
220 <domain> ESMTP
helo blub
250 <domain>
mail from: someone@somedomain.de
250 ok
rcpt to: unknown_user@local-domain.de
550 sorry, no mailbox here by that name. (#5.7.17)

Aber folgendes funktioniert:
Code:
220 <domain> ESMTP
helo blub
250 <domain>
mail from: someone@somedomain.de
250 ok
rcpt to: blub
250 ok
Und den User blub gibt es definitiv nicht.

Wobei <domain> aus irgendeiner Nummer gefolgt von ".onlinehome-server.info" besteht.
Jede im Plesk eingerichtete Domain ist in der Datei rejectnonexist aufgeführt, nur diese <domain> nicht. Sollte diese ebenfalls in dieser Datei stehen?
 
Wenn sie auch in locals bzw rcpthosts steht, dann ja. Ansonsten mußt Du ein catchall-Postfach aufmachen.
 
OK, getestet, die <domain> stand zwar nicht drin, aber in der locals hab' ich noch localhost und locahost.localdomain gefunden, welche ich in der rejectnonexist ergänzt habe.

Funktioniert aber nicht, ich bekomme nach wie vor eine failure notice an meine mail-from-Adresse geschickt.

Kann ich Qmail nicht irgendwie beibringen, dass Mails ohne Domainzusatz, vor allem an nicht existente Benutzer abgelehnt werden?

Falls nicht, wie kann ich ein systemweites catch_all-Konto einrichten?

// Edit:
Die failure notice sieht so aus:
Code:
Hi. This is the qmail-send program at <domain>.
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.

<blub@<domain>>:
Sorry. Although I'm listed as a best-preference MX or A for that host,
it isn't in my control/locals file, so I don't treat it as local. (#5.4.6)

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

Return-Path: <<mailfrom-adresse>>
Received: (qmail 17811 invoked from network); 9 Jun 2010 20:22:12 +0200
Received: from dslb-084-061-200-056.pools.arcor-ip.net (HELO blub) (84.61.200.56)
  by <domain> with SMTP; 9 Jun 2010 20:22:06 +0200
subject: test 4

asldfasf
 
Last edited by a moderator:
OK, jetzt habe ich <domain> in der locals ebenfalls eingetragen, bekomme aber immer noch eine failure notice, allerdings fehlt folgender Part, ansonsten ist diese aber gleich:

Code:
Sorry. Although I'm listed as a best-preference MX or A for that host,
it isn't in my control/locals file, so I don't treat it as local. (#5.4.6)

Es wurde also erkannt, dass diese in der locals steht, in der rejectnonexist steht sie aber ebenfalls, was aber anscheinend keine Bewandnis hat. :(
 
Nö, wurde nicht erkannt.

Wenn nicht gerade ein Schreibfehler vorliegt, hat qmail (smtpd) die Datei vielleicht noch nicht neu eingelesen.
 
Nö, wurde nicht erkannt.

Wenn nicht gerade ein Schreibfehler vorliegt, hat qmail (smtpd) die Datei vielleicht noch nicht neu eingelesen.

Doch, der hat die neu eingelesen. :(

Ich bin mittlerweile etwas weiter mit meinen Versuchen, und zwar habe ich in der Datei "me" einfach mal eine Domain eingetragen, welche per Plesk konfiguriert ist und eine mail an "no_user@domain.de" auch mit 550 beantwortet wird.
Wenn ich jetzt allerdings als "rcpt to" einfach nur "no_user" angebe, dann wird korrekterweise "domain.de" ergänzt (was ich in der failure notice) sehe, aber die Mail wird erstmal angenommen und anschließend entsprechend eine Fehlernachricht an den Absender geschickt.

Bei der automatischen Domainergänzung scheint die Überprüfung, ob es das Konto auch wirklich gibt nicht zu funktionieren.

Also: Mail an no_user@domain.de wird direkt abgelehnt, Mail an no_user (wo domain.de automatisch angehängt wird) wird angenommen und eine Fehlernachricht erzeugt.

Bin ich so doof oder qmail? :)
 
@mantiz
Bist du in dem Problem irgendwie weiter gekommen? Ich hänge nämlich momentan an genau dem selben Punkt! E-Mails mit Domainname werden korrekt rejected, ohne Domainname verschickt Qmail obige "failure notice".

Und 1&1 macht es sich sehr einfach, indem Sie einfach auf ihre AGB's verweisen, dass die Administratoren sich um den Server kümmern müssen. Dass aber alles 1&1-Rootserver von Haus aus diese lückenhafte Konfiguration aufweisen scheint sie dabei eher weniger zu stören!
Sie schreiben:
> > Leider finde ich aber auch nach langer Suche nicht, wie man die
> > Zustellung von Mails ohne Domainname in qmail unterbindet!
> > Haben Sie hier eine entsprechende Konfiguration zur Hand?
Wir können Ihnen derzeit nicht sagen, ob es hierzu eine entsprechende
Konfiguration gibt. Wenden Sie sich dazu bitte direkt an den Hersteller der
Software qmail.

Evtl. finden Sie auch Hilfe in einschlägigen Foren, wie dem Server-Support-Forum
(http://serversupportforum.de/).

Das Forum kannte ich aber vorher schon! :cool:
 
Setzt Du Plesk ein? Dann schau mal hier: Plesk/Qmail: Bounce-Mails unterbinden
Ja, ich nutze aus Faulheit und wider besseren Wissens Plesk! :eek:
huschi's Beitrag kenne ich natürlich auch. Das bringt aber nur was, wenn eine Mail an gibt-es-nicht@pleskdomain.tld geht! Wenn aber im RCPT TO nur gibt-es-nicht steht hilft dies leider überhaupt nichts!

Falls Du kein Plesk benutzt, schau hier: Rejecting with Qmail
Danke, werde ich mir Morgen mal zu Gemüte führen.
Einen einfachen Config-Schalter der Marke "rejectlocalmail" scheint es für QMail ja leider wirklich nicht zu geben! :rolleyes:
 
Ich hab Dein Problem bei meinem Strato vServer mal aus Spaß nachgestellt: Hoppla, ich habe genau dasselbe Problem! :eek:
Scheint wohl eine Schwäche der mitgelieferten Plesk-Installation (hier: Plesk Panel 9.5.2) zu sein. 1&1 kann jedenfalls nichts dafür, außer wenn Du ihnen vorwerfen willst, dass sie Plesk einsetzen... ;)
Übrigens unterstützt Plesk jetzt endlich auch Postfix!
Ein Grund mehr zum Wechsel... :D
 
Soweit ich mittlerweile herausgefunden habe, ist das ein Qmail-Problem und keines von Plesk (das hat andere ;)). Qmail nimmt Mails (für lokale User) immer an und entscheidet erst später, was damit geschehen soll. Und dieses Verhalten kann man Qmail (standardmäßig) scheinbar auch nicht abgewöhnen.

Das Verhalten kann ich übrigens genauso mit einem älteren Rootserver von 1&1 wie mit einem vServer von HostEurope nachstellen! Klappt vermutlich auch mit 99% aller Qmail-Server (mit Plesk)!

Ich finde es halt ehrlich gesagt etwas dreist von 1&1 einen Server bereit zu stellen, der in seiner Grundkonfiguration unsicher ist - in wie weit man bei Backscatter auf lokale User überhaupt von unsicher oder Problem sprechen möchte -, diese dann automatisiert zu testen und in der entsprechend automatisierten Mail dann auch damit zu drohen den Server vom Netz zu nehmen! Des weiteren wurde ein reproduzierbarer Fall auch erst nach langem hin-und-her genannt und auf die Frage nach der Lösung kommt dann ein "wissen wir auch nicht"! Und 1&1 dürfte dann ja doch eine stattliche Anzahl an Root- und vServern mit exakt diesem Qmail-Problem vermieten! :mad:
 
Du hast schon recht- QMail bietet von sich aus keine Möglichkeit, den Absender schon innerhalb des SMTP-Dialoges abzulehnen. Ist eben letztendlich Software von 1998, und da war das Internet eben auch noch etwas "friedlicher".
Was ich mich aber frage, ist:
Wenn 99% aller Plesk-betriebenen Server das Problem haben (weil QMail verwendet wird), wieso führt nur bei Dir das zu wirklichem Backscatter und nicht bei den restlichen 98,999%?
Wie gesagt, ich habe hier auch Mailserver mit QMail stehen, und es ist noch nie jemand auf die Idee gekommen, über den Versand von eMails an "domainlose" Benutzer Backscatter zu erzeugen.
Und: Ja, ich finde das Verhalten von 1&1 auch etwas frech. Aber sie können sich halt wunderbar herausreden, weil a) Du der Admin bist und b) Dich ja auch keiner zwingt, Plesk (QMail) zu nutzen.
Ein Patch von Parallels zu dem Thema wäre natürlich auch nicht schlecht...
 
Last edited by a moderator:
Der einzige Grund wieso ich mich damit überhaupt beschäftige, ist der Hinweis von 1&1 darauf! Ansonsten würde ich es wie eben die anderen 98,999% auch machen und den Backscatter auf lokale User ignorieren und unter "Ist halt so" verbuchen - zumal ja bei Zustellversuchen mit Domain alles passt!

Du kannst ja deine Server-IP mal bei http://www.backscatterer.org/?target=test eintragen! Dürfte dann ebenfalls zu einem Listing führen! :cool:


Ein anderer Lösungsansatz, der mir noch eingefallen ist, ist via /var/qmail/alias/.qmail-default ALLE Mails anzunehmen und nach /dev/null zu schieben! Für die Domains müsste ja weiter das Listing in /var/qmail/control/rejectnonexist greifen, so dass in .qmail-default nur die "Problem-Mails" landen. Oder sehe ich das jetzt falsch?
 
Du kannst ja deine Server-IP mal bei http://www.backscatterer.org/?target=test eintragen! Dürfte dann ebenfalls zu einem Listing führen! :cool:
Hab´s jetzt spaßeshalber mal mit allen drei Servern gemacht, auf die ich Zugriff habe: Nicht gelistet.
Deswegen wundert es mich ja, wie Dein Server auf backscatter.org kommt. Da müssten ja dann alle Server gelistet sein, die QMail verwenden.

Ein anderer Lösungsansatz, der mir noch eingefallen ist, ist via /var/qmail/alias/.qmail-default ALLE Mails anzunehmen und nach /dev/null zu schieben! Für die Domains müsste ja weiter das Listing in /var/qmail/control/rejectnonexist greifen, so dass in .qmail-default nur die "Problem-Mails" landen. Oder sehe ich das jetzt falsch?

Guter Ansatz, ich bin aber (noch) nicht firm genug, was QMail angeht, um mir ein Urteil erlauben zu können.
Ich weiß nur, dass QMail lokale und remote Mails anders behandelt. Und dass, je nachdem ob die Mailadresse eben lokal oder remote ist, auch andere Konfigurationsfiles konsultiert werden. Lese mich aber gerade ein. :)
 
Workaround Backscatter unterbinden

Qmail antwortet auf Mails, die ohne Angabe eines Domainnamens in RCPT TO stehen standardmäßig mit einer Failure Notice, da Mails ohne Domainpart, wie z.b. userxy statt userxy@domain.tld, immer angenommen werden. Leider kann man Qmail die Annahme lokaler Empfänger aber auch nicht untersagen.

Folgender Workaround verhindert den Backscatter, löst das Problem im eigentlichen Sinne aber nicht. Es werden einfach alle Mails angenommen und anschließend - wenn diese nicht lokal zustellbar sind - in .qmail-default verworfen! Die Datei envnoathost bestimmt den Domainpart einer E-Mail, wenn dieser nicht angegeben wird.
Code:
echo "#" > /var/qmail/alias/.qmail-default
echo "localhost" > /var/qmail/control/envnoathost
/etc/init.d/qmail restart

Damit dies funktioniert, muss Qmail Mails an localhost selbstverständlich auch lokal behandeln! Dies ist normalerweise so, kann aber folgendermaßen überprüft werden:
Code:
cat /var/qmail/control/locals
Hier muss localhost mit aufgefüht sein!

Hinweis: Die Rejects (Statuscode 55x) auf vollständige aber ungültige E-Mail-Adressen funktioniert weiterhin! Obige Lösung greift nur für den Spezialfall, wenn Mails keinen Domainpart besitzen!
 
Hi,

selber Fehler bei uns. Workaround ist erstmal eine gute Zwischenlösung. Wir haben 1+1 grad davon unterrichtet und warten auf dei Antwort, ob sie damit leben können. Es dürften ja nun keine bounce-messages mehr zurückgesendet werden.

Was bedeutet eigentlich
Es werden einfach alle Mails angenommen und anschließend - wenn diese nicht lokal zustellbar sind - in .qmail-default verworfen
Was passiert in der /var/qmail/alias/.qmail-default. bedeutet verworfen, die Mails landen im Nichts? Diese Dateien und die /var/qmail/control/envnoathost existieren nicht. Warum wird auf diese neuen Dateien zugegriffen, wenn sei erstellt werrden?
 
Was passiert in der /var/qmail/alias/.qmail-default. bedeutet verworfen, die Mails landen im Nichts?
So habe ich das jedenfalls verstanden!

Diese Dateien und die /var/qmail/control/envnoathost existieren nicht. Warum wird auf diese neuen Dateien zugegriffen, wenn sei erstellt werrden?
Weil dies Standard-Konfigurationsfiles von Qmail sind, die beim Neustart des Dienstes eingelesen werden.
Mit /var/qmail/bin/qmail-showctl kannst du dir z.B. die Konfiguration deines Qmail-Servers anzeigen lassen!


Hab mittlerweile aber auch festgestellt, dass dieser Workaround dubiose Listen wie z.B. backscatterer.org nicht interessieren. Hier wird scheinbar eine 55x erwartet, mit dem ich nun mal nicht dienen kann!
 
Hi, danke für Deine Info.

Übrigens 1+1-Abuse hat uns auch Deinen Workaround empfohlen.
"...Für den Fehler mit dem Workaround gibt es folgenden Workaround:
https://serversupportforum.de/threads/qmail-backscatter-vermeiden.37998/post-250426"

und

"...Wenn Sie den Workaround von oben noch umgesetzt haben, ist Ihr Server vor diesem Missbrauch erst einmal geschützt. Wir gehen davon aus, dass Sie die Änderungen jetzt zeitnah durchführen und schließen das Ticket deshalb jetzt ab...."

ausserdem

"...Wir liefern unsere Standardimages derzeit nicht mehr mit qmail aus. Auch aus diesem Grunde stellen wir auch einen Hilfe-Artikel zur Umstellung von qmail auf postfix bereit:
http://hilfe-center.1und1.de/server/root_server/plesk/8.html?article_searchpos=4..."
 
Last edited by a moderator:
Back
Top