Roland Turner via dmarc-discuss:
ARC directly addresses (2). Unlike the measures for interoperating
with earlier schemes, adding an ARC-* header set does not in any way
impede or alter the traditional operation of mailing lists.
Consequently: if list operators perceive benefit in
+ dm...@ietf.org because Roland's responses should be
considered/captured there too.
Additional comment bottom-posted.
On 6/29/16 12:09 AM, Roland Turner via dmarc-discuss wrote:
Andreas Schulze wrote:
2)
a general point I'm still unsure about:
Andreas Schulze wrote:
> 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?
No.
Previous ways of adapting to DMARC involved changing mailing list semantics;
ARC doesn't. That's a theoretical reason to believe it may get adoption where
other things didn't. The practical one is that there are mailing list systems
working on code, and mailing list operators I've spoken too
+ 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
Hello,
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?
I'm aware Google has some code. I guess there are other implementers
otherwise the inter-op events wouldn't make sense.
The protocol is
