Re: lists and DMARC and ARC, was Incoming SMTP in the year 2017 and absence of DKIM
On Wed, 29 Nov 2017 13:46:05 -0800, Michael Thomas said: > Apparently the levine unit is hearing things again because nobody -- > least of all me -- has > said anything about arc. I believe it was a pre-emptive statement. pgp2H7Fy1I06i.pgp Description: PGP signature
Re: lists and DMARC and ARC, was Incoming SMTP in the year 2017 and absence of DKIM
On 11/29/2017 01:11 PM, John Levine wrote: PPS: Please spare us pontification about why ARC can't possibly work unless you're prepared to cite section numbers in the ARC spec supporting your argument. Apparently the levine unit is hearing things again because nobody -- least of all me -- has said anything about arc. Mike
Re: lists and DMARC and ARC, was Incoming SMTP in the year 2017 and absence of DKIM
On 11/29/2017 03:00 PM, Grant Taylor via NANOG wrote: On 11/29/2017 03:46 PM, Michael Thomas wrote: You know what the original header was via the signature. You can take the delta of the current subject line and remove any additions and validate the signature. Whether you're happy with the additions is a different concern, Are you referring to the optional z DKIM-Signature tag? Or are you referring to brute forcing what the subject was in order to derive the delta of the current subject? This would be compounded by any number of other changes to (over)singed headers / body portion. If I were constructing a spam filter out of it, I'd give a lot of prejudice to anything added, but that's outside of what you can do within the bounds of the spec. *If* the z tag was included in the DKIM-Signature header, I can see how this would work and I agree with your distrust of said additions / alterations. Yes, with the z= Mike
Re: lists and DMARC and ARC, was Incoming SMTP in the year 2017 and absence of DKIM
On 11/29/2017 03:46 PM, Michael Thomas wrote: You know what the original header was via the signature. You can take the delta of the current subject line and remove any additions and validate the signature. Whether you're happy with the additions is a different concern, Are you referring to the optional z DKIM-Signature tag? Or are you referring to brute forcing what the subject was in order to derive the delta of the current subject? This would be compounded by any number of other changes to (over)singed headers / body portion. If I were constructing a spam filter out of it, I'd give a lot of prejudice to anything added, but that's outside of what you can do within the bounds of the spec. *If* the z tag was included in the DKIM-Signature header, I can see how this would work and I agree with your distrust of said additions / alterations. -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic Signature
Re: lists and DMARC and ARC, was Incoming SMTP in the year 2017 and absence of DKIM
On 11/29/2017 02:40 PM, Grant Taylor via NANOG wrote: On 11/29/2017 03:24 PM, Michael Thomas wrote: Message footers and subject lines can be dealt with. That's already been proven within the current DKIM spec. Please humor my ignorance and explain how a subject line (which is (over)signed) can be dealt with in the current DKIM spec? I get how footers can be dealt with, read appended. At least as long as DKIM only signs a given amount of the (original) body. (Though HTML (read: MIME structures) can complicate this.) - Or are you referring to something else? You know what the original header was via the signature. You can take the delta of the current subject line and remove any additions and validate the signature. Whether you're happy with the additions is a different concern, If I were constructing a spam filter out of it, I'd give a lot of prejudice to anything added, but that's outside of what you can do within the bounds of the spec. Mike
Re: lists and DMARC and ARC, was Incoming SMTP in the year 2017 and absence of DKIM
On 11/29/2017 03:24 PM, Michael Thomas wrote: Message footers and subject lines can be dealt with. That's already been proven within the current DKIM spec. Please humor my ignorance and explain how a subject line (which is (over)signed) can be dealt with in the current DKIM spec? I get how footers can be dealt with, read appended. At least as long as DKIM only signs a given amount of the (original) body. (Though HTML (read: MIME structures) can complicate this.) - Or are you referring to something else? -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic Signature
Re: lists and DMARC and ARC, was Incoming SMTP in the year 2017 and absence of DKIM
On 11/29/2017 01:11 PM, John Levine wrote: In article <1d458e76-ab61-db28-79cb-6aabcab4f...@mtcc.com> you write: I've been saying for years that it should be possible to create the concept of DKIM-friendly mailing lists. ... I suppose, if your users are OK with no subject tags, message footers, or any of the other cruft that list users have taken for granted for the past 30 years. Message footers and subject lines can be dealt with. That's already been proven within the current DKIM spec. Mike
Re: lists and DMARC and ARC, was Incoming SMTP in the year 2017 and absence of DKIM
In article <1d458e76-ab61-db28-79cb-6aabcab4f...@mtcc.com> you write: >I've been saying for years that it should be possible to create the >concept of DKIM-friendly mailing lists. ... I suppose, if your users are OK with no subject tags, message footers, or any of the other cruft that list users have taken for granted for the past 30 years. The people who brought us DMARC have a new anti-DMARC thing called ARC that is intended to help recipients guess whether a message with a broken signature came through a mailing list. It's a kludge, but since it's a kludge that Gmail has already implemented, you'll be seeing more of it. Returning to the original question, if a message has no DKIM signature, that doesn't say anything particularly bad, but it does mean that the sending IP is your main bit of info to decide whether it's mail you want, which has issues of its own. R's, John PS: details here https://dmarc.org/resources/specification/ PPS: Please spare us pontification about why ARC can't possibly work unless you're prepared to cite section numbers in the ARC spec supporting your argument.
