Thread Info
  • State Suggested Answer
  • Locked Locked
  • Replies 12 replies
  • Answers 1 answer
  • Subscribers 30 subscribers
  • Views 18280 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

SPF sinvoll oder nicht? Whitelist nur für Benutzer

Thomas_Braun

Hallo,

wird die SPF Filterung standardmäßig eingesetzt? Wir haben das mal gemacht und stellten fest, das sehr viele per SPF abgelehnt werden.
Wenn es immer noch eine gängige und sinnvolle Methode ist würden wir diese gerne Einsetzen.

In diesem Zusammenhang:

Gelten die Whitelist Einträge, die der Benutzer im Benutzerportal tätigen kann dann für die gesamte Organisation oder muss ich das unter den Globalen Einstellungen von der Filterung ausnehmen?

 

Herzlichen Dank



This thread was automatically locked due to age.
Parents
  • 0

    Unlike the others, I am negative on SPF.

    1. SPF compares the remote server to the authentication information passed by the remote server, and the authentication information is only trustworthy if the sending server is trustworthy.   Consequently, it will not meet your expectations.

    2. Specifically, SPF does not look at the "From" information seen by the user, because the test is performed before that information is even delivered.   Consequently, spammers can avoid SPF by either (a) not providing an SPF record for the arbitrary domain in their authentication information, or (b) by providing a valid SPF record.  (Creating an SPF record provides no new information to the people who want to stop them.)   There is nothing that requires the internal authentication information used for SPF to have any relationship to the FROM information seen by the user, and as best I have been able to tell, the EXIM mail system inside UTM is UNABLE to check the user-visible FROM information at all.  My general impression is that the incremental benefit from valid SPF blocks will be minimal, because the real spam will be blocked on other criteria, but it will come at the expense of unwanted blocks.

    3. In the specific case of UTM, the only SPF option is to block, and when a message is blocked it is not retained, so you have no information to evaluate whether the block was appropriate or not, because you have no way to see the headers on which the decision is made. I don't know how you will tell a false positive from a correct block, or how to know which business partners need to be contacted because they are generating false positives.  UTM's message log review is completely inadequate on many levels.

    4. Too many companies have a do-nothing SPF entry ending in "maybe" -- either "?all" (neutral) or "~all" (softfail).  An include list that ends in maybe can also render the SPF entry meaningless, even if the parent list ends in "-all" (hardfail).   UTM documentation doesn't even explain whether it blocks both softfail and hardfail, or hardfail only, so you don't even know what you are signing up for.

    5. Too many companies have third-parties sending mail on their behalf without the knowledge of the internal mail organization, so the SPF record is wrong.   Salesforce.com is the most common relationship that creates a problem, because Salesforce.com routinely sends email under the identity of their clients.

    I tried to use SPF at least twice, all before UTM.   Disappointed every time, and rolled it back fairly quickly because of false positives. 

  • 0 in reply to DouglasFoster
    1. The SPF test is done on the domain in MAIL FROM, so it's practically "free" to use.

    2. There are few blocks due to SPF, under 0.5% of blocked/rejected emails, but 90% of all blocked emails are rejected prior to the SPF test.  I agree that it's most likely that they would be caught by the spam filter.  That requires receiving the complete email, calculating a signature and checking that with the known signatures in the cloud - not "free" at all.

    3. False-positives and true-positives are recorded in the SMTP log along with the sending IP, so no additional information is needed.  One can quickly determine which rejections might be false-positives.  In addition to the above technique with the 'SMTP Log' tab, here's a command-line approach to getting the list of the senders that were blocked during the first nine days of March:

               zgrep 'SPF check failed' /var/log/smtp/2018/03/smtp-2018-03-0[1-9].log.gz|grep -oP 'from=".*?"'|sort -n|uniq -c|sort -n

      That should let you quickly see which senders were possibly blocked because of an incorrect SPF record.  Looking at that for MediaSoft, I know that the chase.com rejection was certainly valid and that the planetsmb.com and customermail.usaa.com ones are suspicious.  Someone with better Linux-fu than I probably could make a sendmail cronjob to get the appropriate info to the admin every day.

    4. Agreed, Doug.  Smaller companies can get away with ? or ~ until they start getting bounces for emails sent by cyber criminals.  Activating SPF hard-fail for your company means you have solid-enough IT infrastructure to be certain that your SPF record remains valid.  For the smaller organizations, a week or two is probably long enough to maintain your hard fail.

    5. Salesforce.com is a challenge - even they have a ?all record.  Any company that uses a bulk mailer or similar should include a monitoring address when they pass a list to their supplier.

    Cheers - Bob

  • 0 in reply to BAlfson

    Okay, da scheiden sich die Geister.

    Ich denke aber, man sollte jede Funktion für den MIssbrauch von email Adressen ausnützen. Die Zeiten sind vorbei, wo belanglos emails verschickt werden konnten und auf Sicherheit (wegen Kosten) kaum geachtet worden ist.

    Erschreckenderweise stelle ich fest, dass es sehr viele Unternehmen gibt, wo kein SPF Eintrag gesetzt ist, obwohl es ja nun wirklich nicht allzuschwierig ist.

    In diesem Zusammenhang:

    Sofern ich es mitbekommen habe, bekommt der Absneder ja die emails zurück. Was da drin steht, versteht ja kein normaler User. Kann man die zurück schicken Email um einen Text ergänzen z.B. Usergerecht, weshalb die Email zurück gekommen ist mit dem Verweis dass es im eigenen Interesse ist, seine IT zu informieren und einen SPF eintrag setzen zu lassen?

    Bin leider kein Linux spezialist, ich nehme an, dass kann man irgendwo auf der UTM in eine Datei eintragen? Für Hilfe wäre ich dankbar.

     

    (Sorry, my English-speaking brain isn't creating thoughts at the moment)

     

    Allright, It looks like 50% are agree with me, 50% not. 
    Anyway, I decide to use SPF for the whole company at any cost. In my opinion, every authenticated Technologie should be used.
    Times are over, where emails where send without checking it deeply.

    As I see, since one week, it seems that many Admins don´t establish the DNS Entry for SPF. I think thats easy to establish but not in use in most of the cases.

    Now, I recieved phone calls where people saying: "Could not send you emails". As I understood, they getting the email back as undelivery.

    I think, the text inside this system mail is overtax for common users, so there ist my question:

    Is it possible to edit the undelivery email utm send back? I would like to add a sentence, explaining the reason why the mail was refused in a simple way.

    Unfortunately, I am not a Linux Professional but I think there must be a way to edit what utm sends back.
    Did something know a simple way to do so?

    Thanks for you help

  • 0 in reply to Thomas_Braun

    Bekommt der Versender eigentlich von der UTM eine Fehlermeldung zurück, dass die Email nicht zugestellt wurde aufgrund von SPF oder wird die einfach geschluckt?

     

    Danke

  • 0 in reply to Thomas_Braun

    Die Email wird nicht angenommen, daher wird der Absender (-Server) wahrscheinlich eine Fehlermeldung generieren. Der Absenderserver wird die Email also gar nicht los.

     

    Beste Grüße

    Alex

  • 0 in reply to Alexander Busch

    Ah okay. D.h. der Absender bekommt schon mit, dass die email nicht zugestellt wurde. Sehr gut. DAnke!

  • 0 in reply to Thomas_Braun

    Hallo und sorry, dass ich den Threat nochmal öffnen muss.

    Ich habe ein Problem mit dem SPF check. SPF prüft ja nach ob ein Versender vom richtigen Server verschickt indem es DNS ausliest.
    Das Problem stellt sich jetzt folgendermaßen da:

    Wir haben zwei MX Records im DNS. Der erste ist unser eigener (Prio 10) und der andere Domainfactory (Prio 100).
    Ein Versender @domain.com schickt eine email, diese kommt auch an. Später verschickt derselbe Versender erneut eine email und sie wird von der UTM als SPF verworfen.

    Aus dem Log erkenne ich das Problem:
    Erste Mail kam von der IP dessen Prüfung ergibt, dass er die emails versenden darf.
    Die zweite email kommt von unserem Provider.

    Das würde Sinn ergeben, wenn unsere Leitung ausgefallen wäre, dem ist aber nicht so. Es lässt sich auch kein Muster erkennen.

    Unter emailprotection\Relaying habe ich die IP Adresse der Upstreamhosts (also DF) unter "Upstream-Hosts" eingetragen, dennoch werden sie abgelehnt.

    Die enstprechende mails kamen über
    80.67.18.5
    80.67.18.1
    80.67.18.10 an

    Eingetragen hab ich als Upstream das Netzwerk 80.67.0.0/24
    Ist das falsch bzw. hat das überhaupt damit zu tun?

     Was ich aber generell nicht verstehe: Wieso schreibt er mir überhaupt die DF Adresse, wenn der "Ursprüngsserver" doch der richtige war?

    danke!

  • 0 in reply to Thomas_Braun

    You need to add the provider's IP-addresses in your DNS SPF-record. Ask you provider what you should include in your SPF-record, he might have a domainname you can include so you don't have to add/maintain individual IP-addresses.

    Fabian Drska said:

    Hallo und sorry, dass ich den Threat nochmal öffnen muss.

    Ich habe ein Problem mit dem SPF check. SPF prüft ja nach ob ein Versender vom richtigen Server verschickt indem es DNS ausliest.
    Das Problem stellt sich jetzt folgendermaßen da:

    Wir haben zwei MX Records im DNS. Der erste ist unser eigener (Prio 10) und der andere Domainfactory (Prio 100).
    Ein Versender @domain.com schickt eine email, diese kommt auch an. Später verschickt derselbe Versender erneut eine email und sie wird von der UTM als SPF verworfen.

    Aus dem Log erkenne ich das Problem:
    Erste Mail kam von der IP dessen Prüfung ergibt, dass er die emails versenden darf.
    Die zweite email kommt von unserem Provider.

    Das würde Sinn ergeben, wenn unsere Leitung ausgefallen wäre, dem ist aber nicht so. Es lässt sich auch kein Muster erkennen.

    Unter emailprotection\Relaying habe ich die IP Adresse der Upstreamhosts (also DF) unter "Upstream-Hosts" eingetragen, dennoch werden sie abgelehnt.

    Die enstprechende mails kamen über
    80.67.18.5
    80.67.18.1
    80.67.18.10 an

    Eingetragen hab ich als Upstream das Netzwerk 80.67.0.0/24
    Ist das falsch bzw. hat das überhaupt damit zu tun?

     Was ich aber generell nicht verstehe: Wieso schreibt er mir überhaupt die DF Adresse, wenn der "Ursprüngsserver" doch der richtige war?

    danke!

     

  • 0 in reply to Thomas_Braun

    Hallo Fabian,

    Anstatt 80.67.0.0/24, versuche mal 80.67.18.0/24 - geht's besser damit ?

    MfG - Bob

Reply Children
No Data