I have everyone, I'm going to tell you about my two DMARC Rooney, which analyzes DMARC reports.
I love if you might know about DMARC. Some probably more than me, but just to make sure that we're on the same page.
I would like to say that DMARC is a standard that allows you to monitor the deliverability of your email.
By adding one or two lines in the DNS zone file, you should start getting XML reports from each domain you or someone's moving you as contact with.
At least the mother ones that adhere to the standard.
There are two types of DMARC reports. You can ask for forensic reports. They give you information about the emails that didn't get delivered.
And there are aggregated reports, and they are what I'll be talking about today.
These aggregated reports contain information about the amount of email sent, divided by each IP address.
But they also say how many of them passed the DMARC, the total reporting period, and if they got delivered or not.
They all start by adding a DMARC policy to your DNS.
These policies instruct people about what you want to happen with your mail when it hits their server.
DMARC is just about reporting. The heavy lifting is done by two other standards, namely SPF and DKM.
SPF allows you to whitelist IP addresses.
If any emails are sent from these IP addresses, the receiver may assume that it is use sending them an email.
Obviously this regarding broken implementations that were available to SMTP smuggling.
DKM is a much more recent standard that follows another form of logic.
The receiver can check if the email they received really came from you because it carries cryptographic signature.
These two are complementary, SPF restricts when aware in the network emails can come from, and DKM provides a proof of origin on the envelope.
They break in a different way, and so you want to have both act as each others fall back.
If your email does not carry your signature and it doesn't come from one of your own email server address, you probably don't want anybody thinking you actually sent it.
That is why you need to add a DMARC policy.
The first policy is none, in other words, do nothing.
This is the dry run, you turn on just because you start getting serious.
You start getting all the reports to monitor your email traffic until you are 100% certain that everything is configured right.
All emails should be accepted, whether they are positive and SPF or not.
None means that you are still really found the world of spoofing and run the risk of large spam, and malware being sent from your domain name.
The next policy, guaranteeing, instructs recipients to guarantee the email.
What guaranteeing actually means is not well defined, it can be a custom implementation at a two-folder names spam or something else.
To reject policies, says that any receiver should just outright reject any emails not passing the email or SPF.
This is where you ideally want to be.
To make sure that you can switch to these policies, to a guaranteeing or reject policy, you want to make sure that the emails you sent yourself pass both the email and SPF.
For this, you want to analyze the reports sent to you by your context, but nobody wants to read all raw XML files themselves.
This is where my project fits in.
Before I started working on day macaroni, I couldn't find any false tooling to analyze and visualize this data well.
There was one really basic tool, but it just didn't written in Python, but it just didn't have the features needed.
And there are some proprietary tools, but that would mean that you would need to send access to your data about all the people you sent emails to.
How often do you do, and who might be trying to impersonate you.
So that's why it is needed for the ecosystem.
People running their own mail infrastructure should be able to locally run the tool, giving them insight into the deliverability of their own emails.
But I would also like to tell you why I started working on this because I noted it doesn't sound like a sexy subject that the students would randomly get into.
Our family is pretty technology technology, technology savvy, and we use our own vanity domain name to keep our email independent from ISPs.
You don't want people to not be able to contact you when you want to switch internet service providers, and using Gmail or Outlook is not something that is an option for us.
Our DNS, also has a nice feature where emails forwarded in its traditional manner.
That setup has been in place since before my birth and predates SPF.
Almost two years ago, I applied for the Bachelor of Computer Science and Engineering in ANT over.
In the Netherlands, this is a numbers fixed study, meaning that there are only a limited amount of spots that you need to take in entry exam.
But to my initial application, I didn't hear anything back from them for a few weeks.
I knew they needed some information for me, but I had already provided that the year before.
I did get regular messages from the university about all kinds of other matters, so I had no reason to doubt my setup.
As you know, only a five minutes left, and so some about the tool.
So it turned out they sent me emails, they got in my currency folder.
I didn't reply, and I got rejected, so I wanted to show them.
I didn't get allowed to make the exam.
So I thought if I would make a tool that shows them that they're email, they're sending.
There's not a peeking on it and didn't arrive at my place.
They might still want me in the program, but they didn't in the end.
I'm studying Electropet Engineering now.
Luckily, yeah, I got a grant from as the end funds to work for furthering this.
So I got to work.
I started with the server side.
It written in the Haskell, which is a functional language and type save.
And it looks a lot like Matt, so it seems perfect to easily manipulate large sets of data.
And it is the first language that I learned so it was easy for me.
The server currently is a command line tool with a dog config file.
There are different types of input you can give it to, although I would like to add also.
I'm at the top three support.
You will end it your raw XML reports or mail files and then it validates the supplied XML with the
Relex and G schema as some big players like Google didn't perfectly comply with the standard.
So I also wrote a more relaxed schema.
Then I aggregate all the data on different levels.
There's an overview level.
There's info per domain and info per report.
I'm at the given IP address to ASN numbers, which basically are their service providers.
And the application, so you can also get information about the place people are moving from.
The tool internally starts the data as XML, but like I said, it can also output in different formats.
Currently, it does XML JSON and CSV, but it's fairly easy to extend that.
Then I wrote a client in L, which is another type save functional programming language inspired by Haskell,
but focused on designing user interfaces.
What's nice is that you write clean functional code and it compiles down to the JavaScript ready for the browser.
It's a weapon that allows you to drill down the data via tables, graphs, and pie charts.
The functionality is currently still focused on analysis of the deliverability.
I definitely don't think that one tool will cater for all needs and use cases.
Certainly there are people with much more experience writing slick front and stemmy.
That's why I split the server part and the client part.
It would be really nice to see other people creating their own clients.
And of course, doing it in a language of choice.
If anything is needed for that on the server part, a different output format, please let me know.
And of course, veggies are welcome.
Then there is more stuff I would like to see happening.
Next to me learning how to make a better UI and smarter ways to visualize the data.
I also want to make a separate panel focus on spoofing because it should be possible to map our hosters to abuse addresses
that the people can easily contact relevant parties if they need to act on some attack.
I also think it could be insightful to see which domain certain attackers interested in.
Are these random other people or important clients, players or personal friends?
Another roadmap item is to incorporate forensic reports in my analysis because they can provide useful find-grained information
about emails that didn't get delivered.
And I want to write more extensive documentation, of course, and make a desktop mobile at so people can access the relevant information more easily.
Lastly, being able to send notification when something is going wrong, for example, emails not arrived,
which should be or an attack taking place, I think would be useful.
And there could be more logic on this side as well.
I currently analyze things, but automatically flagging trusted sources when your SPF record change or suggesting things like white listing certain IP address
when it consistently passes decam, but it's included in the SPF record might be useful.
Yeah, thank you all very much for listening.
This is all I have to say about you, Mark Rowley for today.
Please check it out at get.isroot.org-alloners.
Once you've returned home safely, you're also my contact details.
If you want to reach me, I hope the name D.Mart Rowley is annoying enough to be memorable.
And it's false software.
So if you think someone you know could benefit to refer them to me.
Once more, thank you as the end funds for the grant.
The people at the end loves for their valuable advice.
The people at Plotterman Internet stand there, I know which I see a 4-4 already giving some more support and talk to me.
And Google the omet Procalix for providing me with VMs for testing the infrastructure.
And the authors of D.Mart with their standard almost earning 10 years old next month.
So thank you very much.
Thank you very much.
So the question is, if the question is what an acceptable failure rate would be if it's 1% or 5% or something else.
I think I should have decided it depends on who is who uses the tool.
Like for me personally, if 1% is derived, I wouldn't bother.
If 3% is derived, I also might find it okay.
But if I need to send out really important emails, I would want to make sure they arrive.
So that's why the analysis per domain is useful.
So you can actually flag clients or context that are important to you and make sure that all the emails to them arrive.
Yes?
Well, that's a question.
Okay.
Well, yeah, that is.
I have a question.
Like, he won't use the only report when he was about lying on duty, but that is serve or where
you're sending you to.
But if for some reason, but he won't get lost in transit or you're dispelting the main or whatever.
Is there anything that you would like to see happen?
I would like to see if I would like to see if I would like to make an email for whatever reason doesn't
be released and then serve.
So the question is that if the email doesn't arrive at the other person's end, if there would be a possible solution to defend that.
Or to gain insight.
I think working together with an email server, like Staubert or Mox maybe, could be useful to see the outgoing email on the report you get back.
So you can actually see if they also reported on the emails you sent, especially for important clients this would be.
I think we have a direct report.
I don't know what you have to say.
I thought about that.
Okay, do I verify the email reports coming in?
I don't fully yet.
There are some small mechanisms I check.
If the sender matches the sender in reports and if the, like seeing if the report is valid at least, make sure you don't get any information breaking your system.
But I would like to add more verification at the front end.
So just, yeah, I'd like to know if this is simply related to an unsolicited perception of the mark reports, which are an external document.
Yeah, I'm sorry.
Yeah, that, it is needed, but it's currently not any tool yet.
But I will look into it after first.
Thank you.
We are in tracing email that doesn't arrive.
This was the topic at the idea about 20 years ago.
We started in RFC 388, which then, very much didn't get implemented.
It's a very nice standard, not all that it goes to the internet, but people who cared about it didn't care enough to actually go to the internet.
She happens.
Okay.
So maybe just for the microphone.
Yeah.
What was the option?
388.
It's an RFC.
I don't think it's green, but 388.
Thank you.
All right.
Thank you.
Thank you very much.
Thank you.