Absender Validierung ( SPF/RDNS ) & Restriktierung

[PowerShellAdmin 169]

Moin,

mich würde an dieser Stelle einfach mal eure Meinung und Lösungsansatz interessieren.

 

SPF Records sind nicht durchgehend verbreitet und ein korrektes RDNS Setup "war" nie ein Standard.

Eine saubere DNS/RDNS Konfiguration ist aber seit Jahren in den meisten Konzepten bestandteil und wird auch von vielen großen Providern umgesetzt.

 

Von obigen ausgehend komme ich derzeit zu der Aufassung:

• SPF Records sind nicht zwingend erforderlich, müssen aber berücksichtigt werden falls vorhanden.
• DNS/RDNS Prüfung sollten für jede Email vorgenommen werden.

Abschließend - mir ist durchaus bewusst, dass Spammer heute großteils über ganz andere Kanäle fungieren und dies nur Teil eines Lösung / Konzepts ist, ähnlich wie Greylisting

=> Am Ende zählt aber die Summe.

 

 

Nun würde mich hier die Umsetzung interessieren. Im Exchange 2010 gibt es die Option Sender-ID und baut damit ja bereits eine Technik vor.

Aber mir scheint diese Technik ungenügend:

•  RDNS Prüfung wird nicht ausgeführt.
•  Wenn ich von einen gültigen SMTP Server die Domäne fälsche, erhält diese Email lediglich den Status Softfail udn wird nicht direkt gesperrt.

Zusätzlich gibt es die Absenderzuverlässigkeit - Hier habe ich ein Scoring anhand dessen ich wohl auch die RDNS Prüfung indirekt mit einfließen lassen kann.

Aber dazu kommt dann noch das N Stunden Blacklisting und es ist mir nicht transparent genug.

Das Feature ist völlig untransparent und das Scoring auch nicht gut dokumentiert.

 

Den Punkt SPF könnte ich via Transport- oder Virenschutz-Regel lösen => Headerfields prüfen und zurückweisen.

 

 

 

VG PSAdmin

bearbeitet 14. April 2016 von PowerShellAdmin

[testperson 1.680]

Hi,

 

vielleicht genügt der Exchange integrierte SPAM Filter einfach nicht deinen Anforderungen ;)

 

Gruß

Jan

[NorbertFe 2.035]

SPF Records sollten berücksichtigt werden, aber das kann man eben nicht beeinflussen. Der Eigentümer der Domäne wünscht sich wahrscheinlich, dass es berücksichtigt wird. Da aber viele schon den SPF Record mit ~ bauen, gehe ich davon aus, dass sie selten wissen, was sie tun. ;)

Ich persönlich bin pro SPF, aber gibt viele die das für "umständlich" oder nicht implementierbar für ihre Domain halten, weil sie Umleitungen usw. nutzen müssen/wollen.

 

Wenn ich von einen gültigen SMTP Server die Domäne fälsche, erhält diese Email lediglich den Status Softfail udn wird nicht direkt gesperrt.

Verstehe ich grad nicht. Wenn du von einem gültigen SMTP Server die Domäne fälschst, warum solltest du dann Softfail bekommen? Oder steh ich grad auf dem Schlauch?

 

Bye

Norbert

Hi,

 

vielleicht genügt der Exchange integrierte SPAM Filter einfach nicht deinen Anforderungen ;)

 

Gruß

Jan

Der genügt eigentlich niemandem, der das Ding mal konfigurieren mußte und dann gefragt wird, warum Mail xy nicht ankommt. ;)

 

Bye

Norbert

[PowerShellAdmin 169]

Erstmal danke für die Rückmeldung.

Dass die Spam-Filterung vom Exchange nicht ausreicht - Ja. Ich hatte aber doch ein wenig die Hoffnung die beiden angesprochenen Punkte via Exchange zu lösen.

In 2003 gab es ja noch eine explizite RDNS Prüfung - die Absenderzuverlässigkeit in Ex2010 ist ja ein Zusammenschluss diverser Faktoren mit einem unklaren Scoring (letzteres zumindest mir).

 

Wir setzen zusätzlich noch ein ESMX 6 mit umfassenden Regeln ein, was ansich ganz gut funktioniert aber auch nicht alles abdeckt.

Gerade ein Abgleich mit SPF Records und dem RDNS gehören für mich eigentlich dazu...

 

 

