On Tue, Jul 31, 2018 at 17:26 John Levine wrote:
> In article v...@mail.gmail.com> you write:
> >> It doesn't say that in 4.1.2, even though it's sort of implicit since
> >> i= means something else. I'd say so explicitly in a fifth bullet
> >> after where it says "three (3) differences."
> >
>
In article
you write:
>> It doesn't say that in 4.1.2, even though it's sort of implicit since
>> i= means something else. I'd say so explicitly in a fifth bullet
>> after where it says "three (3) differences."
>
>One of those differences says:
>
>* the presence of the “instance tag”. Additional
Dear WG,
I thought I'd chime in in support of the draft. Having implemented DKIM,
SPF
and various other email authentication protocols, I've chosen this time to
integrate and contribute to OpenARC instead (power to the community! :)).
So while I didn't implement it directly, I can't help but read
On Tue, Jul 31, 2018 at 3:13 PM, John Levine wrote:
> It doesn't say that in 4.1.2, even though it's sort of implicit since
> i= means something else. I'd say so explicitly in a fifth bullet
> after where it says "three (3) differences."
>
One of those differences says:
* the presence of the “
In article
you write:
>-=-=-=-=-=-
>
>I've added the following text as Section 4.1.4 (note fixed typos and
>removal of the i= section, which is removed from ARC explicitly):
It doesn't say that in 4.1.2, even though it's sort of implicit since
i= means something else. I'd say so explicitly in a
I've added the following text as Section 4.1.4 (note fixed typos and
removal of the i= section, which is removed from ARC explicitly):
4.1.4: Internationalized mail considerations
In internationalized messages [RFC 6532] many header fields can contain
UTF-8 as well as ASCII text. The changes fo
In article
you write:
>The appropriate place for this guidance is likely a second paragraph in 4.1
>(https://tools.ietf.org/html/draft-ietf-dmarc-arc-protocol-16#section-4.1),
>as this guidance will apply to the three following header fields.
>
>Would you mind suggesting a paragraph to add in thi
On Tue, Jul 31, 2018 at 1:48 PM, John Levine wrote:
> >So the only wording consideration under WGLC is the ABNF import with
> >respect to DKIM and draft-levine-appsarea-eaiauth?
>
> Yes, although it's probably worth reminding people where things are
> different in EAI messages.
>
The appropriate
In article
you write:
>-=-=-=-=-=-
>
>I agree ARC should be EAI-ized.
>
>To be clear, are you saying that once 7601bis and draft-levine-appsarea-eaiauth
>are approved by the IESG and properly update 7601 and 6376, then no direct
>changes are needed to the ARC spec?
>
>So the only wording consider
I agree ARC should be EAI-ized.
To be clear, are you saying that once 7601bis and draft-levine-appsarea-eaiauth
are approved by the IESG and properly update 7601 and 6376, then no direct
changes are needed to the ARC spec?
So the only wording consideration under WGLC is the ABNF import with
respe
I was updating my EAI-izing draft for DKIM and DMARC and realized that it
would be nice not to have to update ARC, too.
The gist of it is the same as what I said for DKIM: anywhere there's a
domain name there can be an IDN written with U-labels (Unicode), and
anywhere there's user text, the te
On Tue, Jul 31, 2018 at 4:09 AM, Alessandro Vesely wrote:
> > Do you have a suggestion for alternative text?
>
> Say:
>
> In that case, if the producer intent is not to harm or mislead, the
> trust
> in this field's content would be proportional to the estimated quality
> of
> the pro
On Mon 30/Jul/2018 07:58:29 +0200 Murray S. Kucherawy wrote:
> On Sun, Jul 29, 2018 at 11:23 AM, Alessandro Vesely wrote:
>
>> *Section 1.2. "Trust Boundary"*
>> That section ends with two questionable statements about A-R fields found
>> in an attachment:>>
>> The details
13 matches
Mail list logo
