Re: [dmarc-discuss] ARC adoption

[A. Schulze via dmarc-discuss]

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 implementing  
ARC, then they're free to do so without having to incur additional  
operational problems, in particular without changing user experience.


(1) is not a big problem; for a list operator who doesn't have a  
problem that ARC addresses there is no reason for them to implement  
ARC, and it doesn't matter to anyone else if they don't.


Hello all,

thanks for your responses.

to repeat with my words:
ARC is an offer to Intermediaries which does even not require to  
change any semantics.

And for that reason there is chance for adoption.

hope I understood it correct ...

Andreas

___
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)

Re: [dmarc-discuss] ARC adoption

[Steven M Jones via dmarc-discuss]

+ 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:

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. ARC seeks to construct a situation in which forwarders and receivers will 
each gain incremental benefit if they choose to implement; it neither requires 
nor assumes implementation by any particular participant.


But the list operators fail over the last years to do so. Why should I expect 
they will do now?

List operators typically cite two compelling reasons for not making changes to 
support pre-ARC schemes:

1) the assumption that they're being asked to expend resources to solve someone 
else's problems; and
2) even if resource constraints are ignored, each of the proposed changes 
imposes harmful dilemmas (each option, including do nothing, is harmful).

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 implementing ARC, then they're free to do so without having 
to incur additional operational problems, in particular without changing user 
experience.

(1) is not a big problem; for a list operator who doesn't have a problem that 
ARC addresses there is no reason for them to implement ARC, and it doesn't 
matter to anyone else if they don't.

- Roland


Well put, Roland. I was so concerned with addressing the frequently 
asked question of "why will people upgrade" that I overlooked other 
considerations in my earlier response.


--S.


___
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)

Re: [dmarc-discuss] ARC adoption

[Roland Turner via dmarc-discuss]

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. ARC seeks to construct a situation in which forwarders and receivers will 
each gain incremental benefit if they choose to implement; it neither requires 
nor assumes implementation by any particular participant.

> But the list operators fail over the last years to do so. Why should I expect 
> they will do now?

List operators typically cite two compelling reasons for not making changes to 
support pre-ARC schemes:

1) the assumption that they're being asked to expend resources to solve someone 
else's problems; and
2) even if resource constraints are ignored, each of the proposed changes 
imposes harmful dilemmas (each option, including do nothing, is harmful).

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 implementing ARC, then they're free to do so without having 
to incur additional operational problems, in particular without changing user 
experience.

(1) is not a big problem; for a list operator who doesn't have a problem that 
ARC addresses there is no reason for them to implement ARC, and it doesn't 
matter to anyone else if they don't.

- Roland



___
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)

Re: [dmarc-discuss] ARC adoption

[Elizabeth Zwicky via dmarc-discuss]

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 are more positive 
about ARC than they are about changing From:.

ElizabethOn Tuesday, June 28, 2016 9:12 AM, A. Schulze via dmarc-discuss 
 wrote:
 

 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 that kind of special I don't expect so many implementers with 
the necessary skills.

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.

Andreas
___
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)


   ___
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)

Re: [dmarc-discuss] ARC adoption

[Steven M Jones via dmarc-discuss]

+ 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-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)