On Sat, Jul 28, 2018, at 03:29, Seth Blank wrote:
> On Fri, Jul 27, 2018 at 10:21 AM, Murray S. Kucherawy
> wrote:>> On Fri, Jul 27, 2018 at 8:35 AM, Seth Blank
>> wrote:>>
>>> The verification algorithm is straightforward. If you receive a
>>> chain that ends with cv=fail stop your evaluation,
In article
you write:
>-=-=-=-=-=-
>
>On Fri, Jul 27, 2018 at 10:41 AM, Scott Kitterman
>wrote:
>
>> And if you don't want to make a new one, 5.7.26 (Multiple authentication
>> checks failed) seems at least not wrong. To get to this point DKIM,
>> DMARC,
>> and ARC have failed.
>
>Is this
On Fri, Jul 27, 2018 at 10:54 AM, Seth Blank wrote:
> On Fri, Jul 27, 2018 at 10:39 AM, Murray S. Kucherawy > wrote:
>>
>> But (and I think this proves my point) I don't know if "cv=fail" refers
>> to an invalid chain or a failed chain. I have to run the verification to
>> figure that out.
On Fri, Jul 27, 2018 at 11:15 AM, John R Levine wrote:
>
> I'd say that all signatures in a seal SHOULD have the same domain, to make
> them easier to evaluate.
>
So the Usage Guide will (does?) say that. Earlier consensus was to keep
that out of the normative document because a) it doesn't
On Fri, Jul 27, 2018 at 10:24 AM, John Levine wrote:
The ARC draft clearly says that every ARC header can be signed by
whatever domain you want.
Are you saying we should proscribe it, because its semantics are unclear?
I'd say that all signatures in a seal SHOULD have the same domain, to
On Fri, Jul 27, 2018 at 10:39 AM, Murray S. Kucherawy
wrote:
>
> But (and I think this proves my point) I don't know if "cv=fail" refers to
> an invalid chain or a failed chain. I have to run the verification to
> figure that out. But you're saying you just stop when you see "cv=fail".
>
> I
On Fri, Jul 27, 2018 at 10:41 AM, Scott Kitterman
wrote:
> And if you don't want to make a new one, 5.7.26 (Multiple authentication
> checks failed) seems at least not wrong. To get to this point DKIM,
> DMARC,
> and ARC have failed.
>
Is this better moved into Experimental Considerations?
We
On Friday, July 27, 2018 10:20:04 AM Murray S. Kucherawy wrote:
> On Fri, Jul 27, 2018 at 7:03 AM, John R. Levine wrote:
> > Ah. I still think it should go, but if you really want to do that, invent
> > a new enhanced status code. They're cheap. 5.7.7 isn't right, it's more
> > like corrupt
On Fri, Jul 27, 2018 at 10:24 AM, John Levine wrote:
> The ARC draft clearly says that every ARC header can be signed by
> whatever domain you want.
>
> I understand what that means technically, but I don't understand the
> semantics of an ARC set where the AMS and AS are signed by different
>
On Fri, Jul 27, 2018 at 10:29 AM, Seth Blank wrote:
> On Fri, Jul 27, 2018 at 10:21 AM, Murray S. Kucherawy > wrote:
>
>> On Fri, Jul 27, 2018 at 8:35 AM, Seth Blank wrote:
>>
>>> The verification algorithm is straightforward. If you receive a chain
>>> that ends with cv=fail stop your
This was just discussed in a thread with Jim Fenton last week (although
from the DNS angle).
The tl;dr is that we don't believe they'll ever be different, but there's
no technical reason to require d=/s= alignment between AS/AMS for the same
i=.
We can foresee places where separate signing
On Fri, Jul 27, 2018 at 10:21 AM, Murray S. Kucherawy
wrote:
> On Fri, Jul 27, 2018 at 8:35 AM, Seth Blank wrote:
>
>> The verification algorithm is straightforward. If you receive a chain
>> that ends with cv=fail stop your evaluation, you’re done. There’s no
>> separate validation path here.
The ARC draft clearly says that every ARC header can be signed by
whatever domain you want.
I understand what that means technically, but I don't understand the
semantics of an ARC set where the AMS and AS are signed by different
domains.
R's,
John
On Fri, Jul 27, 2018 at 8:35 AM, Seth Blank wrote:
> The verification algorithm is straightforward. If you receive a chain that
> ends with cv=fail stop your evaluation, you’re done. There’s no separate
> validation path here.
>
Then why bother signing anything when you affix "cv=fail"?
-MSK
On Fri, Jul 27, 2018 at 7:03 AM, John R. Levine wrote:
>
> Ah. I still think it should go, but if you really want to do that, invent
> a new enhanced status code. They're cheap. 5.7.7 isn't right, it's more
> like corrupt S/MIME bodies.
>
>
I did a bunch of these (for DKIM and SPF at least)
On Fri, Jul 27, 2018 at 08:24 Murray S. Kucherawy
wrote:
> covering the ARC header fields in the failing chain, all the data in the
>> failed chain can be modified as it is not covered under the latest
>> signature.
>>
>
> I think it's weird that the body of content that gets hashed by the
There's a bunch of errata from the past year that are neither verified nor
rejected. Most of them look correct, suggest they all be hold for update.
Erratum 5229: adds some misssing default values to the report XML scheme.
Looks correct.
Erratum 5365: report filename .gz should be .xml.gz.
On Fri, 27 Jul 2018, Kurt Andersen (b) wrote:
This is not a matter of *whether* you reject during the SMTP interchange as
how to do it in a meaningful way *if* you do so. The discussion about
signaling that the domain authentication failure led to the rejection is
the point of this section.
18 matches
Mail list logo
