SPF (?)

[Thomas Roessing]

Moin,
bei d)f und andernorts rufen die Leute nach SPF, das laut dem Heise (http://www.heise.de/newsticker/meldung/44262) eine Methode ist, das Verschicken von Spam mit gefälschtem Absender zu verhindern. Leider sind mir auch nach einem Blick auf http://spf.pobox.com/ ein paar Sachen unklar. Deshalb frage ich mal einfach hier nach ;) :

1. Mein Thunderbird begnügt sich mit einem einzigen SMTP-Server, nämlich smtp.trgsites.de. AFAIK könnte ich für meine meinungsklima.de und uni-mainz.de Adressen auch die entsprechenden smtp-einträge vornehmen, aber Thunderbird ist offenbar standardmäßig nicht darauf aus, das zu tun. Scheint also normal zu sein, alle möglichen Mailadressen mit nur einem smtp zu versehen; IIRC gibt (gab?) es auch in Volker Gringmuths Anleitung zum Hamster mal eine Stelle, die nur einen SMTP-Smarthost für alle Mailkonten empfahl, weil mehrere nicht unbedingt nötig seien. Offenbar nix per se Böses[tm].
Frage: Bekomme ich mit SPF Streß, wenn ich eine Mail von @meinungsklima.de über smtp.trgsites.de verschicke? Vermutlich nicht, weil beide Domain auf demselben Mailserver liegen. Wie ist es aber, wenn ich eine @roessing.org-Mail (Hostweb) über smtp.trgsites.de (Domainfactory) verschicke? Oder meine @uni-mainz-Mails?

2. Was wollen die Leute im d)f-Forum eigentlich selber und frei konfigurieren? Wenn ich SPF nicht völlig falsch verstanden habe, geht es darum, Mails abzulehnen, bei denen @alpha.tld im From steht und die über smtp.beta.tld verschickt wurden, sofern die IPs von alpha und beta nicht identisch sind. Was gibt es denn da zu konfigurieren :beati: ?

TIA,
viel Gruß
Thomas

[sillybilly]

Hallo Thomas,

ich hab mich die letzten Tage das erste mal mit SPF bschäftigt.
Wenn ich das alles richtig verstanden habe läuft das Verfahren (vereinfacht erklärt) folgendermassen ab:
Server A erhält eine eMail -->
Server A schaut nach welche Domain in der Absenderadresse angegeben ist (als Beispiel: irgendwer@example.tld) und über welche IP (als Beispiel: 666.777.888.999) die Mail versendet wurde -->
Jetzt fragt Server A den Nameserver von example.tld, ob 666.777.888.999 Mails für diese Domain versenden darf (dafür ist der SPF-Eintrag notwendig)
Abhängig von der Antwort des Nameservers kann Server A jetzt mit der eMail verfahren, wie der Admin ihm das vorgegeben hat (löschen, rejecten, taggen oder was auch immer)
Eigentlich ein sehr einfaches verfahren.

Zu deinen Fragen:Bekomme ich mit SPF Streß, wenn ich eine Mail von @meinungsklima.de über smtp.trgsites.de verschicke? Vermutlich nicht, weil beide Domain auf demselben Mailserver liegen.
Richtig - in diesem Beispiel bekommst du keinen Stress.
Selbst wenn die Domains unterschiedliche Mailserver von d)f verwenden würden könnte d)f den SPF-Eintrag so gestalten, das du dann keine Probleme bekommst.

Wie ist es aber, wenn ich eine @roessing.org-Mail (Hostweb) über smtp.trgsites.de (Domainfactory) verschicke? Oder meine @uni-mainz-Mails?
Hier würdest du Probleme bekommen.
Es sei denn (und der Fall ist sehr unwahrscheinlich), dass Hostweb oder deine Uni in den Nameservereinträgen dem df -Server ein relaying für die Domain roessing.org gestattet.