SPF Records sollten berücksichtigt werden, aber das kann man eben nicht beeinflussen. Der Eigentümer der Domäne wünscht sich wahrscheinlich, dass es berücksichtigt wird. Da aber viele schon den SPF Record mit ~ bauen, gehe ich davon aus, dass sie selten wissen, was sie tun. ;)
Ich persönlich bin pro SPF, aber gibt viele die das für "umständlich" oder nicht implementierbar für ihre Domain halten, weil sie Umleitungen usw. nutzen müssen/wollen.

Ich meinte damit ja auch, dass wenn es ein SPF Record gibt, soll dieser auch berücksichtigt werden und bei Abweichung die Email zurückweisen. Ohne SPF Record soll die Nachricht aber nicht direkt blockiert werden, hier reicht ja eine Erhöhung des SCL Scores.

 

Verstehe ich grad nicht. Wenn du von einem gültigen SMTP Server die Domäne fälschst, warum solltest du dann Softfail bekommen? Oder steh ich grad auf dem Schlauch?

Ich habe eine Email (außerhalb der Organisation)  unter einen fremden Absender verschickt  (xxx@paypal.de) an eine internen Empfänger verschickt z.B. - Die Email wurde vom Exchange angenommen, der Sender-ID Filter hat ledlgich einen Softfail als Headerfield hinterlegt.

Das geht garnicht :(

 

VG PSAdmin

bearbeitet 14. April 2016 von PowerShellAdmin

[NorbertFe 2.035]

"Das geht gar nicht", wenn man als PowershellAdmin die Parameter nicht setzt. ;)

 

zeig doch mal ein get-SenderIDconfig

 

Ich geb dir nen Tipp:

Der Parameter SpoofedDomainAction gibt die Aktion an, die der Sender ID-Agent für die Nachricht ausführt, wenn die Absenderdomäne Anhaltspunkte für Spoofing aufweist. Der SpoofedDomainAction-Parameter akzeptiert die folgenden Werte: StampStatus, Reject oder Delete. Der Standardwert lautet StampStatus.

bearbeitet 14. April 2016 von NorbertFe

[PowerShellAdmin 169]

Hey - Wenn es hier noch Konfigurationsmöglichkeiten gibt nehme ich diese gerne an :)

Falls es um das Rejecting geht - hatte ich natürlich auch aktiviert.

 

Meine damit auch mehr - Der Zustand geht garnicht.

 

edit: Liste der aktiven Transportagents - Sender Id Agent läuft

Identity                                           Enabled         Priority       
--------                                           -------         --------       
ESET-Filteragent                                   True            1              
ESET-Filteragent für Virenschutz                   True            2              
Connection Filtering Agent                         True            3              
Sender Id Agent                                    True            4              
Sender Filter Agent                                True            5              
Recipient Filter Agent                             True            6              
Transport Rule Agent                               True            7              
Text Messaging Routing Agent                       True            8              
Text Messaging Delivery Agent                      True            9              

RunspaceId            : bb550fff-946d-4778-89e5-c0486c669fc5
SpoofedDomainAction   : StampStatus
TempErrorAction       : StampStatus
BypassedRecipients    : {}
BypassedSenderDomains : {}
Name                  : SenderIdConfig
Enabled               : True
ExternalMailEnabled   : True
InternalMailEnabled   : False
AdminDisplayName      : 
ExchangeVersion       : 0.1 (8.0.535.0)
DistinguishedName     : CN=SenderIdConfig,CN=Message Hygiene,CN=Transport Settings,CN=domain,CN=Microsoft Exchange,CN=
                        Services,CN=Configuration,DC=xxx,DC=domain,DC=tld
Identity              : SenderIdConfig
Guid                  : 8bd6c1b7-13c1-4d4a-b8e6-575f7937b2de
ObjectCategory        : domain.tld/Configuration/Schema/ms-Exch-Message-Hygiene-Sender-ID-Config
ObjectClass           : {top, msExchAgent, msExchMessageHygieneSenderIDConfig}
WhenChanged           : 14.04.2016 09:22:57
WhenCreated           : 05.01.2010 15:33:57
WhenChangedUTC        : 14.04.2016 07:22:57
WhenCreatedUTC        : 05.01.2010 14:33:57
OrganizationId        : 
OriginatingServer     : psrv24.xxx.domain.tld
IsValid               : True

bearbeitet 14. April 2016 von PowerShellAdmin

[NorbertFe 2.035]

Naja aber da steht StampStatus. Und solange der da steht, macht er auch genau das.

[PowerShellAdmin 169]

Falls es um das Rejecting geht - hatte ich natürlich auch aktiviert.

 

 

AchJa hatte ich doch geschrieben ;-) - war aktiv und ist es gerade auch testweise wieder.

 

