On Fri, 26 Oct 2018 at 07:58, Richard James Salts <post...@spectralmud.org> wrote:
> On Friday, 26 October 2018 12:53:48 AM AEDT Scott Kitterman wrote: > > On October 25, 2018 10:56:53 PM UTC, Richard James Salts > <post...@spectralmud.org> wrote: > > >Hi all, > > > > > >This is offtopic in regards to postfix but I bring it up because of the > > >last > > >few emails I've sent to the postfix mailing list. > > > > > >I was originally signing all the headers mentioned in rfc6376 section > > >5.4, > > >whether they existed or not and mails to postfix mailing list failed > > >because of > > >the added List-* headers. I fixed that up so that it will only sign > > >those > > >headers when they exist. I now oversign only the From, Sender, > > >Reply-to, > > >Subject, Date, Message-id, To, CC, MIME-Version, Content-Type, Content- > > >Transfer-Encoding, Content-ID, Content-Description, > > >Content-Disposition, In- > > >Reply-To and References. > > > > > >This is still leading to the postfix mailing list failing DKIM once > > >it's added > > >a Sender header for owner-postfix-us...@postfix.org. Should I stop > > >oversigning > > >the Sender header? rfc5322 says the Sender header is unique if it > > >exists so if > > >there was a sender header would the postfix maling list strip it and > > >add it's > > >own? Should majordomo at russian-caravan be adding a Resent-From or > > >Resent- > > >Sender instead of Sender in order to prevent breaking the DKIM > > >signatures for > > >final recipients of people who include a signed Sender header? > > > > > >Your thoughts and opinions on this would be welcomed. > > > > I think you are making are poor assumption that the RFC 6376 should sign > > header fields are at related to should over sign. > > > > I've never before heard of anyone over signing anything except From. I > > wouldn't over sign anything else. Section 8.15 discusses this. As > you're > > discovering, over application of this mitigation brings it's own pain. > > I was basing the oversigning on discussion at https://noxxi.de/research/ > breaking-dkim-on-purpose-and-by-chance.html > <https://noxxi.de/research/breaking-dkim-on-purpose-and-by-chance.html> > where they reused and manipulated > existing dkim signed emails to send "valid" bogus emails. It does mention > that > the Sender header should be signed, but I'm not sure how useful it is in > practise or whether it needs to be oversigned. > I too have just found this article. But signing Sender will inevitably break DKIM for mails going through this mailing list. IMO (please correct me if wrong) the critical things for DKIM are: - don't use the l= (lower case L) tag when signing - don't use a 512-bit length key - sign whatever headers you like, but oversign the From header - use DMARC with p=reject With these protections I don't think it is feasible for a third party to spoof emails from your domain, except to recipients who don't apply DMARC (assuming that neither your DNS records nor your mailserver(s) have been hacked, and that the recipient's DNS is working correctly). Signed headers that are not oversigned could be modified in transit (by adding fake headers) but I don't see this as an effective attack vector and I am more concerned that legitimate alteration of some headers upon relaying might lead to email blocking (as OP has indeed found).
