Hi Tim and all, I am wondering whether companies like Dmarcian could implement third-pary whitelisting. As they receive and analyze DMARC aggregate reports on behalf of many mail sites, they probably are able to distinguish various level of authentication failures, from mailing lists to misaligned ESPs, to actual abusers. In that case, they could maintain a whitelist tailored for any given client. The client would set, say:
_dmarc.client.domain.example IN TXT "v=DMARC1; rua=mailto:client...@ag.dmarcian.com; snd=client-id.rhswl.dmarcian.com; [...]" A receiver seeing a failed From: user@client.domain.example, but an authenticated Sender: whate...@example.com could check authorization by querying the following record: example.com.client-id.rhswl.dmarcian.com IN A 127.0.0.2 If the record exists, the sender is authorized. That way, a Dmarcian client can run for some time with p=none. Meanwhile Dmarcian fills the client's whitelist based on misaligned authentications and the client's desiderata. When the list is complete and receivers upgraded, the client can switch to p=reject or whatever they like. Delivery would still lag in case, say, users subscribe to mailing lists not yet whitelisted, unless we make provisions for whitelisting requests to be submitted at subscription time. For domain names longer than 200 octects (punycode), a whitelist may replace the domain name with a hash, รก la ATPS. The above setting overcomes the diagnosed non-trivial upkeep which prevented the diffusion of previous schemes. Best Ale -------- Original Message -------- Subject: Re: [dmarc-ietf] third party authorization, not, was non-mailing list Date: Wed, 19 Aug 2020 21:18:29 GMT From: Douglas E. Foster <fosterd=40bayviewphysicians....@dmarc.ietf.org> Reply-To: fost...@bayviewphysicians.com To: dmarc@ietf.org <dmarc@ietf.org> My two cents. 1) What has changed since 2012 is DMARC, including the ability through DMARC to obtain feedback. "New ATPS" would have to be implemented as a DMARC option, not a new thing. 2) A lot of organizations seem to be stick at p=none. Maybe that means they want it that way. Maybe it means that they are being courteous to mailing lists. But maybe it means something about DMARC is too hard. I am assuming that all of the problems with DMARC are related to third-party authorization, and something needs to be done to make it easier. 3) Delegation with an ATPS-type email entry seems functionally equivalent to DKIM scope delegation, with several benefits: Easier and cheaper for the third-party to implement. The third-party only needs to apply its own domain's signature. Simpler means quicker implementation. Private keys are never exchanged. Third-party is only responsible for its own key. A big organization like Constant Contact or SendGrid could end up holding hundreds of thousands of DKIM keys, and that becomes an attractive target for attackers. If a delegated DKIM key store is stolen from a third party, the attacker knows every domain that has been compromised. If an ATPS-delegated third party has a corporate DKIM key stolen, the attacker knows that he has struck pay-dirt, but he does not have an immediate enumeration of compromised organizations.. That enumeration will require an additional data collection process, which might buy time for the affected organizations to take evasive measures. An ATPS-type scope delegation could be designated for a specific user, which I assume will represents an application. ("SMTP address must be applicationname@vendordomain"). This information is something that the receiving system can enforce and report. It is a weak enforcement tool, but limiting scope of delegation seems likely to satisfy some of the auditor concerns associated with any third-party delegation. This is also a new ideas relative to the original ATPS. Of course, a domain level delegation should also be an option for situations that the authorizing domain deems appropriate. ("SMTP address must be *@vendordomain") ATPS-type delegations could be given a pre-defined expire date (if specified with that feature). This would be particularly appropriate where a third-party authorization is linked to a time-limited contract. When the contract lapses, the authorization lapses, unless both the contract and the DNS entry are renewed. This limits risk associated with the possibility of delegated-but-forgotten authorizations. DKIM delegations are always good-til-cancelled (by removing the DNS public key). Both DKIM and ATPS can be revoked easily, subject only to the limits of DNS propagation. DKIM delegation becomes impossible if the third-party is not cooperative. ATPS-type delegation can be done unilaterally by the owning domain. I am thinking of Proofpoint in particular. They violate my DMARC policy when my users, who are non-clients, respond to a secure message from one of their clients. Author self-copies arrive at my gateway looking like spoof, but I can fix this with local policy. When my user uses reply-all to a message with many recipients, those other domains will see my p=reject, which may mean that messages are not delivered and my user does not know that it happened. Maybe all those other domains will have a Proofpoint exception as well, impossible to say. Maybe Proofpoint will begin header munging, but they have not done so yet. So the big benefit for DKIM is the i= clause, but I think the sender-limiting potential with ATPS is superior to the impersonation-limiting capability of DKIM. Besides, it seems generally agreed that i= has very limited use. On all other risk-management concerns, an ATPS -type signature seems preferable. Implementation obstacles and notes: When a domain implements an ATPS signature, it must set the corresponding DMARC policy to p=none. Otherwise, sites that are DMARC-aware but ATPS-blind will block ATPS-authoized transactions. Consequently, this option will only interest organizations that are currently at p=none or that have no DMARC policy. If a new feature such as ATPS is implemented, senders have a problem knowing whether their recipients understand it or not. This dilemma would be helped if recipients published a DNS token to indicate that they understand the new feature. Some will consider this inappropriate information disclosure, although I am currently having a hard time seeing the risk in the release of that information. By and large, senders will want confidence that the new feature is widely deployed before they will begin depending on it for outbound delivery. In the absence of recipient reporting, change may never happen. Doug Foster ---------------------------------------- From: "Murray S. Kucherawy" <superu...@gmail.com> Sent: 8/19/20 2:38 PM To: "Kurt Andersen (b)" <kb...@drkurt.com> Cc: "dmarc@ietf.org" <dmarc@ietf.org>, Alessandro Vesely <ves...@tana.it> Subject: Re: [dmarc-ietf] third party authorization, not, was non-mailing list On Wed, Aug 19, 2020 at 10:11 AM Kurt Andersen (b) <kb...@drkurt.com> wrote: On Wed, Aug 19, 2020 at 1:34 AM Alessandro Vesely <ves...@tana.it> wrote: On Tue 18/Aug/2020 01:21:33 +0200 Murray S. Kucherawy wrote: > The industry in general, and the IETF in particular, have chosen not > to pursue widespread use of any kind of standards-based third party > domain signature policy or reputation system. . . > Both ATPS (individual submission, experimental, February 2012) and the > REPUTE series of documents (working group, standards track, late 2013) > saw nearly zero adoption after publication even when free reference > implementations were provided. They differ from basic DKIM in that > they require non-trivial upkeep, and that appears to be a step > function inhibiting adoption among operators. We can still try again. In particular, the non-trivial upkeep seems to be a valid diagnosis. Is there anything which has materially changed between 2012-13 and 2020 which would indicate that the anticipated results for such effort would be any different? +1. If anyone has some kind of creativity in this space that they've been hiding, now's the time. -MSK _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