Wenn du natürlich selbst diese Nameservereinträge vornehmen kannst könntest du einstellen, das die d)f-IP eMails mit Absender roessing.org versenden darf und würdest "keinen Stress bekommen".
Und damit dürfte die Frage, warum einige d)f-Kunden die Möglichkeit SPF-Einträge setzen zu können haben möchten geklärt sein ;)

HTH
Gruss, Norbert

[Thomas Roessing]

Moin,
vielen Dank für die Erklärung - Du solltest Gebrauchsanleitungen für komplizierte Computermachinen schreiben.

Wenn ich das richtig sehe, kommt es hier auf zwei Einstellungen an, diem an vornehmen kann/muß/will:

1. Man muß dem Mailsystem sagen, was es mit Mails machen soll, bei denen der Domainname im From nicht zum Einlieferserver paßt. Wenn man löscht, bekommt man keine Mails mehr, die mit gefälschter oder sonstwie unpassender Absenderadresse verschickt wurden. Würden alle Leute so verfahren, könnten Spammer keine geklauten Adressen mehr ins From schreiben.

2. Man muß seinem eigenen Mailserver sagen, für welche From-Domainparts er sich zuständig fühlen soll.

Nun scheint mir das ganze - sofern ich es richtig mitbekommen habe - aber eine etwas zähe Methode zur Spambekämpfung zu sein:

1. Niemand hindert Spammer in südostasiatischen Gefilden daran, ihren Mailserver für bundeskanzler.de für zuständig zu erklären.

2. Was passiert, wenn der Einliefer-Header gefälscht ist und zu der ebenfalls gefälschten Adresse im From paßt? Ob das einfach unzusetzen ist, weiß ich nicht, aber $Spammer wird sich da schon Gedanken drüber machen.

3. SPF müßte schon flächendeckend mit Blackhole-Funktion eingesetzt werden (und wenn's geht *ohne* einen Bounce ans From :rolleyes: !), um die Zustellung von Mails mit gefälschtem From zu unterbinden und so den Spammern Hurgka zu machen. Bekommt das jeder Provider hin, ohne Murks zu machen?

3. Die Gefahr von False-Positives ist doch weng hoch, IMHO. Ich bin vermutlich nicht der einzige, der einen SMTP für drei oder vier Adressen einsetzt. Ich habe das jetzt mitbekommen und mir professionell erklären lassen. Wer da nicht so aufpaßt, wird nicht mehr gelesen (und bekommt - hoffentlich - nicht mal einen Bounce). Wenn ich mir den Wunsch eines Users aus dem d)f-Forum (http://forum.domainfactory.de/forum/showthread.php?t=28717) ansehe, scheint SPF insgesamt keine allzu triviale Sache zu sein:
[so sollte es aussehen]
[kiu@wopr kiu]$ dig tiscali.de txt
tiscali.de. 1800 IN TXT "v=spf1 ip4:62.26.116.129 ip4:62.26.116.130 ip4:195.63.63.121 ip4:62.27.91.200 ip4:62.27.91.201 ip4:213.183.18.32/28 -all". Wenn ich meiner Mutter erklären sollte, daß sie sowas irgendwo eintragen muß, um für ihre Zweit-Mailadresse denselben SMTP nutzen zu können, wie für ihre Hauptadresse, würde das nicht weit führen.

Also:

Ist SPF der Große Wurf? :beati:

Viel Gruß
Thomas

[sillybilly]

Originally posted by Thomas Roessing@Feb 4 2004, 11:50 PM
Du solltest Gebrauchsanleitungen für komplizierte Computermachinen schreiben.
Danke für die Blumen :)

