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.

@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).