Die Zuordnung Soft Fail ansich scheint ja auch als zu Ordnung zu stimmen - Allerdings scheint die Reaktion wieder ein anderes Thema.

Ich habe die Befürchtung, dass ich die Anforderung mit den Onboardmitteln nicht sinnvoll abbilden kann.

Lese mir jetzt noch mal die weiteren Artikel durch:

https://technet.microsoft.com/de-de/library/aa997136%28v=exchg.150%29.aspx

 

 

Quelle:

https://technet.microsoft.com/de-de/library/aa996295%28v=exchg.150%29.aspx

 

Soft fail   Die IP-Adresse für die PRA ist möglicherweise im Nicht-Berechtigungssatz enthalten.

bearbeitet 14. April 2016 von PowerShellAdmin

[NorbertFe 2.035]

Kann ich dir schlecht sagen, da ich nicht weiß, was du da testest und wie der SPF Record lautet.

[PowerShellAdmin 169]

Danke Norbert...Am Ende ist ein ~All und nicht -ALL. Daher stimmt die Soft-Fail Zuordnung.

Also ich hatte als Sender Domäne Paypal.de getestet - hätte wohl zweimal hinschauen sollen - Brillenträger

 

Ich gehe jetzt davon aus, das Sender ID erst ab Fail rejected.

 

Teste jetzt nochmal mit einer anderen Domäne - die wird das sicher bestätigen.

 

Ich sehe jetzt nur die Option Softfails via Transportregel zu rejecten... dient aber nicht so der Übersicht. Soft-Fails möchte ich jedenfalls nicht zugestellt bekommen.

Selbst in dem Exchange Kompendium (wirklich eine sehr hilfreiche Dokumentation/Referenz) sind die Sender ID und Absender Validierung ungenügend dokumentiert, im Technet wird es sicherlich noch irgendwo versteckt sein oder ich habe es übersehen.

 

edit- so einfach ist es:

Sender ID funktioniert ansich wunderbar.

In Aktion tritt diese aber erst ab "Fail" inkraft- Ich denke es ist sinnvoll auch Softfails zu unterbinden oder wie seht ihr das ?

 

Die zusätzliche RDNS Prüfung ist aber ein anderes paar Schuhe, das Score-Lvl der Absenderzuverlässigkeit wäre da ein Ansatz.

Da hier div. Faktoren zusammenlaufen, aber ebenfalls sehr unschön...

VG PSAdmin

bearbeitet 14. April 2016 von PowerShellAdmin

[NorbertFe 2.035]

Alternativ nimm dir einen Spamfilter der das alles kann, bedienbar ist und lesbare Logfiles erzeugt. http://vamsoft.com

 

HTH

Norbert

[PowerShellAdmin 169]

Schaue ich mir mal an, sobald die Website wieder verfügbar ist.

Auch im parallel Betrieb konfliktfrei ?

Den Virenscan und Anhangsprüfung würde ich in jedemfall auch mit ESMX 6 aktiv belassen wollen.

Spamschutz würde je nach Administrierbarkeit dann beim ESMX ausgeschaltet werden.

bearbeitet 14. April 2016 von PowerShellAdmin

[NorbertFe 2.035]

Die ist verfügbar ?Parallel zu was?

[PowerShellAdmin 169]

Die ist verfügbar Parallel zu was?

Eset Mail Security 6 haben wir im Einsatz.

Ansich funktioniert es auch recht gut, hier laufen diverse Regeln - auch für Whitelisting und setzen dabei Headerfields.

ORF würde ich dann also gerne mit der Prio nach Eset laufen lassen - Hier sollte eine Auswertung der zuvorgesetzen Headerfields möglich sein.

Die eigentliche Spam-Engine in Eset kann ich einfach ausschalten, aber die Regeln sollten abgearbeitet werden.

 

Ja geht wieder - komsich.

Lizenzmodell klingt mehr als fair - diverse Anbieter lizenzieren auf Postfächer ... Ist bei uns jedenfalls sehr ungünstig

Quelle:http://vamsoft.com/pricing

 

In this licensing model, you will need as many licenses as the number of users you have. However, you can deploy ORF any number of servers that belong to your organization, because it does not affect the licensing.

A user is defined as an actual person who has access to a mailbox filtered by ORF. For example, if your company has 500 employees, but only 25 have company email access, you will need 25 licenses only.

bearbeitet 14. April 2016 von PowerShellAdmin

[NorbertFe 2.035]

Also ich würde eset aus dem Traffic soweit wie möglich raushalten. Aber das wirst du dann auch feststellen, dass es kaum wirkliche Features gibt, die dir fehlen. ORF hat auch einen testmodus dann wird nur geloggt.