Re: [dmarc-ietf] Minutes from IETF 112
On 11/18/2021 1:44 PM, John Levine wrote: > It appears that Todd Herr said: >> It seems to me that DMARC already provides the ability for >> security.example.edu to ensure that no other part of example.edu can send >> mail on their behalf. To accomplish this, security.example.edu can today: >> >> - Publish an SPF record listing only hosts under its direct control, a >> record which ends with "-all" >> - Ensure that only hosts under its control can DKIM sign messages using " >> security.example.edu" as the signing domain, by making sure that its >> private DKIM signing key is only deployed to hosts under its control >> - Publish a DMARC policy record that includes the following three tags >> and values: >> - p=reject >> - adkim=s >> - aspf=s > > Agreed. That would work fine. > > An sp=reject in both security.example.edu and its org domain would also be a > good idea. (Sorry, AWOL due to new employment, only tertiary involved in matters relevant to this discussion these days. Also haven't read this list for about a year.) Here's my best recollection of the issue: p=(quarantine|reject) isn't the real issue for example.edu; just tell departments to use their sub.example.edu domains (localized control/branding makes people happy, more or less.) [1] p=(quarantine|reject) for sub.example.edu isn't really an issue either; just a microcosm. The problem is when there are departments with lots of systems all sending from hostname.sub.example.edu. So, sub.example.edu needs time to reconcile (or doesn't care to), wants to publish sp=none for sub.example.edu; but can't because the org domain's sp policy is the only one that matters, since there is no tree walk from hostname.sub.example.edu to sub.example.edu. Meanwhile, example.edu can't move beyond sp=none. Also, the lack of control down the tree means that example.edu would never be able to use aspf=r, which is restricting a useful feature from organizations that could probably benefit the most from the flexibility it provides. I don't think that inability to use adkim=r is as much of an issue since individual CNAME records are easy to create under example.edu. This if off topic in my mind, but it was mentioned above. Jesse [1] most complex institutions probably aren't so willing to hand out subdomains like candy ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Reversing modifications from mailing lists
On November 30, 2021 5:30:39 PM UTC, John R Levine wrote: >On Tue, 30 Nov 2021, Wei Chuang wrote: >> What about adding a footer to some html mime part is poorly handled when >> using "l="? Multipart bodies could be handled by other techniques. > >See section 8.2 in the DKIM spec which says if you use l= you need to be >careful with your MIME boundaries so naughty people can't add another part >that overlays the real message. > >I have seen lists that edit the footer into the HTML of the body, I think >at Yahoo groups. Don't see how you're going to describe that in a >reversible way. Or, we could stop trying to design a DKIM replacement and work on DMARC. Scott K ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Reversing modifications from mailing lists
On Mon 29/Nov/2021 15:17:45 +0100 John R Levine wrote: On Mon 29/Nov/2021 04:03:57 +0100 John Levine wrote: This was part of the discussion about what sort of body modifications to allow. We ended up with optionally ignoring white space changes, and l= to ignore added text. My impression is that neither is useful. Very few messages pass with relaxed canonicalization that don't also pass strict. Using relaxed rather than strict is quite different between header and body. It is fairly frequent to find reflowed headers, especially with MLM handling, while bodies remain mostly untouched, except for CR additions and removals. Of course, X-MIME-Autoconverted rewrite bodies beyond strict/ relaxed range. (That's the original mistake.) Well yeah, welcome to mail UNCOL land. Those conversions used to afflict direct mail flows as well. It'd be enough to add the subject tag on new messages to address the other changes. Using l= works well with a wide range of mailing lists. However, it only works with plain text. I suppose if by wide range you mean lists that do not add subject tags and do not handle html or multipart bodies. That may be common among nerd lists but take a look beyond mailman and I don't think it is. OTOH, it'd feel cringing to discuss the standardization of solutions to deal with indirect mail flows using a mailing list where neither of those solutions apply. Best Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
