[Postfixbuch-users] Mailserver drehen MX-Priorität um?!

[Maximilian Grobecker]

Hallo zusammen,

falls es dazu schon eine Diskussion gibt, bitte ich vielmals um
Entschuldigung - ich habe die Liste nach einigen Stichwörtern
durchsucht, aber nichts passendes gefunden...


Es ist ja hinlänglich bekannt, dass Spammer gerne die MX-Prioritäten
umdrehen und den vermeintlich am wenigsten gut gesicherten Mailserver
dann penetrieren. Funktioniert ja offenbar auch oft genug.

In letzter Zeit fällt mir zunehmend auf, dass gerade viele
Newsletterversender, aber nun auch Hoster wie Strato oder die Telekom
ebenfalls so verfahren.
Das würde mich nicht weiter stören, allerdings handelt es sich bei dem
Backup-MX um einen vergleichsweise kleinen vServer, der am
"Newsletter-Mittwoch" schon genug zu tun hat.
Wenn dann auch noch die gut 10 MB schweren Mails über Strato oder die
DTAG aufschlagen, dann kann es gut sein, dass diese Mails etwa 20
Minuten in der Queue des Backup-MX warten dürfen, bis sie dann endlich
zugestellt werden.

Der flinkere Server ist bereits in Vorbereitung, aber die zahlende
Institution hat etwas skeptisch hinterfragt, wofür denn da ein dickerer
Backup-MX hinmuss, wenn der doch vielleicht 10-15 Mal im Jahr benutzt
werden dürfte.
Und ehrlich gesagt habe ich mich das auch gefragt...

Daher:
Welchen Vorteil hat es z.B. für Strato, dass sie die MX-Priorität
umdrehen? Ich käme doch nie auf die Idee, so einen Aufwand zu betreiben,
ohne dass ich mir davon was besonderes verspreche...



Viele Grüße aus dem Tal
Max


-- 
Max Grobecker
max at grobecker-wtal.de

Sollten Sie eine .asc-Datei im Anhang finden, so können Sie diese
getrost ignorieren.
Es handelt sich dabei um eine digitale PGP-Signatur, die Absender und
Inhalt verifiziert.

-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : signature.asc
Dateityp    : application/pgp-signature
Dateigröße  : 259 bytes
Beschreibung: OpenPGP digital signature
URL         : <https://listi.jpberlin.de/pipermail/postfixbuch-users/attachments/20100730/88f7d875/attachment.asc>