1. Man muß dem Mailsystem sagen, was es mit Mails machen soll, bei denen der Domainname im From nicht zum Einlieferserver paßt. Wenn man löscht, bekommt man keine Mails mehr, die mit gefälschter oder sonstwie unpassender Absenderadresse verschickt wurden. Würden alle Leute so verfahren, könnten Spammer keine geklauten Adressen mehr ins From schreiben.
Ganz genau richtig - das ist der Sinn hinter dem ganzen.
Der Sinn ist nicht (und kann es auch technisch gar nicht sein), Spam zu verhindern.
Es ist ein Verfahren um Absenderadressfälschung zu erkennen (nichteinmal diese zu verhindern) - nicht mehr und nicht weniger.
Letztlich hängt das ganze Verfahren davon ab, wieviele Domainbetreiber (u.a. auch Du und ich) sich daran beteiligen.
Wenn aber ein paar grosse Provider (wie eben z.B. AOL) dieses Verfahren einsetzen ergibt sich ein gewisser Zwang mitzumachen ;).

2. Man muß seinem eigenen Mailserver sagen, für welche From-Domainparts er sich zuständig fühlen soll.
Flachs.
Natürlich musst du deinem eigenen Mailserver sagen, für welche Domain(s) er zuständig ist. Das hat mit der Sache aber gar nichts zu tun.
Du musst dem Nameserver deiner Domain (z.B. roessing.org) sagen, welche IP-Adresse(n) Mails mit dem Absender roessing.org versenden dürfen.

Damit hat sich
1. Niemand hindert Spammer in südostasiatischen Gefilden daran, ihren Mailserver für bundeskanzler.de für zuständig zu erklären.
bereits erledigt, weil der Spammer keinen Zugriff auf den Nameserver deiner Domain hat (wäre das anders würde das gesamte DNS und damit das www nicht funktionieren ;)).

2. Was passiert, wenn der Einliefer-Header gefälscht ist und zu der ebenfalls gefälschten Adresse im From paßt? Ob das einfach unzusetzen ist, weiß ich nicht, aber $Spammer wird sich da schon Gedanken drüber machen.
Der Spammer kann sich soviel Gedanken machen wie er will - er kann schlicht und einfach den "Einliefer-Header" nicht fälschen, da dein Mailserver diesen Header setzt.

