<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, 29 Sept 2023 at 10:13, Carles Pina i Estany via Wolves <<a href="mailto:wolves@mailman.lug.org.uk">wolves@mailman.lug.org.uk</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
<br>
> If anyone wants a short talk about DNS based Mail 'security' (SPF, DKIM,<br>
> DMARC, DANE), I probably need to get one made for work shortly anyway :D,<br>
> so I'm happy to 'do one' :)<br>
<br>
I don't see how it can be "short" and then "DNS based Mail 'security'<br>
(SPF, DKIM, DMARC, DANE)". To me this is impossible :-D<br>
<br>
I am interested, I would try to attend. If it's online I would hope that<br>
it's easy to attend (if you welcome someone from the SLUG group :-D) ,<br>
if it's physical depends on the day and place (perhaps Telford is a good<br>
place, at least for me, from Market Drayton). No idea of concrete places<br>
though!<br></blockquote><div><br></div><div>It would be online rather than physical, unless there was a demand for the LUG to start doing talks again? </div><div>But as this is partly a personal development thing for me, as I hate speaking in front of people, I'd find online a lot easier.</div><div>NB, Knowledge transfer is also important to me.</div><div><br></div><div><br></div><div>The subject area is not actually that bad:</div><div>(drastic over-simplifications ahead):</div><div><br></div><div>It's an important distinction that all these DNS records are informational, and no receiving server/provider actually has to adhere to what you state in these records.</div><div><br></div><div>SPF: A list of servers that send mail on behalf of a domain (and what should be done to emails that are from said domain, which not originating from a listed hosts/networks).</div><div>DKIM: digitally signing body and/or headers of an email with a publicly available pub key stored in DNS. </div><div>DMARC: A DNS records that states what to do if both the above fail, including reporting to a specific address. There are fun things like being able to request only report a percages of email etc.</div><div>DANE: (A little more complicated, whilst I get my head around it). Ability to authenticate sending and receiving mail servers, through publication of a DNS TLSA records (which should be DNSSEC signed). Where TLSA records are used to associate a TLS server certificate or public key with the domain name where the record is found. This in theory should prevent MITM attacks etc. </div><div><br></div><div><br></div><div>Thanks,</div><div>Simon.</div><div> </div><div><br></div></div></div>