On Thu, Jun 1, 2017 at 10:30 PM, Murray S. Kucherawy
wrote:
>
> I'm taking the opposite approach: There might be some utility later to
> them being different, so why proscribe it just because we don't see
> anything to gain when the protocol is nascent? I'd rather lock
On Thu, Jun 1, 2017 at 2:43 PM, Gene Shuman wrote:
> I don't have particularly strong opinions here. I can see no reason for
> the d= to differ, but also no harm in allowing it do so. So I think the
> question of what to do here is slightly more philosophical. I think I
>
On Thu, Jun 1, 2017 at 4:05 AM, Kurt Andersen (b) wrote:
> On Thu, Jun 1, 2017 at 12:10 PM, Murray S. Kucherawy
> wrote:
>
>> On Wed, May 31, 2017 at 6:23 PM, Kurt Andersen (b)
>> wrote:
>>
>>> There's another question that had been
I don't have particularly strong opinions here. I can see no reason for
the d= to differ, but also no harm in allowing it do so. So I think the
question of what to do here is slightly more philosophical. I think I
generally fall on the side of reducing user flexibility when nothing is
actively
On Jun 1, 2017 11:48 PM, "Seth Blank" wrote:
I'm slightly confused.
I have a strong sense that the d= tag should be the same between the AS and
AMS within an ADMD. I can absolutely see why the s= might legitimately
vary. However, I can't seem the harm in the d= tag differing.
I'm slightly confused.
I have a strong sense that the d= tag should be the same between the AS and
AMS within an ADMD. I can absolutely see why the s= might legitimately
vary. However, I can't seem the harm in the d= tag differing. If the
signatures validate, why should this matter?
Might this
On Thu, Jun 1, 2017 at 12:10 PM, Murray S. Kucherawy
wrote:
> On Wed, May 31, 2017 at 6:23 PM, Kurt Andersen (b)
> wrote:
>
>> There's another question that had been raised by Seth about whether d=
>> needs to match within an ARC set. The answer is yes,
On Wed, May 31, 2017 at 6:23 PM, Kurt Andersen (b) wrote:
> There's another question that had been raised by Seth about whether d=
> needs to match within an ARC set. The answer is yes, [...]
>
Why?
-MSK
___
dmarc mailing list
On Wed, May 31, 2017 at 3:08 PM, Brandon Long wrote:
> On Wed, May 31, 2017 at 1:42 PM, Murray S. Kucherawy
> wrote:
>
>> On Wed, May 31, 2017 at 1:35 PM, Murray S. Kucherawy > > wrote:
>>
>>> What benefit is there to covering AAR
On Wed, May 31, 2017 at 1:35 PM, Murray S. Kucherawy
wrote:
>
> What's the added value in covering AAR[n] twice, once with its b= and once
> without?
>
>
Sorry, that got out before my thought was fully formed.
What benefit is there to covering AAR with both the AMS and the
On Tue, May 30, 2017 at 6:38 PM, Kurt Andersen (b) wrote:
> On Fri, May 26, 2017 at 6:47 AM, Seth Blank wrote:
>
>> This might be a non-issue, but we're asking this question specifically
>> because we've run into an implementation issue within openarc that
On Fri, May 26, 2017 at 6:47 AM, Seth Blank wrote:
> This might be a non-issue, but we're asking this question specifically
> because we've run into an implementation issue within openarc that feels
> weird and seems like a matter the WG may want to weigh in on.
>
> Our
So, history, the concepts of ARC come from the XOAR as implemented by
Google.
There, there is the XOAR header and it's covered by the
X-Google-DKIM-Signature header. This translated to the AAR covered by
AMS. ARC obviously has the second layer with the AS, which seems likely to
provide the same
The two list approach to configuration actually seems sensible in general,
I'll discuss this with msk.
However, if the recommended AAR inclusion language accomplishes nothing,
shouldn't we remove it, regardless?
On Tue, May 30, 2017 at 3:00 PM, Brandon Long wrote:
>
>
> On
So I'm actively doing development on OpenARC right now, and this definitely
something that is being a source of some non-trivial awkwardness.
Can anybody recall why the aforementioned language of recommending
including the AAR's in the AMS is in there? Afaik, it seems to make no
sense, and is
This might be a non-issue, but we're asking this question specifically
because we've run into an implementation issue within openarc that feels
weird and seems like a matter the WG may want to weigh in on.
Our expectation is that, for any given ARC Set n, AMS[n] would cover AAR[n].
Currently in
16 matches
Mail list logo