3. SPF müßte schon flächendeckend mit Blackhole-Funktion eingesetzt werden (und wenn's geht *ohne* einen Bounce ans From :rolleyes: !), um die Zustellung von Mails mit gefälschtem From zu unterbinden und so den Spammern Hurgka zu machen.
Richtig - wirklich effektiv wird SPF erst, wenn man (nach einer gewissen Übergangszeit) Mails mit nicht autoristertem Absender ohne bounce killt.
Dazu drei Bemerkungen: Das ganze wird zur Zeit in einem RFC formuliert - wenn das fertig ist (die techn. Funktionsweise also klar definiert und von der IETF (http://ietf.org/) bestätigt ist) liegt es an den Mailserverprogrammierern, diesen (dann "verbindlichen" RFC) in ihrer Mailserversoftware umzusetzen.
Für die grössten OpenSource Mailserver (qmail, postfix z.B.) existieren schon entsprechende Plugins.
Spätestens, wenn ein paar grössere Provider das rigoros durchziehen wird den anderen gar nichts anderes übrig bleiben als mitzuziehen
Ich persönlich halte sehr wenig bis gar nichts davon, das Verfahren vor Bestätigung des RFC durch die IETF für etwas anderes als zu Testzwecken einzurichten (macht bis jetzt ja auch keiner und wird hoffentlich auch keiner machen).
Ich könnte d)f aber sehr gut verstehen (und würde dem voll zustimmen), wenn sie sich bis zur offiziellen Bestätigung weigern würden, entsprechende Nameservereinträge umzusetzen.

Bekommt das jeder Provider hin, ohne Murks zu machen?
Wenn er das nicht schafft kann er immer noch Bäcker werden ;)

3. Die Gefahr von False-Positives ist doch weng hoch, IMHO. Ich bin vermutlich nicht der einzige, der einen SMTP für drei oder vier Adressen einsetzt. Ich habe das jetzt mitbekommen und mir professionell erklären lassen. Wer da nicht so aufpaßt, wird nicht mehr gelesen (und bekommt - hoffentlich - nicht mal einen Bounce).
Jede Umsetzung eines neuen technischen Verfahrens "am lebenden Objekt" wird die einen oder anderen Schwierigkeiten machen - dafür gibt es Übergangszeiten.
So könnte man (und wird man wohl auch) vor kill ohne bounce eine gewisse Zeitlang kill mit bounce praktizieren.

"v=spf1 ip4:62.26.116.129 ip4:62.26.116.130 ip4:195.63.63.121 ip4:62.27.91.200 ip4:62.27.91.201 ip4:213.183.18.32/28 -all".
Der Eintrag ist eigentlich sehr einfach zu lesen (ob deine Mama ihn jemals verstehen könnte vermag ich nicht zu beurteilen ;)):
[list] v=spf1 == Hier beginnt der SPF-Eintrag
ip4: == Die folgende IP-Adresse ist eine IP der Version 4
62.26.116.129 == IP-Adresse, die Mails mit @tiscali.de versenden darf
-all == Ende des SPF-Eintrags (nur und ausschliesslich die vorher genannten IP-Adressen sind berechtigt für tiscali.de Mails zu versenden

Um aber mal ein einfaches Beispiel zu zeigen nehmen wir den Eintrag für meine sillybilly.org
"v=spf1 a mx -all"
SPF-Wizard (http://spf.pobox.com/wizard.html?mydomain=sillybilly.org&a=yes&mx=yes&ptr=no&a_colon=regular+hostnames&mx_colon=MX+servers&ip4_colon=IP+addresses&include=myISP.com&all=yes&record_so_far=%22v%3Dspf1+a+mx+-all%22&use_built_from_args=1)
Kannst du für deine Domain ja auch mal machen:
http://spf.pobox.com/wizard.html


Wenn ich meiner Mutter erklären sollte, daß sie sowas irgendwo eintragen muß, um für ihre Zweit-Mailadresse denselben SMTP nutzen zu können, wie für ihre Hauptadresse, würde das nicht weit führen.
Wenn der Provider deiner Mama (oder z.B. du) das nicht einrichten will/kann wird ihr nichts anderes übrig bleiben, als den entsprechenden Mailserver zu verwenden.
Vielleicht kriegen die Jungs/Mädels vom Mozilla/Thunderbird-Projekt es ja dann endlich mal hin einen brauchbaren MUA zu programmieren ;)

Ist SPF der Große Wurf? :beati:
Der grosse Wurf wozu?
Um Spam zu verhindern/auszumerzen? - Ganz sicher nicht (ist auch nicht das Ziel).
Um Absenderadressfälschungen zu verhindern? - Wenn es umgesetzt ist: Ja.! <--

Der Vorteil von SPF ist die relativ einfache und wenig aufwendige Umsetzung: lediglich die Mailserversoftware muss angepasst werden und ein Nameservereintrag gesetzt werden.

Gruss, Norbert

[Thomas Roessing]

Der Sinn ist nicht (und kann es auch technisch gar nicht sein), Spam zu verhindern.

Würde es die Spammer nicht behindern, wenn sie keine Adressen mehr klauen könnten? Angenommen, alle nutzten SPF. Dann muß der Spammer entweder seine eigene Adresse benutzen oder erfundene (duenn.sch z.B.). Letztere fliegen aber bei einem Lookup schnell auf und auf erstre kann man prima filtern.

Flachs.
Natürlich musst du deinem eigenen Mailserver sagen, für welche Domain(s) er zuständig ist. Das hat mit der Sache aber gar nichts zu tun.
Du musst dem Nameserver deiner Domain (z.B. roessing.org) sagen, welche IP-Adresse(n) Mails mit dem Absender roessing.org versenden dürfen.

Ah, gut, danke. Ich glaube, jetzt habe ich's verstanden.


Der Spammer kann sich soviel Gedanken machen wie er will - er kann schlicht und einfach den "Einliefer-Header" nicht fälschen, da dein Mailserver diesen Header setzt.
:confused: Mit Einliefer-Header meine ich den untersten Received-Eintrag. Ich dachte immer, man soll nur dem obersten (neuesten, letzten vor Auslieferung) Eintrag trauen, weil der vom eigenen Mailserver stammt. Die unterste Received-Zeile wird doch von dem SMTP-Server gemacht, an den das Mailprogramm / die Spamsoftware die Mail übergibt, also z.B. ein offenes Relay in Burma. Und um den muß es doch gehen bei SPF: Bestätigt der Nameserver des From-Domainparts, daß der erste Mailserver auf dem Weg berechtigt ist, die Mail zu senden? Oder habe ich das jetzt unpräzise aufgeschnappt? :beati:

Mit dem Wizard muß ich noch mal üben, wenn ich etwas mehr Muße habe, mich darauf zu konzentrieren; im Moment behauptet er jedenfalls, publizistik.uni-mainz.de hätte keine IP-Adresse -> :confused: Ich muß doch hoffentlich nur dann alle denkbaren Einliefer-IPs (zuhause, über DSL, sind das ja eine ganze Menge) dem trgsites-Nameserver als befugt bekannt geben, wenn ich den trgsites-Mailserver als Smarthost für einen lokalen Server nutzen will, oder?

Viel Gruß
Thomas

[sillybilly]

Originally posted by Thomas Roessing@Feb 5 2004, 03:39 PM
Der Sinn ist nicht (und kann es auch technisch gar nicht sein), Spam zu verhindern.

Würde es die Spammer nicht behindern, wenn sie keine Adressen mehr klauen könnten?
Warum sollte sie das behindern? - die allermeisten in spamhaus.org gelisteten Spammer verwenden ihre eigenen (korrekten) Absenderadressen ;)
Spam wird also nicht verhindert - es wird lediglich Adressfälschung verhindert.
Und dadurch, das der Spammer seine Absenderadresse nicht mehr fälschen kann (das kann er natürlich weiterhin ohne Probleme - nur würde dann niemand mehr seine Spammails erhalten und er würde kein Geld verdienen..) ist die Nachforschung, wer den Spam wirklich versendet hat erst möglich und man kann entsprechende Massnahmen ergreifen (juristisch, Eintrag in BL wie z.B. spamhaus.org etc.)

