Qmail: Backscatter vermeiden - Seite 2

siradlib · #16 29.06.2010, 10:24

Zitat:

Zitat von wolfman

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

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.

Zitat:

Zitat von wolfman

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.

wolfman · #17 29.06.2010, 13:46

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!

howie · #18 08.07.2010, 14:21

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

Zitat:

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?

wolfman · #19 15.07.2010, 12:08

Zitat:

Zitat von howie

Was passiert in der /var/qmail/alias/.qmail-default. bedeutet verworfen, die Mails landen im Nichts?

So habe ich das jedenfalls verstanden!

Zitat:

Zitat von howie

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!

howie · #20 15.07.2010, 15:47

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:
http://serversupportforum.de/forum/m...tml#post250420...
"

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/...le_searchpos=4..."

wolfman · #21 15.07.2010, 16:14

Werden bei der Umstellung von Qmail auf Postfix auch evtl. gefüllte Postfächer mit übernommen? Dann werde ich das ggf. die Tage mal in Angriff nehmen, da in meinem internen Wiki die Tipps & Todo's zu Qmail immer länger werden!

Roger Wilco · #22 15.07.2010, 17:27

Zitat:

Zitat von wolfman

Werden bei der Umstellung von Qmail auf Postfix auch evtl. gefüllte Postfächer mit übernommen?

Was haben qmail oder Postfix mit schon ausgelieferten E-Mails zu tun?

wolfman · #23 15.07.2010, 17:45

OK, missverständlich ausgedrückt!

Zugestellte Mails, die noch nicht abgerufen wurden!

wstuermer · #24 15.07.2010, 23:54

Wenn die Mail einmal zugestellt ist (in *Maildir/* liegt), ist der MTA egal.

wolfman · #25 16.07.2010, 06:18

Und was ist mit den Daten unter /var/qmail/mailnames/domain.tld/...?

wstuermer · #26 16.07.2010, 07:34

Du hast die Aufgabe eines MTA noch nicht verstanden.

http://de.wikipedia.org/wiki/Mail_Transfer_Agent

wolfman · #27 16.07.2010, 17:26

So, Update ist durch und auf lokale Mails wird jetzt auch korrekt mit einem Fehler 550 geantwortet.

Das autoinstaller-Skript befindet sich bei neueren Plesk-Versionen (9.x) übrigens nicht mehr in dem von 1&1 angegeben Pfad, sondern unter:

Code:

/usr/local/psa/admin/bin/autoinstaller

1&1 ist sich selbst scheinbar auch nicht so im Klaren darüber, was sie tun sollen. Einerseits empfehlen Sie meinen Tipp von oben als Workaround weiter. Andererseits bekam ich heute eine Mail in der mir mitgeteilt wurde, dass mein Server wieder Backscatter verschickt und er binnen 24h vom Netz genommen wird. Prompt die von 1&1 getesteten Adressen überprüft die aber sogar korrekt mit 55x beantwortet wurden. Auf meinen Hinweis darauf, wurde das Ticket innerhalb von 10 Minuten geschlossen! Die Frage ob denn der Server nun wirklich backscattert oder nicht blieb mit einem schwammigen "wir testen ja nicht alle Möglichkeiten aber könnte ja möglich sein" weitestgehend unbeantwortet.

Fest steht jedenfalls: Nie wieder 1&1
Und das sage ich als jemand, der seinerzeit schon S&P-Partner war und über die Jahre mittlerweile tausende von Euro für Hostingpakete & Server bezahlt hat - man hat es scheinbar nicht nötig. Aber seit S&P in 1&1 aufging, ging es ja eh nur noch in eine Richtung, nämlich bergab!

incredibleDude · #28 01.08.2010, 20:11

Zitat:

Zitat von wolfman

1&1 ist sich selbst scheinbar auch nicht so im Klaren darüber, was sie tun sollen. Einerseits empfehlen Sie meinen Tipp von oben als Workaround weiter. Andererseits bekam ich heute eine Mail in der mir mitgeteilt wurde, dass mein Server wieder Backscatter verschickt und er binnen 24h vom Netz genommen wird. Prompt die von 1&1 getesteten Adressen überprüft die aber sogar korrekt mit 55x beantwortet wurden. Auf meinen Hinweis darauf, wurde das Ticket innerhalb von 10 Minuten geschlossen! Die Frage ob denn der Server nun wirklich backscattert oder nicht blieb mit einem schwammigen "wir testen ja nicht alle Möglichkeiten aber könnte ja möglich sein" weitestgehend unbeantwortet.

Die Frage ist doch hier eher, warum 1&1 deinen Server testen soll? Das er Backscattert habe die dir ja anscheinend bereits geschrieben.
Es ist doch schließlich dein Server. Da solltest du doch selbst einmal überprüfen ob er noch ausnutzbar ist.