An alle, die mit E-Mail zu tun haben und die es amtlich richtig™ machen wollen: Das @bsi hat die Technische Richtlinie BSI TR-03182 „Email Authentication“ https://bsi.bund.de/dok/tr-03182-en veröffentlicht, welche beschreibt wie #spf, #dkim und #dmarc eingesetzt werden müssen, damit sie konform mit der TR sind und einen Audit für eine BSI-Zertifizierung bestehen können.

Weshalb ich das schreibe? Ihr lest den troet des stolzen Autors, der 1,5 Jahre mit dem BSI an der TR getüftelt hat.

BSI TR-03182 Email Authentication

Federal Office for Information Security
@patrickbenkoetter @bsi Interessant, vielen Dank für den Input. Bisher hab ich DMARC immer als nett gedacht aber wenig nutzvoll wahrgenommen. Bin ich da irgendwo falsch abgebogen?
@lairsdragon @bsi #DMARC schützt effektiv vor Identitätsmissbrauch wenn es richtig (siehe TR) gemacht wird und deshalb ist es sinnvoll, es einzusetzen. DMARC ist aber nicht die Wunderwaffe gegen Identity Abuse, so wie es viele Anbieter von DMARC-Lösungen gerne darstellen und es zwingt diejenigen, welche E-Mail-Plattformen bereitstellen und jene, welche E-Mail nutzen, E-Mail anders zu nutzen. Besonders das beliebte Forwarding funktioniert mit DMARC und SPF nicht mehr.

Und das hat für viel Ärger gesorgt. Die Kritiker sagen DMARC wäre nicht durchdacht und verursache mehr neue Probleme als es alte lösen würde. Die Befürworter führen an es dämmt effektiv abuse ein und berufen sich auf „Wer heilt, hat recht.“

Mein persönlicher Standpunkt ist: DMARC hilft vor allem denen, welche es sich ausgedacht haben und das sind die Betreiber der Großplattformen. Die Betreiber kleiner Plattformen bis hin zu den Individualisten, welche ihren eigenen Mailserver betreiben, …

… stören sich an der Komplexität und Kompliziertheit der drei Standards.

Am Ende geht es darum SenderInnen mit Sicherheit identifizieren zu können, damit wir deren Botschaften vertrauensvoll zur Grundlage unseres Handelns machen können.

#DMARC bietet das nur teilweise, indem es die Senderdomain, aber nicht den / die SenderIn identifizieren hilft. Das kann nur eine signierte E-Mail und deshalb hat der eco Verband die KG E-Mail, welche ich mit zwei anderen leite, den Auftrag erhalten,

sich dieses Jahr mit der signierten E-Mail und wie wir deren Gebrauch fördern können, zu beschäftigen.

@patrickbenkoetter @lairsdragon @bsi I saw this thread because I follow the #DMARC hashtag. Message forwarding works fine as long as the original message is #DKIM signed and the forwarding service does not tamper with the email. #SPF never works with a forwarded message.

You are right that there are many other ways to impersonate an identity, like display name spoofing, but it does prevent from address spoofing. Good security awareness programs train users to look at the from address when checking for impersonation. There are also free DMARC solutions, like the open source software I wrote.

I wrote a detailed blog post about DMARC here: Demystifying DMARC: A guide to preventing email spoofing

parsedmarc documentation - Open source DMARC report analyzer and visualizer — parsedmarc 9.0.5 documentation

@seanthegeek @lairsdragon @bsi I agree forwarding may work if #DKIM is being used. That’s why we made #DKIM mandatory in the technical guideline because we wanted something that works and lets #DMARC help where it can help.

Personally I’d like to drop the requirement for #SPF because it severely impairs email transport, but the time isn’t ready yet. Too many companies making money with it forming a too large lobby voting against SPF dismissal.