Angenommen, alle nutzten SPF. Dann muß der Spammer entweder seine eigene Adresse benutzen oder erfundene (duenn.sch z.B.). Letztere fliegen aber bei einem Lookup schnell auf und auf erstre kann man prima filtern.
Ganz genau richtig.
Joe-Jobs wären leicht erkennbar bzw. würden keine Wirkung mehr zeigen, weil niemand die entsprechenden Joe-Job-Mails erhält; Bounceorgien von den Mailservern missbrauchter Domains würden der Vergangenheit angehören....

Mit Einliefer-Header meine ich den untersten Received-Eintrag. Ich dachte immer, man soll nur dem obersten (neuesten, letzten vor Auslieferung) Eintrag trauen, weil der vom eigenen Mailserver stammt. Die unterste Received-Zeile wird doch von dem SMTP-Server gemacht, an den das Mailprogramm / die Spamsoftware die Mail übergibt, also z.B. ein offenes Relay in Burma. Und um den muß es doch gehen bei SPF: Bestätigt der Nameserver des From-Domainparts, daß der erste Mailserver auf dem Weg berechtigt ist, die Mail zu senden?
Nein - es geht um den obersten (von deinem Mailserver gesetzten Received-Eintrag).

4 Beispiele zur Verdeutlichung:
Wir fälschen eine Absenderadresse:
Mein MTA smtp.sillybilly.org sendet eine Mail mit Absenderadresse roessing.org an deinen MTA.
Daraufhin fragt dein MTA den Nameserver von roessing.org ob smtp.sillybilly.org denn Mails für roessing.org versenden bzw. relayen darf.
Da in dem SPF-Eintrag vom Nameserver von roessing.org kein Eintrag für smtp.sillybilly.org vorhanden ist beantwortet der Nameserver die Anfragen von deinem MTA mit einem klaren NEIN!

