I'm the author of one of the dkimpy mods to support arc, and I'm happy to share it. It's been sent to the dkimpy maintainer for inclusion, but he's been busy. It appears at this point to be correct, but it may not be pretty.
Brandon On Jun 28, 2016 5:09 PM, "Steven M Jones" <s...@crash.com> wrote: > + dm...@ietf.org list to capture for ARC discussion/archive > > On 06/28/2016 09:12, A. Schulze via dmarc-discuss wrote: > > > > Kurt just mention adoption in his last message. > > Adoption is a good point, I've two questions: > > > > 1) > > are there implementation available as open source? > > There is an OpenARC milter under development - it currently runs and > signs messages. A few bugs turned up at the last interop have been > fixed, but I have to see if the signatures/seals now verify. > > There are two modified versions of the dkimpy library that perform ARC > operations. If one - as planned - will be the basis for an > implementation in a mailing list manager, it will become publicly > available. The author of the other implementation is on these lists, but > it's up to them whether or not to discuss it further publicly. > > I was told of another effort that might result in a Perl module/library > for performing ARC operations, but it had stalled and I haven't had an > update on that for a while. > > > I'm aware Google has some code. > > There is one other large mailbox provider who has a functioning > implementation, and these two implementations are working when tested > against each other, and with one of the dkimpy libraries. > > > > 2) > > a general point I'm still unsure about: > > > > https://datatracker.ietf.org/doc/draft-ietf-dmarc-arc-usage say in 2.) > > "If the mailing list implemented ARC, ..." > > > > ARC *require* the list operator (Intermediary) to install new or update > > existing - right? > > But the list operators fail over the last years to do so. Why should I > > expect they will do now? > > p=reject on google/gmail/googlemail may generate the required pressure > > but that doesn't sound like the best way to achieve adoption. > > Section 2 of the Usage doc describes how ARC works. The phrase "If the > mailing list..." just indicates what would happen differently after ARC > functionality was added - it isn't addressing the question of when, how, > or why an MLM operator would update their software. > > Some kind of change will be required for virtually any application - > MLM, forwarding service, etc - to implement ARC. The only scenario I can > see where the application operator themselves didn't make a change, is > if a different group deployed an ARC signing capability to a downstream > MTA still within the ADMD that the application operates in. But somebody > is still making a change... > > Your question about motivation is a good one. I don't think there's any > way to coerce everybody to implement ARC - or anything else, for that > matter. If there were, the Internet would be a very different place. > > However I think we will see a standard "long tail" curve of adoption. > Once the protocol is fully tested and implementations released, there > will be a surge of early adopters - people who do it because they always > look for better ways to operate, ways to make sure their mail - or their > customers' mail - gets delivered cleanly everywhere, etc. > > Another increment will raise the level slowly as packages like Mailman > and Sympa are updated (assuming they will be) and a natural upgrade > cycle occurs. This is a slow process, and not everybody will do so. > > Will there be spikes as more senders or mailbox providers publish DMARC > p=reject policies? Maybe - if the provider is large enough, then > "definitely." But there are only so many of those that would make a > measurable impact, and even then it won't be universal. > > I think smaller application operators - MLMs, forwarding services, etc - > may feel pressure to adopt ARC simply because they are below the volume > thresholds where medium to large mailbox providers make exceptions for > them, or even identify them as such. In some percentage of cases where > their messages are misidentified, or have some tricky content, they'll > have issues and in some cases turn to ARC. FOSS options, and MLM > support, will be critical for these cases. > > Will they all do so? Of course not. Just as I'm sure somebody out there > is still running sendmail 5.65 on SunOS 4.x, somebody out there will > continue to run some version of Majordomo and never change it. > > Anybody have data on the adoption rate of the RFC2369 List-*: headers? I > doubt those jumped from 0 to 100 overnight, but they're very wide-spread > now. And I suspect there would be an interesting comparison to the > uptake of ARC over time. > > --Steve. > > Steve Jones > DMARC.org > > e: s...@dmarc.org, s...@crash.com > > > _______________________________________________ > dmarc mailing list > dm...@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc >
_______________________________________________ dmarc-discuss mailing list dmarc-discuss@dmarc.org http://www.dmarc.org/mailman/listinfo/dmarc-discuss NOTE: Participating in this list means you agree to the DMARC Note Well terms (http://www.dmarc.org/note_well.html)
