[Postfixbuch-users] RFC Reverse DNS

[Alexander Stoll]

Also, ich will hier keine weitere, endlose Diskussion provozieren, jedoch
einfach eine weitere Facette beleuchten, ich hoffe das kann so als Standpunkt
stehen bleiben ohne eine Flut auszulösen...

Stefan Förster schrieb:

> Ich muß Patrick hier zustimmen, es gibt zwar viele Systeme, bei denen
> die Namensauflösung "wie nach Lektüre des RFC zu erwarten" stimmige
> Ergebnisse liefert, es gibt aber eben leider auch genug Systeme, bei
> denen das nicht so ist.
Und es liegt leider noch weniger Sinn darin, "Gurkensysteme" zu
"domestizieren", selten kranken solche Systeme nur am inkonsistenten DNS,
meist ist die ganze Konfiguration auf dem Stand, irgendwas wird versendet und
empfangen, was genau und wie weis keiner, am wenigsten der "Admin".


> Vor lauter Spam-Bekämpfung sollten wir nicht vergessen, daß wir
> Mailserver betreuen. Wir tun das, damit wir oder unsere Kunden Mails
> empfangen und verschicken können, sprich, um das Medium Mail zur
> Kommunikation zu benutzen.
Und diese Betreuung gehört in die Hände von ausreichend engagierten und vor
allem ausreichend fachkundigen Administratoren. Wer nicht in der Lage ist dies
vorzuhalten, möge diesen Service doch bitte extern einkaufen, es gibt durchaus
fähige und gute Dienstleister, dies ist billiger und bringt mehr als eine
halbgare Bastellösung.

> Es ist uns und unseren Kunden nicht damit geholfen, daß wir die
> Daumenschrauben, also die Anforderungen an die Systeme Dritter, immer
> fester anlegen.
Mit Maß und Ziel, die RFCs definieren hier fixe Rahmenbedingungen, wer gegen
_verpflichtende_ Richtlinien verstößt, darf sich nicht wundern ausgegrenzt zu
werden.


> Du selbst hast ein gutes Beispiel dafür gebracht, wie
> man es machen kann: Ist der Hostname nicht korrekt "gemapped", wird
> Grelisting benutzt. Das ist effektiv und das wird z.B. durch einen
> policyd-weight noch effektiver.
Zustimmung, wenn dies für Deine Umgebung funktioniert und ausreicht, andere
werden uU der Flut nur durch härtere Maßnahmen Herr und müssen und können auch
unter Abwägung aller Fakten harte Ablehnungen fahren.

> Jede fälschlicherweise abgelehnte Mail, jede Mail, die mit großer
> Verspätung ankommt macht das Medium "eMail" ein Stückchen mehr kaputt.
Leider wurde das Medium schon lange kaputt gemacht, es geht in erster Linie
darum, den Status Quo und die Benutzbarkeit an sich aufrechtzuerhalten, vieles
wäre wünschenswert und würde ich gerne anders handhaben, der Missbrauch
erzwingt strengere Restriktionen. Auch wird das Medium heute leider vielfach
zur Echtzeitkommunikation missbraucht, dazu war es nie erdacht, Laufzeiten
sind ganz normal, nur ist das Bewusstsein über diesen Umstand ist leider
zunehmend verschwindend gering.

> Ein Benutzer wird damit leben können, wenn er pro Tag zwei Spam-Mails
> in seiner Inbox vorfindet. Womit er nicht leben können wird sind zwei
> Mails pro Tag, die ihn nicht erreichen. Es ist nicht unsere Aufgabe,
> mit immer mehr Blacklisten, immer mehr Checks und immer mehr
> Programmen die Chance, daß auch legitime Mail durchgestellt wird,
> Stück für Stück weiter zu verringern. Wir sollten vielmehr umdenken
> und uns dazu zwingen, unsere Policy, was wir annehmen und zustellen,
> explizit und genauso wohldefiniert zu formulieren, wie wir das z.B.
> von Sicherheits- oder Notfallkonzepten in anderen IT-Bereichen kennen.
> Nur so bieten wir unseren Benutzern die Möglichkeit, informiert zu
> entscheiden, ob sie unseren Service nutzen wollen oder nicht.
> Nutzungssicherheit ist viel wichtiger als immer neue Abwehrmaßahmen.
Nach unserer Erhebung sind Nutzer in der Mehrzahl nicht in der Lage bei
Wahlmöglichkeiten für sich sinnvolle Einstellungen vorzunehmen und wollen sich
auch gar nicht im erforderlichen Maße mit der Materie beschäftigen um dies zu
können.
Sie reduzieren ihre Ansprüche auf 100% spamfreier Mailbox und 0% Ablehnungen
von gewünschter Email. Das dies technisch nicht erreichbar ist, interessiert
erst in zweiter Linie, beschert wird IMMER ;-) .
Es obliegt dem Admin unter Einbeziehung aller Aspekte eben das Beste aus der
Situation und den Rahmenbedingungen zu machen.

> Als Posthamster darf man sich nie und nimmer dazu hinreißen lassen,
> mit Maßnahmen gegen UCE/UBE über das Ziel hinauszuschießen. Ich stimme
> Dir zu, daß viel "Dreck" über Hosts mit falsch eingestellten
> DNS-Informationen eingeliefert wird und daß von solchen Hosts
> deutlich mehr Noise als Signal ausgeht. Solange da aber noch Signal
> ist, egal wie wenig, darf man nicht einfach ein NOQUEUE rausballern.
> Und nötig ist das ganze auch nicht - momentan haben wir noch genug
> Mittel und Wege, Spam anderweitig abzulehnen und auszusortieren.
Dies ist für meinen Geschmack etwas zu idealistisch, wer ernsthaft erwartet an
einer dynamischen IP, ohne konsistenten DNS einen progfessionellen Mailservice
betreiben zu können, sollte umgehend einen "Realitäts-Check" seiner
Erwartungen durchführen. Diese Option haben die Botnetze in der Tat
erfolgreich zerstört.
Ich kann das permanente Klagen der "Großen" über die wahnsinnigen SPAM-Fluten
echt nicht mehr hören, im Gegenzug wird der ganze Schrott vielfach pauschal
geschluckt und schlimmer noch Backscatter generiert, einfach weil mehr Server
und Bandbreite billiger ist als "Gurkensysteme" auszugrenzen und den
Supportaufwand für den Billigheimer steigert.
Das die Gesamtsituation von der Domestizierung solcher Systeme nicht
profitiert, andere zwingt ihrerseits Restriktionen zu lockern um nicht den
"Schwarzen Peter" zugeschoben zu bekommen und langfristig in die Sackgasse und
den endgültigen Tod des Mediums führt, interessiert die nur im Quartal
denkende Fraktion leider wenig.

Meine Prämisse:
- SPAM Bekämpfung mit Maß und Ziel ohne idealistisch Einfärbung in irgendeine
  Richtung, orientiert an der realen Situation und Randbedingungen
- Durchsetzung von SINNVOLLEN Restriktionen
- Informationspolitik für nicht ausreichend sachkundige Administratoren

Ich hoffe dies ist so annehmbar.

mfG, AS

-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : smime.p7s
Dateityp    : application/x-pkcs7-signature
Dateigröße  : 3237 bytes
Beschreibung: S/MIME Cryptographic Signature
URL         : <https://listi.jpberlin.de/pipermail/postfixbuch-users/attachments/20071004/146f5f3c/attachment.bin>