SPF Record Schlund
Thomas Wildgruber
seit längerem arbeit Schlund mit einer SPF Codierung der E-Mail Absender
Adressen, das hat dann ständig so ausgesehen und war täglich zu Hunderten
in unserem Spamfilter zu finden:
SRS0=YLYh=4T=direct.ca=eliseo...@srs.kundenserver.de
Und das bei Absender von denen ich nicht glaube, dass die einen SPF Record
registriert haben. Des Weiteren ist 99% davon eindeutig Spam. Dieses
restliche Prozent ist dabei das, welches Probleme macht. Es kommt aus mir
nicht bekannten Gründen ab und an mal vor, dass ein Kunde (oder wer auch
immer) eine Mail über unseren Backup MX routet, der bei Schlund gehostet
ist und ebenfalls false positve als Spam erkannt wird. Trend Micro versucht
nun schon seit längerem die Ursache zu finden, bislang wird davon
ausgegangen, dass die Domain @srs-kundenserver.de auf eine Blackliste
gerutscht ist, weil eben 99% Spam darüber versandt wurde.
Jetzt taucht seit Kurzem (seit 25.02.06 um genau zu sein) ein neuer Eintrag
im Header der über Schlund gerouteten Mails auf:
Received-SPF: none (mxeu2: 82.243.86.243 is neither permitted nor denied by
domain of lycos.com)
Das Aukommen von als Spam erkannten Mails mit srs-kundenserver.de als
Absender ist *dramatisch* gesunken. Für mich ist es ganz offensichtlich,
dass Schlund erst seit 25.02 das Vorhanden sein eines SPF Records
überprüft, streiten aber jegliche Änderung in ihrem Setup ab.
Hat jemand ähnliche Erfahrungen mit dem SPF Gedöhns bei Schlund gemacht?
Wir versuchen hier bereits seit Wochen das Problem zu lösen, Schlund war zu
keiner konstruktiven Mithilfe bereit und jetzt, so hat es den Anschein,
können wir und Trend Micro wieder von vorne anfangen.
Bye Tom
--
"Manches Gewissen ist nur rein, weil es nie benutzt wurde"
(Robert Lembke)
Rene Schumann
> Das Aukommen von als Spam erkannten Mails mit srs-kundenserver.de als
> Absender ist *dramatisch* gesunken. Für mich ist es ganz offensichtlich,
> dass Schlund erst seit 25.02 das Vorhanden sein eines SPF Records
> überprüft, streiten aber jegliche Änderung in ihrem Setup ab.
>
> Hat jemand ähnliche Erfahrungen mit dem SPF Gedöhns bei Schlund gemacht?
> Wir versuchen hier bereits seit Wochen das Problem zu lösen, Schlund war zu
> keiner konstruktiven Mithilfe bereit und jetzt, so hat es den Anschein,
> können wir und Trend Micro wieder von vorne anfangen.
>
> Bye Tom
Hallo,
SRS und SPF sind nicht das gleiche.
Mit SPF kann man steuern ob der Sender von dieser IP aus erlaubt ist.
Mit SRS schreibt man bei Weiterleitungen den Sender um.
Wenn du viele Mails mit srs.kundenserver.de reinbekommst liegt das daran,
das viele der Mails zuerst an eine Mailadresse bei 1&1 gingen und
dann an deine externe weitergeleitet wurde.
Gruß
Rene
Thomas Wildgruber
> SRS und SPF sind nicht das gleiche.
> Mit SPF kann man steuern ob der Sender von dieser IP aus erlaubt ist.
> Mit SRS schreibt man bei Weiterleitungen den Sender um.
OK
> Wenn du viele Mails mit srs.kundenserver.de reinbekommst liegt das daran,
> das viele der Mails zuerst an eine Mailadresse bei 1&1 gingen und
> dann an deine externe weitergeleitet wurde.
Das eigentliche Problem liegt ja gar nicht bei Schlund, auch wenn ich davon
ausgehe, dass sie erst seit kurzem in diesem Setup etwas geändert haben.
Kamen früher *alle* Mails die über Schlund geroutet wurden, mit dem
SRS-[blafasel]@srs.kundenserver.de daher, so ist dies seit neuestem nicht
mehr so. Vor zwei Wochen hatten wir noch weit über 100 Mails täglich mit
SRS-... im Spamfilter, sind es jetzt grad mal drei, oder vielleicht auch
vier. Auch haben wir eine neue Zeile im Header der über Schlund gerouteten
Mails endeckt:
Received-SPF: neutral (mxeu16: 213.23.73.25 is neither permitted nor denied
by domain of aol.com) client-ip=213.23.73.25;
Oder statt 'neutral' auch mal 'none' oder 'fail'. Das aber ist neu und ganz
plötzlich ist das Aufkommen der SRS-...@ codierten Absenderadressen
*extrem* stark rückläufig.
Warum wir aber den ganzen Hickhack haben, da kann Schlund jetzt auch nichts
dafür. Wir hatten früher unseren primären MX auch bei Schlund gehabt -> Die
ganzen Postfächer eben und haben uns vor einem viertel Jahr einen eigenen
MTA, mit eigenem primären MX Eintrag zugelegt und lassen noch Schlund MTAs
als Backup-MX mitlaufen.
Spammer haben es sich offensichtlich angewohnt gerne gleich mal den
Backup-MX zu verwenden aber leider nicht nur die. Aus mir nicht
erklärlichen Gründen gibt es bei uns /Kommunikationspartner/ die entweder
einem verwaisten DNS Eintrag zufolge - oder warum auch immer - immer noch
über den damals primären und jetzt eben sekundären MX Eintrag Mails zu uns
versenden. Also auch erstmal den (Backup) MX bei Schlund ansprechen. Was
bislang zur Folge hatte, dass diese auch alle mit dem SRS[blafasel)@...
daherkommen.
Und weil das noch nicht reicht, werden von TrendMicro alle Mails die von
Schlund kommen (bzw. kamen) als Spam erkannt und in die Quarantäne gesteckt
(mit false positive). Warum? Erst ist TM (FisrtLevelSupport) davon
ausgegangen, dass der Filter "lernt" und einfach erkannt hat, dass von
@srs.kundenserver.de (oder auch mountng.kundenserver.de) fast nur Spam
kommt -> Also schwupp, ab in eine Blacklist (die so aber nicht einsehbar
ist) Das hat nun die nächste Eskalationsstufe bei TM dementiert, mit der
Aussage "Unser Spamfilter lernt nichts automatisch dynamisch dazu". Jetzt
dreht sich bei TM der Fokus um die Art der SRS-Adresse. Sie glauben nun,
dass es daran liegen könnte (und sehen das Problem diesbezüglich sogar bei
ihnen selbst ;) nur können sie es nicht reproduzieren :-(
Wir haben also drei voneinander unabhängige Probleme:
1) Schlund codiert alles was da daher kommt mit SRS- usw. (Zumindest taten
sie es bis vor kurzem, behaupten aber felsenfest nichts an ihrem System
geändert zu haben (Zitat: "in letzter Zeit wurden diesbezüglich keine
Änderung am Mailsystem vorgenommen.")
2) Manche MTAs scheinen fragwürdige DNS Server zu befragen oder warum
kommen heute immer noch Mails über unseren alten MX Eintrag daher - Der ja
jetzt der Backup MX ist. Und sogar das ist nicht reproduzierbar, weil die
nächsten 20 Mails vom selben MTA plötzlich wieder richtig geroutet werden.
BTW: Unser MTA war definitiv durchgängig online und nahm jederzeit Mails
an. Das SMTP Log bestätigt permanent Traffic zu den fraglichen Zeiten,
desweiteren hosten wir mehrere Maildomains auf unseren MTA und haben die
Probleme auschliesslich mit der bei Schlund registrierten Domain. Fazit:
Wohl alles was im Internet gecachet wird ist IMHO störanfällig ;-)
3) TrendMicro kommt mit der SRS- Geschichte nicht zurecht.
Bei allen drei Problemen kann ich eigentlich nur zuschauen, wobei ich
hoffen kann, dass sich das Problem 3) durch Änderungen im Setup bei Problem
1) jetzt nicht mehr so dramatisch darstellt, da es ja eh nur die im Problem
2) betroffen hat und die kommen jetzt wieder alle mit einem vernünftigen
'return path:' daher. ;-)
Ich dreh mich seit Wochen im Kreis und kann eigentlich keinem recht die
Schuld geben ;-))
Oder unterliege ich völlig einem Irrtum? Das kann ich aber eigentlich nicht
mehr recht glauben.
Bye Tom
--
"Der Retter der Welt ist ein Pinguin und Linus Torvalds ist sein Prophet "
Daniel Weber
> Kamen früher *alle* Mails die über Schlund geroutet wurden, mit dem
> SRS-[blafasel]@srs.kundenserver.de daher, so ist dies seit neuestem nicht
> mehr so.
Das sollte aber für einen Spamfilter weder im einen Fall noch im anderen
Fall ein Indiz für oder gegen Spam sein. Wenn doch, dann sollte der
Hersteller da mal nachbessern.
> Spammer haben es sich offensichtlich angewohnt gerne gleich mal den
> Backup-MX zu verwenden aber leider nicht nur die. Aus mir nicht
> erklärlichen Gründen gibt es bei uns /Kommunikationspartner/ die entweder
> einem verwaisten DNS Eintrag zufolge - oder warum auch immer - immer noch
> über den damals primären und jetzt eben sekundären MX Eintrag Mails zu uns
> versenden. Also auch erstmal den (Backup) MX bei Schlund ansprechen.
Seit wann ist es denn umgestellt? Evtl. könntest Du uns ja auch einen
fraglichen Domainnamen nennen, dann könnte man mal nachforschen.
> Und weil das noch nicht reicht, werden von TrendMicro alle Mails die von
> Schlund kommen (bzw. kamen) als Spam erkannt und in die Quarantäne gesteckt
> (mit false positive). Warum?
Schreibt TrendMicro dazu keinen Bericht? Wenn es tatsächlich nirgends
Reports, Logeinträge oder sonstwas gibt, die _begründen_ warum
TrendMicro die Mails für Spam hält, dann würde ich das Ding schleunigst
an den Hersteller zurückgeben.
> Wir haben also drei voneinander unabhängige Probleme:
Ich denke, Du hast nur ein Problem: Dein Spam-Filter protokolliert
unzureichend/garnicht, warum er Mails aussortiert. Dieses Problem ist
als erstes zu beheben, danach _weißt_ Du warum manche Mails aussortiert
werden und musst kein Rätselraten mehr betreiben.
Bye,
Daniel
--
DynFX MailServer 3.0 fuer Windows
Testversion: http://www.dynfx.de/downloads/
Support: news://news.dynfx.net/dynfx.public.mailserver.misc
Rene Schumann
> 2) Manche MTAs scheinen fragwürdige DNS Server zu befragen oder warum
> kommen heute immer noch Mails über unseren alten MX Eintrag daher - Der ja
> jetzt der Backup MX ist. Und sogar das ist nicht reproduzierbar, weil die
> nächsten 20 Mails vom selben MTA plötzlich wieder richtig geroutet werden.
> BTW: Unser MTA war definitiv durchgängig online und nahm jederzeit Mails
> an. Das SMTP Log bestätigt permanent Traffic zu den fraglichen Zeiten,
> desweiteren hosten wir mehrere Maildomains auf unseren MTA und haben die
> Probleme auschliesslich mit der bei Schlund registrierten Domain. Fazit:
> Wohl alles was im Internet gecachet wird ist IMHO störanfällig ;-)
Klingt mehr danach, das der primary doch nicht erreichbar war.
Auch Spammer nutzen gerne den Secondary.
Deaktivieren Sie doch einfach den secondary MX Eintrag, es gibt heutzutage
nur noch Nachteile dadurch.
Juergen P. Meier
> Deaktivieren Sie doch einfach den secondary MX Eintrag, es gibt heutzutage
> nur noch Nachteile dadurch.
Durch deaktivieren von backup-MX Servern entstehen nicht erst
heutzutage nur Nachteile.
Dein Tip ist bestenfalls mit enormer Vorsicht zu geniessen, wenn nicht
sogar voellig Kontraproduktiv.
Thomas Wildgruber
>> 2) Manche MTAs scheinen fragwürdige DNS Server zu befragen oder warum
>> kommen heute immer noch Mails über unseren alten MX Eintrag daher - Der ja
>> jetzt der Backup MX ist. Und sogar das ist nicht reproduzierbar, weil die
>> nächsten 20 Mails vom selben MTA plötzlich wieder richtig geroutet werden.
>> BTW: Unser MTA war definitiv durchgängig online und nahm jederzeit Mails
>> an. Das SMTP Log bestätigt permanent Traffic zu den fraglichen Zeiten,
>> desweiteren hosten wir mehrere Maildomains auf unseren MTA und haben die
>> Probleme auschliesslich mit der bei Schlund registrierten Domain. Fazit:
>> Wohl alles was im Internet gecachet wird ist IMHO störanfällig ;-)
>
> Klingt mehr danach, das der primary doch nicht erreichbar war.
Das wäre ein wirklich grenzenloser Zufall, dass immer ausgerechnet der
selbe Sender den Moment erwischt, an dem unser primary MX ausgefallen sein
soll. False positive wird fast ausschliesslich dieser eine Sender als spam
erkannt. Von ein oder zwei Ausnahmen mal abgesehen.
> Auch Spammer nutzen gerne den Secondary.
Jupp, das wird deutlich, wenn man die Quarantäne analysiert.
> Deaktivieren Sie doch einfach den secondary MX Eintrag, es gibt heutzutage
> nur noch Nachteile dadurch.
Dieser Workaround kommt immer wieder, darüber sollte man mal nachdenken.
Auffällig bei Schlund ist dennoch die signifikante Reduzierung, der SRS
codierten Absenderadressen. Waren es vor dem 25.02 noch weit über 100
*täglich* sind es seitdem *insgesamt* nicht mal ein Dutzend, also weniger
als eine pro Tag im Schnitt. Also die Aussage, sie hätten an ihrem
Mailsystem diesbezüglich keine Änderungen vorgenommen halte ich schlicht
für /unwahr/. Letztlich kann mir bei Schlund ja auch keiner sagen wo die
SRS codierten Absenderadressen geblieben sind.
SRS habe ich im Zusammenhang mit SPF verstanden und sollte letztlich wohl
dem empfangenen Mailserver signalisieren, dass es sich bei dieser Mail um
eine weitergeleitete Mail handelt und somit eine Abfrage nach dem SPF
Record technisch bedingt scheitert (ung ggf. vom MTA Relay schon
durchgeführt wurde). Es hatte den Eindruck, dass Schlund generell jede über
ihr Relay weitergeleitete Mail, den Absender SRS codierte und dies jetzt
nicht mehr tut.
Selbst wenn ich ein Testszenario mit einer Weiterleitung die Schlund
involviert aufbaue, wird der Absender nicht mehr SRS codiert.
[web.de]
|
+------------> Email an 'te...@abc.de' --------------> |Schlund MTA|
|
[unser MTA] <---- Weiterleitung an 'zi...@unseredomain.de' <---+
|
+------------> Postfach des Users 'test'
Wobei abc.de eine bei schlund gehostete Domain ist.
Habe ich SRS richtig verstanden hätte Schlund die Adresse 'te...@abc.de' ins
Format [siehe 1] bringen müssen. Tut es aber nicht und das obwohl dies bei
jeder Mail vor dem 25.02 so gewesen ist und Schlund nichts geändert haben
möchte. Wo ist also die SRS Codierung geblieben? ;-))
[1] SRS0=hash=day=abc.de=te...@srs.kundenserver.de
Da ich dieses Verhalten mit den SRS codierten Absenderadresse nun überhaupt
nicht mehr reproduzieren kann, muss ich wohl das Ticket bei TrendMicro
ungelöst schliessen lassen, was ich schade finde, haben wir doch wochenlang
daran gearbeitet. Und würde Schlund mit offenen Karten spielen, hätten wir
uns einige Stunden der Verwirrung und für den Aufbau alternativer
Testszenarien gespart.
BTW: Wir können uns ruhig Dutzen, ein 'Sie' finde ich ungewöhnlich im
Newsnet ;-)
Rene Schumann
> Durch deaktivieren von backup-MX Servern entstehen nicht erst
> heutzutage nur Nachteile.
>
> Dein Tip ist bestenfalls mit enormer Vorsicht zu geniessen, wenn nicht
> sogar voellig Kontraproduktiv.
inwiefern?
Rene Schumann
> Auffällig bei Schlund ist dennoch die signifikante Reduzierung, der SRS
> codierten Absenderadressen. Waren es vor dem 25.02 noch weit über 100
> *täglich* sind es seitdem *insgesamt* nicht mal ein Dutzend, also weniger
> als eine pro Tag im Schnitt. Also die Aussage, sie hätten an ihrem
> Mailsystem diesbezüglich keine Änderungen vorgenommen halte ich schlicht
> für /unwahr/.
Vielleicht schreibt Schlund jetzt wirklich nur noch Weiterleitungen mit
gültigem SPF Eintrag nach SRS um und der Support weiss davon einfach
nichts. ;-)
Thomas Wildgruber
> Vielleicht schreibt Schlund jetzt wirklich nur noch Weiterleitungen mit
> gültigem SPF Eintrag nach SRS um und der Support weiss davon einfach
> nichts. ;-)
Autsch - Das wäre kein guter Service...
Zumal ich dieses Verhalten bereits mehrfach hinterfragt habe, telefonisch
und per E-Mail und bekam immer eine Anwort alà "Nein bei uns wurde nichts
geändert"
Aber "selten ein Schaden wo nicht auch ein Nutzen dabei" heisst es doch so
schön -> Zumindest habe ich jetzt schon mal was von SPF und SRS gehört.
Vor ein paar Wochen noch hätte ich diese Abkürzungen aller
Wahrscheinlichkeit nach der Automobilbranche zugeordnet ;-))
Bye Tom
& in diesem Sinne... ;-)
--
"Sie wissen, wir leben im Zeitalter der Abkürzungen. Ehe ist die Kurzform
für lateinische "errare humanum est" ("Irren ist menschlich")."
(Robert Lembke)
Juergen P. Meier
Dysfunktionale Mailserver (von denen es genug gibt) und dein MX ist
mal fuer paar Minuten nicht erreichbar. -> Mail bounced
Daniel Weber
> Auffällig bei Schlund ist dennoch die signifikante Reduzierung, der SRS
> codierten Absenderadressen. Waren es vor dem 25.02 noch weit über 100
> *täglich* sind es seitdem *insgesamt* nicht mal ein Dutzend, also weniger
> als eine pro Tag im Schnitt.
Hat sich in diesem Zusammenhang evtl. auch die Anzahl der über Schlund
eingelieferten E-Mails reduziert?
> SRS habe ich im Zusammenhang mit SPF verstanden und sollte letztlich wohl
> dem empfangenen Mailserver signalisieren, dass es sich bei dieser Mail um
> eine weitergeleitete Mail handelt und somit eine Abfrage nach dem SPF
> Record technisch bedingt scheitert (ung ggf. vom MTA Relay schon
> durchgeführt wurde).
Jein, durch die SRS-Kodierung wird ja die Envelope-From-Domain geändert,
somit werden also eventuelle SPF-Queries einfach auf eine eigene
Envelope-From-Domain gelenkt, der SPF-Query kann also nicht mehr wegen
"einliefernder Host passt nicht zur Envelope-From-Domain" scheitern.
> Wo ist also die SRS Codierung geblieben? ;-))
Wichtiger finde ich noch immer die Frage: Wo sind die Auskünfte der
TM-Software zu den Gründen der Spam-Beurteilung?
> Da ich dieses Verhalten mit den SRS codierten Absenderadresse nun überhaupt
> nicht mehr reproduzieren kann, muss ich wohl das Ticket bei TrendMicro
> ungelöst schliessen lassen, was ich schade finde, haben wir doch wochenlang
> daran gearbeitet.
Lass dann aber gleich das nächste Aufmachen, damit sie ein Logging bzgl.
der Entscheidungsgründe mit einbauen.
Bye,
Daniel
Thomas Wildgruber
>> Auffällig bei Schlund ist dennoch die signifikante Reduzierung, der SRS
>> codierten Absenderadressen. Waren es vor dem 25.02 noch weit über 100
>> *täglich* sind es seitdem *insgesamt* nicht mal ein Dutzend, also weniger
>> als eine pro Tag im Schnitt.
>
> Hat sich in diesem Zusammenhang evtl. auch die Anzahl der über Schlund
> eingelieferten E-Mails reduziert?
Das ist jetzt schwer zu sagen, da diese ja nicht mehr so auffällig
(SRS=...bla.de=fa...@srs.kundenserver.de) daherkommen aber im SMTP Log
taucht 'moutng.kundenserver.de' schon noch häufiger auf. Ich denke eher
nicht, dass sich die Anzahl reduziert hat. Viel spannender dürfte die
Anzahl der false prositive als Spam erkannten Mails sein, da wir TM ja
nicht mehr mit einer SRS codierten Envelope-From Adresse konfontieren,
sollte die sich jetzt auch reduzieren.
BTW: Schlund hat sich jetzt doch zu einem Statement hinreissen lassen, dass
sie nur noch Absender SRS codieren, welche einen SPF Record hinterlegt
haben und im Header den Status der SPF Abfrage hinterlegen.
>> [...]
>> Wo ist also die SRS Codierung geblieben? ;-))
>
> Wichtiger finde ich noch immer die Frage: Wo sind die Auskünfte der
> TM-Software zu den Gründen der Spam-Beurteilung?
> [...]
Jo aber dieses Feature hat wohl nur die Enterprise Edition, wir denken über
ein Upgrade nach.
Rene Schumann
> Dysfunktionale Mailserver (von denen es genug gibt) und dein MX ist
> mal fuer paar Minuten nicht erreichbar. -> Mail bounced
Welche dysfunktionalen MTAs kennst du, die bei einem Timeout eine
Mail hart bouncen?
Daniel Weber
> Viel spannender dürfte die
> Anzahl der false prositive als Spam erkannten Mails sein, da wir TM ja
> nicht mehr mit einer SRS codierten Envelope-From Adresse konfontieren,
> sollte die sich jetzt auch reduzieren.
Wenn TM tatsächlich aufgrund von SRS-Adressen irgendwas wegwirft, dann
sollte dort mal jemand ordentlich getreten werden!
>>> [...]
>>> Wo ist also die SRS Codierung geblieben? ;-))
>> Wichtiger finde ich noch immer die Frage: Wo sind die Auskünfte der
>> TM-Software zu den Gründen der Spam-Beurteilung?
>> [...]
>
> Jo aber dieses Feature hat wohl nur die Enterprise Edition, wir denken über
> ein Upgrade nach.
Ich finde Eure Geduld erstaunlich. So ein "Feature" sollte IMO vor allen
anderen Features eines Spamfilters enthalten sein.
Bye,
Daniel
Thomas Wildgruber
> [...]
>> Jo aber dieses Feature hat wohl nur die Enterprise Edition, wir denken über
>> ein Upgrade nach.
>
> Ich finde Eure Geduld erstaunlich. So ein "Feature" sollte IMO vor allen
> anderen Features eines Spamfilters enthalten sein.
Ja, man wird leidensfähiger im Laufe der Zeit ;-) Schuld sind wir selber,
wir hätten uns bei der Evaluierung mehr Zeit lassen sollen. Dann hätten wir
uns für ein anderes Produkt entscheiden können.
Bye Tom
--
"Das Denken ist das Selbstgespräch der Seele."
(Plato)
Juergen P. Meier
Die Mailserver eines grossen Telekommunikationsunternehmens (Stand '04)
Die Mailserver der DBAG (Stand '03)
Desweiteren haben MXe genau garnichts mit SPF zu tun. (Ausser das man
den Weg der Mail von den Backup-MXen zum zustaendigen Mailserver -
meist der primary MX - natuerlich nicht mit hier unpassenden
Filtermechanismen verbockt.)
Juergen
--
Juergen P. Meier - "This World is about to be Destroyed!"
end
If you think technology can solve your problems you don't understand
technology and you don't understand your problems. (Bruce Schneier)
Rene Schumann
> Die Mailserver eines grossen Telekommunikationsunternehmens (Stand '04)
> Die Mailserver der DBAG (Stand '03)
War das alles oder kommt da noch etwas aktuelles mit Gewicht?
> Desweiteren haben MXe genau garnichts mit SPF zu tun. (Ausser das man
> den Weg der Mail von den Backup-MXen zum zustaendigen Mailserver - meist
> der primary MX - natuerlich nicht mit hier unpassenden Filtermechanismen
> verbockt.)
Vielleicht nochmal die SPF RFC durchlesen bevor weitere "MXe
haben garnichts mit SPF zu tun" Aussagen kommen.
Ein abschalten des Secondary hätte verhindert das Mails per SRS
umgeschrieben werden, wenn sie aus irgendeinem Grunde über den secondary
laufen.
Genau darum ging es, vielleicht nochmal von vorne lesen?
Juergen P. Meier
> Am Tue, 07 Mar 2006 12:14:40 +0000 schrieb Juergen P. Meier:
>
>> Die Mailserver eines grossen Telekommunikationsunternehmens (Stand '04)
>> Die Mailserver der DBAG (Stand '03)
>
> War das alles oder kommt da noch etwas aktuelles mit Gewicht?
Ich weis nicht ob sie das aktuelle nicht immernoch so tun.
>> Desweiteren haben MXe genau garnichts mit SPF zu tun. (Ausser das man
>> den Weg der Mail von den Backup-MXen zum zustaendigen Mailserver - meist
>> der primary MX - natuerlich nicht mit hier unpassenden Filtermechanismen
>> verbockt.)
>
> Vielleicht nochmal die SPF RFC durchlesen bevor weitere "MXe
Hahahaha. Guter Witz. Kannst du die RFC Nummer des SPF-RFC nennnen?
Ne, lass mal. Das war eine rethorische Frage. Es gibt keins.
(Draft != RFC. Details dazu stehen in RfC 2026)
> haben garnichts mit SPF zu tun" Aussagen kommen.
MXe koennen natuerlich wie jeder andere Empfangs-MTA irgendwelche SPF
DNS Records fuer ihre lokale Mailfilterpolicy heranziehen und
auswerten.
Die Mailsysteme, die von relayenden MXen die relayten Mails annehmen,
duerfen natuerlich fuer diese MXe keinerlei Sender-Based
Filterpolicies anwenden. Das ist jedoch so selbstverstaendlich, dass
man darueber eigentlich nicht weiter schreiben muss.
> Ein abschalten des Secondary hätte verhindert das Mails per SRS
> umgeschrieben werden, wenn sie aus irgendeinem Grunde über den secondary
> laufen.
Eingehend. Aber das ware ein reichlich Dummliches Herumdocktorn an den
falschen Symptomen.
> Genau darum ging es, vielleicht nochmal von vorne lesen?
Korrekt waere im Fall Mail-laeuft-ueber-secondary-MX: Alle
secondary MXe auf dem Zielserver (also dort, wohin diese weiterleiten,
ist halt meistens, aber nicht immer der primaere MX) mussen Ausnahmen
in jeglichen client/sender Hostbasierten Mailfilterregeln darstellen.
Das ist wie beim Militaer: Gewehrlaeufe muessen auf den Gegner, nicht
auf die eigenen Fuesse gerichtet werden. Den Gewehrlauf zuloeten ist
dabei nicht die richtige Hilfe.
Rene Schumann
> Die Mailsysteme, die von relayenden MXen die relayten Mails annehmen,
> duerfen natuerlich fuer diese MXe keinerlei Sender-Based
> Filterpolicies anwenden. Das ist jedoch so selbstverstaendlich, dass
> man darueber eigentlich nicht weiter schreiben muss.
Ein MX und ein Mailrelay sind zwei verschiedene Dinge.
Dachte eigentlich das wäre selbstverständlich ... scheinbar nicht
überall.
> Das ist wie beim Militaer: Gewehrlaeufe muessen auf den Gegner, nicht
> auf die eigenen Fuesse gerichtet werden. Den Gewehrlauf zuloeten ist
> dabei nicht die richtige Hilfe.
>
> Juergen
Um bei deinem Beispiel zu bleiben.
Sorge dafür das dein Gegner nicht schon auf deinen Füssen sitzt, dann
brauchst du auch das Gewehr nicht auf deine Füsse richten. ;-)
Den der secondary MX Eintrag sorgt dafür das dein Gegner bis an deine
Füsse kommt. ;-)
Daniel Weber
> Sorge dafür das dein Gegner nicht schon auf deinen Füssen sitzt, dann
> brauchst du auch das Gewehr nicht auf deine Füsse richten. ;-)
> Den der secondary MX Eintrag sorgt dafür das dein Gegner bis an deine
> Füsse kommt. ;-)
Außer Du hast den secondary ebenfalls unter eigener Kontrolle und
stattest ihn mit derselben Policy aus, wie den primary.
Bye,
Daniel
Rene Schumann
> Außer Du hast den secondary ebenfalls unter eigener Kontrolle und
> stattest ihn mit derselben Policy aus, wie den primary.
>
> Bye,
> Daniel
jenau ;-)
TheBa...@gmail.com
Daniel Weber schrieb:
>
> Wenn TM tatsächlich aufgrund von SRS-Adressen irgendwas wegwirft, dann
> sollte dort mal jemand ordentlich getreten werden!
Dies ist ein Prozess, der bereits am laufen ist. Aber wie es so oft
ist, solange kein großer Kunde dahintersteht kann das etwas dauern
> > Jo aber dieses Feature hat wohl nur die Enterprise Edition, wir denken über
> > ein Upgrade nach.
>
> Ich finde Eure Geduld erstaunlich. So ein "Feature" sollte IMO vor allen
> anderen Features eines Spamfilters enthalten sein.
Welche AntiSpam Software sagt dir schon, aus genau welchen Gründen
eine Mail gefiltert wurde? Einige grobe Infos gibt es immer, auch bei
der eingesetzen Software. Zu sehr ins Detail wird aber kaum ein
Hersteller gehen, weil man dann seine internen Techniken veraten
würde.
Stephan
Daniel Weber
> Welche AntiSpam Software sagt dir schon, aus genau welchen Gründen
> eine Mail gefiltert wurde?
| F:\Benutzer\Daniel\spam>antispam 2006030904414302760002.eml
| DynFX AntiSpam Decider 4.00.4550.1
| ----------------------------------
|
| Using global configuration file...
| Loading Bayes-DB d:\mail\as_worddb...
| Using global bayes db...
| Testing "2006030904414302760002.eml"...
| unresolvable hop
| DNS2: 222.174.232.252 in cbl.abuseat.org: Blocked
| - see http://cbl.abuseat.org/lookup.cgi?ip=222.174.232.252
| DNS3: 222.174.232.252 in blackholes.five-ten-sg.com: blocked
| by blackholes.five-ten-sg.com
| DNSR: 222.174.232.252 in china.blackholes.us:
| Listed by china.blackholes.us
| content-type multipart/alternative
| bayes word-filter spam probability: 1.000000
| This Mail is probably Spam: 0.997144
Ich finde das schon ziemlich genau.
> Einige grobe Infos gibt es immer, auch bei der eingesetzen Software.
Aber bei den fraglichen Mails wohl keinerlei Information, sonst müsste
der OP nicht rätselraten, warum die Mails aussortiert wurden.
> Zu sehr ins Detail wird aber kaum ein Hersteller gehen, weil man dann
> seine internen Techniken veraten würde.
Spätestens wenn False-Positives auftreten, dann führt kein Weg daran
vorbei, ins Detail zu gehen, weil man herausfinden muss, warum eine Mail
fälschlicherweise erkannt wird um an der jeweiligen Schraube drehen zu
können.
Bye,
Daniel
Stephan Kühn
| DynFX AntiSpam Decider 4.00.4550.1
| ----------------------------------
|
| Using global configuration file...
| Loading Bayes-DB d:\mail\as_worddb...
| Using global bayes db...
| Testing "2006030904414302760002.eml"...
| unresolvable hop
| DNS2: 222.174.232.252 in cbl.abuseat.org: Blocked
| - see http://cbl.abuseat.org/lookup.cgi?ip=222.174.232.252
| DNS3: 222.174.232.252 in blackholes.five-ten-sg.com:
blocked
| by blackholes.five-ten-sg.com
| DNSR: 222.174.232.252 in china.blackholes.us:
| Listed by china.blackholes.us
| content-type multipart/alternative
| bayes word-filter spam probability: 1.000000
| This Mail is probably Spam: 0.997144
>Ich finde das schon ziemlich genau.
Was ist daran genau?
Sorry, aber das kann ich nicht nachvollziehen. Wie ist den die
Spam-Score entstanden? Das kann man hier nicht herauslesen.
Daniel Weber
> Sorry, aber das kann ich nicht nachvollziehen. Wie ist den die
> Spam-Score entstanden? Das kann man hier nicht herauslesen.
Du siehst die zutreffenden Kriterien. Genau das, was der OP nicht weiß.
Bye,
Daniel
Stephan Kühn
Ich sehe nur, dass ein paar DNS-Abfragen gemacht wurden. Das wars.
Das hier sagt wenig aus:
--->
|bayes word-filter spam probability: 1.000000
|This Mail is probably Spam: 0.997144
<---
Wenn man es "richtig" machen würde, müßte man sehen, was den bayes
word-filter dazu veranlasst, die Score 1.000 zu vergeben. Oder
verstehen wir uns falsch?
Gruß,
Stephan
Daniel Weber
> Wenn man es "richtig" machen würde, müßte man sehen, was den bayes
> word-filter dazu veranlasst, die Score 1.000 zu vergeben.
Dafür gibts -v (nicht jeder hat Lust sich regelmäßig durch x Seiten zu
graben), allerdings ist es gerade bei Bayes-Filtern IMO nicht wirklich
interessant, durch welche Wörter er dazu kam, weil man hier Mailweise
und nicht Wortweise trainiert.
Bye,
Daniel
Jakob Hirsch
> Welche AntiSpam Software sagt dir schon, aus genau welchen Gründen
Spamassassin.
Stephan Kühn
Jakob Hirsch schrieb:
> TheBa...@gmail.com wrote:
>
> > Welche AntiSpam Software sagt dir schon, aus genau welchen Gründen
>
> Spamassassin
Ersetze "Welche AntiSpam Software" durch "Welche kommerzielle AntiSpam
Software".
Ich glaube kein kommerzieller Anbieter kann es sich leisten zu viel
über die Erkennung auszusagen - immerhin sind viele AntiSpam
Algorithmen quasi ein Betriebsgeheimnis .
Stephan