@patrickbenkoetter @seanthegeek @lairsdragon @bsi I see a big problem: a) popular MUAs hide the From: address and only show the name (and users wouldn't be able to validate the address anyways), so b) orgs have started to add "EXTERNAL" warnings to inbound mails, thereby breaking DKIM signatures (which are worthless anyways because of a)). Spam and Phishing also have valid DKIM signatures, because they use throwaway domains or hijacked legitimate mail accounts. Much ado about nothing...
@patrickbenkoetter @seanthegeek @lairsdragon @bsi Just look at SpamAssassin or rspamd's default scores: very little positive impact of valid DKIM signatures, but negative impact of invalid signatures, which are mostly due to configuration errors or forwards/mailing lists of legitimate users.
@cm @seanthegeek @lairsdragon @bsi Well that’s mostly because the operational model is wrong - at least that’s what comes to my mind first. Validated identity can only be the precondition to build reputation upon. This said it makes sense to give only slightly positive scores when a DKIM signature validates. What OSS email filter lack is a real useful reputation backend. That’s where commercial products come in.
@patrickbenkoetter @seanthegeek @lairsdragon @bsi Given the high number of bad mail I get from completely legitimate outlets (either stolen accounts or the likes of gmail and O365), I don't see how that could work. What would be needed is matching between the content of the message and the sender, and flagging if that is off. That *might* work for banks etc, but for general business emails?
@cm @seanthegeek @lairsdragon @bsi what would we gain if we were able to match sender and content? What kind of relation would you like to create and validate?
@patrickbenkoetter @seanthegeek @lairsdragon @bsi Phishing. People click on links in the body that say "$BANK", and completely ignore that the sender has nothing to do with $BANK. DKIM/SPF/DMARC as discussed here validate the sender...
@cm @seanthegeek @lairsdragon @bsi sorry for nit picking on this but I think it’s very important to be precise on this: #spf and #dkim only serve to authenticate the senderdomain, but not the sender. While DKIM could do that in theory nobody does that in practice. If you want to authenticate the sender your best call is to sign the message itself. And most OSS people won’t like this, but the best call here is S/MIME. All MUAs support it.

@patrickbenkoetter @seanthegeek @lairsdragon @bsi You're of course correct with your nitpicking, but for the purpose of the phishing discussion we're talking about the domain anyways.

(And don't get me started on PGP and/or S/MIME. Both horses were dead back in 2000 when I worked on support for them in Sympa...)

@cm @seanthegeek @lairsdragon @bsi the problem with pgp is most people’s lack of interest in building a web of trust. They want something to use out of the box. Whereas one may use S/MIME out of the box, cert acquisition and management really suck. Think cross device usage and last but not least the challenge you meet when you don’t want to store your private key on e.g. your smartphone (read: in the cloud).
@cm @seanthegeek @lairsdragon @bsi I agree with „users wouldn’t be able to validate the address anyway“ and I believe it should be a machine’s job to do that. Chat apps have proven how machines can solve this problem without continuous user interaction. Email users should be able to focus on the content of their communication and not on operational duties machines can take care of.
@patrickbenkoetter @seanthegeek @lairsdragon @bsi But how? Like, out of my spam folder, "From: NameOfAustrianBank <*@something.co.uk>" and the content is a phish. Users fall for this (or it wouldn't exist), how could we go about this? Even if legitimate mails from that bank had some kind of visual distinction, what prevents the user from just reading the text and clicking the link, never noticing that visual is not present here?
@cm @seanthegeek @lairsdragon @bsi well strict DMARC alignment, BIMI and S/MIME and / or PGP signatures come to my mind, when we look for technology that validates envelope sender and From: header.

@patrickbenkoetter @bsi Vielen Dank!

Bei dem Titel denke ich an "modern auth" mit 2fa für IMAP und SMTP. Die Client-Seite ist hier aber anscheinend out-of-scope.

@hexmasteen @bsi so ist es. Ich merke mir das damit, dass die E-Mail authentifiziert wird und nicht der Client. Bin ebenso wie du wiederholt über die Formulierung gestolpert.
@patrickbenkoetter @bsi Na dann werden wir das ja wohl mal lesen.;-)