Re: [dmarc-ietf] Debugging and preventing DKIM failures- suggestion
On 5/30/2019 7:49 PM, Douglas E. Foster wrote: I rather hoped that IETF would be the poster-boy for list processing done correctly. "Correctly"? A message to a list is 'delivered' to the list. As in, it goes to the specified addresse... the list. A message from a list has been re-posted by the list. There are no constraints on the changes that are permitted to a message, before it is re-posted. There are no specifications that limit or direct the behaviors of a list processor. Different groups want and probably need different behaviors by a list processor. Periodic efforts to create such constraints have failed. So while it would certainly make things easier to have list processors behave in a simple, consistent manner, there's ample evidence that ain't gonna happen. If you can link the 'correctly' you are suggesting, to some documented, community consensus, please cite it. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Debugging and preventing DKIM failures- suggestion
Thank you for the education The IETF list processor seems to be an illustration of your point. It invalidates the orginal sender's signature Then it adds an ietf.org signature Then the message is relayed internally within a single IETF server, where the IETF signature is invalidated.The the message is signed a second time with an valid IETF signature I rather hoped that IETF would be the poster-boy for list processing done correctly. Why is the message manipulation that you describe necessary or acceptable? Deeply puzzled, Doug Foster From: "John R Levine" Sent: Thursday, May 30, 2019 5:19 PM To: "Murray S. Kucherawy" Cc: "IETF DMARC WG" Subject: Re: [dmarc-ietf] Debugging and preventing DKIM failures- suggestion > And as John said, there have been numerous proposals over the years of ways > to annotate a message with what "standard" mutations were done so that at > verification time the receiver could decide which mutations it was willing > to forgive, but the community showed no interest in such complexities. It is my impression that the proponents of this idea tended not to be very familiar with mailing list software and imagined that most mutations were simple, like adding a subject tag or a text footer. Those happen, but they are the very tip of the iceberg. Modern list managers add, delete, and reorder MIME parts, flatten HTML into text, and a huge list of other things that no mutuation catalog could plausibly describe. That's one of the reasons that ARC doesn't try to say what's changed, just what the authentication results were before and after. Regards, John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARC PSD and non-existent subdomains
On Thu, May 30, 2019 at 9:06 AM Richard C wrote: > What would be the best way to incorporate this requirement? > The simplest possible way to address this use case is just to make sure those existing but currently non-compliant domains just have a bare p=none record. Then they'll never fall back to the gov.uk record. There's no risk to inadvertently breaking mail here. It it remotely realistic for you to offer this guidance? If you're already saying that p=reject is required, how painful is it to advertise that any domain without a DMARC record will get p=reject by default unless it explicitly puts p=none in? Seth ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Debugging and preventing DKIM failures- suggestion
And as John said, there have been numerous proposals over the years of ways to annotate a message with what "standard" mutations were done so that at verification time the receiver could decide which mutations it was willing to forgive, but the community showed no interest in such complexities. It is my impression that the proponents of this idea tended not to be very familiar with mailing list software and imagined that most mutations were simple, like adding a subject tag or a text footer. Those happen, but they are the very tip of the iceberg. Modern list managers add, delete, and reorder MIME parts, flatten HTML into text, and a huge list of other things that no mutuation catalog could plausibly describe. That's one of the reasons that ARC doesn't try to say what's changed, just what the authentication results were before and after. Regards, John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Debugging and preventing DKIM failures- suggestion
On Sun, May 26, 2019 at 7:49 AM John Levine wrote: > In article <54fb29a0-517a-430e-af5b-cb079cc3d...@aegee.org> you write: > >-=-=-=-=-=- > > > >Hello Douglas, > > > >1) Check the Authentication-Results header. An implementation could put > there additional information as comment. A > >downstream MTA will reevaluate the DKIM-Signature anyway, if it does nkt > trust the previous hop. Common case: aliases > >to random servers. > > That would be my suggestion. You can put whatever you want into comments > in the A-R header. > At one point in the early DKIM days we were discussing a way to have DKIM verifiers return enough information to signers to indicate what the mutation was that invalidated a message. This was supremely useful in the early days of DKIM when we were just figuring out how to interoperate; if I keep a copy of the the canonicalized header and body of something outbound, and then on receipt you find the signature doesn't validate, then you send me the canonicalized header and body you saw, and I get to diff them to see what mutation broke the signature. We ended up with RFC6651 and the ones to which it references. OpenDKIM implements this, but I don't think any other implementation does, so its use is obviously very limited. And as John said, there have been numerous proposals over the years of ways to annotate a message with what "standard" mutations were done so that at verification time the receiver could decide which mutations it was willing to forgive, but the community showed no interest in such complexities. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARCbis issue: Separating reporting and policy
On Wed, May 29, 2019 at 10:13 AM John R Levine wrote: > As far as I can tell your proposal to break the document in two has > gotten no support at all. Can we stop now? > What's on topic for the group and what isn't is the purview of the co-chairs and the charter. Let's please not stifle discussions before they die on their own absent chair action to the contrary. -MSK, from the floor ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-psd-04.txt
I'll initiate WGLC before the weekend. I have some feedback from outside the WG that I will forward, but it's not serious enough to block starting WGLC. On Tue, May 28, 2019 at 5:17 AM Craig Schwartz wrote: > I've reviewed the draft. We plan to implement this as soon as possible > (for .bank and > .insurance) and would like to see this get to WG last call shortly. > > Craig Schwartz > Managing Director > fTLD Registry Services | .BANK & .INSURANCE > Office: +1 202 589 2532 > Mobile: +1 202 236 1154 > Skype: craig-schwartz > www.fTLD.com > > > > > > > On Mon, May 27, 2019 at 6:53 PM wrote: > >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the Domain-based Message Authentication, >> Reporting & Conformance WG of the IETF. >> >> Title : DMARC (Domain-based Message Authentication, >> Reporting, and Conformance) Extension For PSDs (Public Suffix Domains) >> Author : Scott Kitterman >> Filename: draft-ietf-dmarc-psd-04.txt >> Pages : 11 >> Date: 2019-05-27 >> >> Abstract: >>DMARC (Domain-based Message Authentication, Reporting, and >>Conformance) is a scalable mechanism by which a mail-originating >>organization can express domain-level policies and preferences for >>message validation, disposition, and reporting, that a mail-receiving >>organization can use to improve mail handling. DMARC policies can be >>applied at the individual domain level or for a set of domains at the >>organizational level. The design of DMARC precludes grouping >>policies for a set of domains above the organizational level, such as >>TLDs (Top Level Domains). These types of domains (which are not all >>at the top level of the DNS tree) can be collectively referred to as >>Public Suffix Domains (PSDs). For the subset of PSDs that require >>DMARC usage, this memo describes an extension to DMARC to enable >>DMARC functionality for such domains. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-dmarc-psd/ >> >> There are also htmlized versions available at: >> https://tools.ietf.org/html/draft-ietf-dmarc-psd-04 >> https://datatracker.ietf.org/doc/html/draft-ietf-dmarc-psd-04 >> >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=draft-ietf-dmarc-psd-04 >> >> >> Please note that it may take a couple of minutes from the time of >> submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> ___ >> dmarc mailing list >> dmarc@ietf.org >> https://www.ietf.org/mailman/listinfo/dmarc >> > ___ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
[dmarc-ietf] DMARC PSD and non-existent subdomains
Hello At the National Cyber Security Centre in the UK we're supportive of the PSD DMARC initiative. However, we currently have one problem that would hamper its applicability to our use case: We essentially have the need to express different subdomain policies to existing and non-existing domains. In our case for the gov.uk PSD we'd like to be able to set a 'reject' policy for non-existent subdomains to prevent delivery of email from them whilst not interfering with authentication of email for the legitimate subdomains. Why? Well, whilst we have a programme of work to get domain owners under gov.uk to implement DMARC and other standards, it will take some of them time, and we don't want to inadvertently break mail delivery for the organisations that have e.g. implemented SPF but not DMARC. But on the flipside, we also know that non-existent domains under gov.uk are being spoofed for phishing, so we want to publish a policy of 'reject' on those and receive reporting about them. What would be the best way to incorporate this requirement? Thanks in advance Richard Crowther, NCSC This information is exempt under the Freedom of Information Act 2000 (FOIA) and may be exempt under other UK information legislation. Refer any FOIA queries to ncscinfo...@ncsc.gov.uk ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
