On Thu, Aug 17, 2017 at 1:09 AM, Bron Gondwana <br...@fastmailteam.com> wrote:
> On Thu, 17 Aug 2017, at 15:28, Murray S. Kucherawy wrote: > > On Wed, Aug 16, 2017 at 5:47 PM, Bron Gondwana <br...@fastmailteam.com> > wrote: > > While there exists A SINGLE SITE which is ARC-unaware and DMARC p=reject > aware, you can't use ARC on a DMARC p=reject domain without rewriting the > sender. Otherwise that site will bounce the email. > > > Goodness, it's a wonder that we've ever successfully deployed anything > incremental around here. ;-) > -MSK > > > I laugh as well, but it's more than p=reject isn't enough in the ARC > world, because it doesn't distinguish between: > a) I'm OK with email from my domain being sent via mailing lists; and > b) no, this domain is only ever used for direct messages, it should never > appear in ARC chains that don't also pass DKIM. > > The existing behaviour of p=reject is (b) for receivers that don't support > ARC - so the question becomes: are we defining ARC to changing the > behaviour of p=reject to (a)? If so, will we define a different (b) later, > when we could instead have > defined a different p= for (a). > My point is that the "SINGLE SITE" posture is absurd. In all likelihood there are still some MTAs out there that don't implement ESMTP and nothing has melted. We should fully expect things to roll out gradually, as they always have. Anyone planning for a flag day should speak up now so we can disabuse them (and, of course, abuse them). If the success of DMARC depends on 100% deployment of ARC, we may as well pack up and go home now. It'll never happen. I support the idea of trying ARC even in the form you claim includes superfluous operations. (For the record, I find your technical argument compelling.) If after a period of experimentation and data collecting we find that the seal is not itself useful, we can negotiate a reduced form and try that. If you really want to prove your point sooner, implement both, run them for a while, and publish the results. But given that there are interoperating implementations now, I think there's enough to be learned from the experiment to continue from here rather than reset. -MSK
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
