The only thing I'd add is that in discussion with Seth Blank, I've implemented
the following format (for now) in an open PR for OpenDMARC that implements this:
delivered
fail
fail source.ip=10.0.0.1
local_policy
arc=[status] as[N].d=dN.example.com as[N].s=sN ..
Thanks for capturing. I agree it makes sense to figure out ticket #16 (
https://trac.ietf.org/trac/dmarc/ticket/16#ticket) first.
Best,
Peter
On Sun, Mar 18, 2018 at 11:00 AM, Kurt Andersen (b)
wrote:
> On Sun, Mar 18, 2018 at 6:54 PM, Peter M. Goldstein <
> peter.m.goldst...@gmail.com> wrote
On 3/17/2018 2:41 AM, Kurt Andersen (b) wrote:
There are two aspects to this -
1. batching (lightens the load for reporting receivers), and
2. re privacy - the fact that someone with authority (over the domain)
has requested said reports suffices for GDPR legal/consent coverage
I'll sug
On Sun, Mar 18, 2018 at 6:54 PM, Peter M. Goldstein <
peter.m.goldst...@gmail.com> wrote:
> Kurt,
>
> Re: -12, it doesn't appear to capture the feedback in the email Mark
> Eissler sent to the list on 2/27. There was also no on-list reply to his
> email that I saw, so I wanted to re-raise the iss
Kurt,
Re: -12, it doesn't appear to capture the feedback in the email Mark
Eissler sent to the list on 2/27. There was also no on-list reply to his
email that I saw, so I wanted to re-raise the issue. His email is included
below.
Mark's analysis appears to be on-point, and I think the XML fragm
This version incorporates various fixes suggested by people since -11.
There are a collection of (mostly minor) open issues now logged into the
issue tracker (
https://trac.ietf.org/trac/dmarc/query?status=accepted&status=assigned&status=new&status=reopened&component=arc-protocol&col=id&col=summary
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Domain-based Message Authentication, Reporting
& Conformance WG of the IETF.
Title : Authenticated Received Chain (ARC) Protocol
Authors : Kurt Ander
On Sun, Mar 18, 2018 at 11:25 AM, Alessandro Vesely wrote:
> Would it be possible to insert a dnswl method in the new spec?
> [...]
>
I'd prefer to do this as its own document. The current one is feeling very
"kitchen sink" already, and this change has more meat to it than the others
that have
On Sun 18/Mar/2018 12:25:05 +0100 Alessandro Vesely wrote:
>
> Besides, that ptype could also be used to define DKIM algorithm as, say, dns.a
> or dns.key-a instead of header.a --just an idea.
Ops, I got confused by another argument[*]. Yet, dns it could used for
the t= key flag.
[*] https://m
The only changes in this version are the corrections that John had provided.
Title : Using Multiple Signing Algorithms with the ARC
(Authenticated Received Chain) Protocol
Authors : Kurt Andersen
Seth Blank
John
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Domain-based Message Authentication, Reporting
& Conformance WG of the IETF.
Title : Using Multiple Signing Algorithms with the ARC
(Authenticated Received Chain) P
Would it be possible to insert a dnswl method in the new spec?
Last time I asked for its insertion, (via expert opinion) it was rejected based
on the definition of ptype, according to which The exception to ptype +
property indicating which particular part of the message from which the data is
ext
12 matches
Mail list logo