Jetzt versuchen wir SPF das erste mal "auszutricksen":
Mein MTA smtp.sillybilly.org sendet eine Mail mit Absenderadresse roessing.org über das OpenRelay smtp.openrelay.com an deinen MTA.
Daraufhin fragt dein MTA den Nameserver von roessing.org ob smtp.openrelay.com denn Mails für roessing.org versenden bzw. relayen darf.
Da in dem SPF-Eintrag vom Nameserver von roessing.org kein Eintrag für smtp.openrelay.com vorhanden ist beantwortet der Nameserver die Anfragen von deinem MTA mit einem klaren NEIN!

Jetzt versuchen wir SPF das zweite mal "auszutricksen":
Mein MTA smtp.sillybilly.org sendet eine Mail mit Absenderadresse openrelay.com an das offene Relay smtp.openrelay.com um es an deinen MTA weiterzuleiten.
Daraufhin fragt openrelay.comden Nameserver von openrelay.com ob smtp.sillybilly.org denn Mails für openrelay.com versenden bzw. relayen darf.
Da in dem SPF-Eintrag vom Nameserver von openrelay.com kein Eintrag für smtp.sillybilly.org vorhanden ist beantwortet der Nameserver die Anfragen von openrelay.com mit einem klaren Nein!

Jetzt machen wir alles korrekt:
Mein MTA smtp.sillybilly.org sendet eine Mail mit Absenderadresse sillybilly.org an deinen MTA.
Daraufhin fragt dein MTA den Nameserver von sillybilly.org ob smtp.sillybilly.org denn Mails für sillybilly.org versenden bzw. relayen darf.
Da ich in dem SPF-Eintrag vom Nameserver von sillybilly.org den Eintrag für smtp.sillybilly.org gesetzt habe beantwortet der Nameserver die Anfrage von deinem MTA mit einem klaren JA!


Mit dem Wizard muß ich noch mal üben, wenn ich etwas mehr Muße habe, mich darauf zu konzentrieren; im Moment behauptet er jedenfalls, publizistik.uni-mainz.de hätte keine IP-Adresse
Hat sie auch nicht --> ergo es ist kein DNS-Eintrag vorhanden (Sache deiner Sysadmins)

Ich muß doch hoffentlich nur dann alle denkbaren Einliefer-IPs (zuhause, über DSL, sind das ja eine ganze Menge) dem trgsites-Nameserver als befugt bekannt geben, wenn ich den trgsites-Mailserver als Smarthost für einen lokalen Server nutzen will, oder?
Natürlich nicht ;)
Um Mails über den trgsites-MTA versenden zu können musst du dich ja bei ihm authentifizieren (SMTP-Auth/POP-before-SMTP).

Nochmal deutlich:
SPF ist eine Sache zwischen Mailserver und Nameserver - die Art, wie du deine Mails dem Mailserver übergibst ist eine ganz andere Geschichte.

Gruss, Norbert

[Thomas Roessing]

Nochmal deutlich:
SPF ist eine Sache zwischen Mailserver und Nameserver

Ich glaube, das muß ich mir auf den Monitor kleben - vor meinem geistigen Auge unterhalten sich immer noch irgendwelche Mailserver miteinander. Also versuche ich mal mich zu konzentrieren:

Ich habe mir jetzt nochmal den Wizard angesehen. Ich wollte einen SPF-Eintrag für trgsites.de haben, der auch roessing.org und uni-mainz.de erlaubt Mails über trgsites.de zu versenden. So ganz klar war mir bei der Eingabemaske nicht alles, aber dat kriege mer später. Ergebnis war jedenfalls:
trgsites.de. IN TXT "v=spf1 a ptr a:roessing.org a:uni-mainz.de -all"
Was mir jetzt noch unklar ist, ist eine der Erläuterungen zu den SPF-Einträgen:

a: trgsites.de's IP address is 62.67.200.20 (wind.ispgateway.de).
That server is allowed to send mail from trgsites.de.

Warum hebt das Formular so deutlich auf IP und Hostname des Weblaves ab? Der Eintrag müßte doch jetzt bedeuten, daß der Mailserver am Zielort den Nameserver von trgsites.de fragt, ob wind.ispgateway.de Mails mit trgsites.de, roessing.org und uni-mainz.de im From versenden darf. Darf er; nützt aber vermutlich nur etwas bei Forums-Benachrichtigungen und Benutzern des Formmailers. 'Richtige' Mails werden über smtprealy02.ispgateway.de verschickt. Also müßte doch eigentlich der Ziel-MTA den Nameserver von trgsites.de fragen, ob smtprelay02.ispgateway.de Mails mit den genannten Adressen im From verschicken darf?

Wenn ich's immer noch nicht gepeilt habe, müßtest Du mir vielleicht mal einen leichten Schlag auf den Hinterkopf geben; Groschen sitzt wohl ziemlich fallsicher fest...

Viel Gruß
Thomas

[sillybilly]

Originally posted by Thomas Roessing@Feb 7 2004, 06:43 PM
Ich wollte einen SPF-Eintrag für trgsites.de haben, der auch roessing.org und uni-mainz.de erlaubt Mails über trgsites.de zu versenden.
trgsites.de. IN TXT "v=spf1 a ptr a:roessing.org a:uni-mainz.de -all"
Hm - ich weiss nicht, ob ich das was du willst richtig verstanden habe.
Im Klartext bedeutet dein Eintrag:
62.67.200.20 (IP-Adresse für trgsites.de), 62.116.145.38 (IP-Adresse für a:rossing.org) und 134.93.8.111 , 134.93.8.112 , 134.93.35.2 , 134.93.35.7 , 134.93.130.77 (IP-Adressen für a:uni-mainz.de) dürfen Mails mit Absender @trgsites.de versenden.
Ist es das, was du wolltest?

Falls ja:
Jede IP-Adresse, die zu uni-mainz.de auflöst wäre zum Mailversand für @trgsites.de berechtigt (und ich bezweifle, das o.g. IPs überhaupt mailrelays sind) - du solltest das etwas genauer spezifizieren (z.B. mailrelay.uni-mainz.de - den Namen hab ich mir ausgedacht; wie die mailrelays der Uni Mainz heissen weiss ich nicht)

Falls du aber gewollt hast, das du Mails mit Absender @roessing.org und @uni-mainz.de über deinen trgsites-Mailserver versenden willst ist dieser SPF-Eintrag natürlich völlig falsch.
Dann müsstest du einen SPF-Eintrag in den Nameserver von roessing.org und uni-mainz.de machen ;)

Was mir jetzt noch unklar ist, ist eine der Erläuterungen zu den SPF-Einträgen:

a: trgsites.de's IP address is 62.67.200.20 (wind.ispgateway.de).
That server is allowed to send mail from trgsites.de.

Warum hebt das Formular so deutlich auf IP und Hostname des Weblaves ab? Der Eintrag müßte doch jetzt bedeuten, daß der Mailserver am Zielort den Nameserver von trgsites.de fragt, ob wind.ispgateway.de Mails mit trgsites.de, roessing.org und uni-mainz.de im From versenden darf. Darf er; nützt aber vermutlich nur etwas bei Forums-Benachrichtigungen und Benutzern des Formmailers. 'Richtige' Mails werden über smtprealy02.ispgateway.de verschickt. Also müßte doch eigentlich der Ziel-MTA den Nameserver von trgsites.de fragen, ob smtprelay02.ispgateway.de Mails mit den genannten Adressen im From verschicken darf?
Das hast du alles völlig korrekt verstanden :)
Logischerweise müsstest du dann im SPF-Eintrag auch smtprelay02.ispgateway.de den Versand erlauben.
Der SPF-Eintrag sähe dann (in Anlehnung an die obigen Ausführungen) so aus:
trgsites.de. IN TXT "v=spf1 a ptr a:smtprelay02.ispgateway.de a:roessing.org a:uni-mainz.de -all"
SPF-Wizard (http://spf.pobox.com/wizard.html?mydomain=trgsites.de&a=yes&mx=no&ptr=yes&a_colon=uni-mainz.de%0D%0Aroessing.org%0D%0Asmtprelay02.ispgat eway.de&mx_colon=MX+servers&ip4_colon=IP+addresses&include=&all=yes&record_so_far=%22v%3Dspf1+a+ptr+a%3Auni-mainz.de+a%3Aroessing.org+a%3Asmtprelay02.ispgatew ay.de+-all%22&use_built_from_args=1)
Hier könnte man sich auch überlegen, ob man nicht die inlude:-Funktion von SPF nutzen möchte (include:ispgateway.de) - die ganze SPF-Geschichte steht ja aber noch am Anfang und d)f hat wohl noch keine vernünftige Namensplanung der Netztopologie in dieser Hinsicht dazu gemacht; von daher sollte man eh noch abwarten - aber zum gegenwärtigen Zeitpunkt sähe der SPF-Eintrag für trgsites.de so aus.
Und wie gesagt - ob das mit uni-mainz.de so gut ist bezweifel ich. Nochmal:
Jede IP-Adresse, die zu uni-mainz.de auflöst wäre zum Mailversand für @trgsites.de berechtigt (und ich bezweifle, das o.g. IPs überhaupt mailrelays sind) - du solltest das etwas genauer spezifizieren (z.B. mailrelay.uni-mainz.de - den Namen hab ich mir ausgedacht; wie die mailrelays der Uni Mainz heissen weiss ich nicht)

Wenn ich's immer noch nicht gepeilt habe, müßtest Du mir vielleicht mal einen leichten Schlag auf den Hinterkopf geben; Groschen sitzt wohl ziemlich fallsicher fest...
Och - ich glaub du bist ganz gut davor :)

Gruss, Norbert

[sillybilly]

Nachtrag: (Editieren meines vorigen Postings ist leider nicht möglich)

Originally posted by Thomas Roessing@Feb 7 2004, 06:43 PM
Der Eintrag müßte doch jetzt bedeuten, daß der Mailserver am Zielort den Nameserver von trgsites.de fragt, ob wind.ispgateway.de Mails mit trgsites.de, roessing.org und uni-mainz.de im From versenden darf.
Flachs!
wind.ispgateway.de darf keine Mails mit roessing.org und uni-mainz.de im From versenden!
rossing.org darf Mails mit trgsites.de im From versenden.
uni-mainz.de darf Mails mit trgsites.de im From versenden.

[Thomas Roessing]

Moin,
danke nochmal für Deine ausführlichen Erläuterungen; ich fürchte gleichwohl, daß das ein Mords-Spaß wird, wenn sowas eingeführt wird. Da kann man dann ein eigenes Supportforum für SPF einrichten. Ich habe schon ziemlich lange kein Computer-Konstrukt mehr erlebt, bei dem ich *solche* Verstädnis- und Durchblick-Probleme hatte...

Das mit dem Editieren gucke ich mir naher mal an; das sollte eigentlich unbegrenzt funktionieren.

Viel Gruß
Thomas