Murray S. Kucherawy writes:
> Some sort of contract or agreement between sender and receiver
> seems to me to be unavoidable if we want to leverage ARC without
> having a global domain reputation system. We don't have a
> precise method to do that. We need to experiment and
>
My overall assessment as an early adopter and implementation:
DMARC SHOULD NOT be declared a Standard Track document. We still have the
potential to develop a sound 1st, 3rd party DKIM Policy model. Declaring
DMARCBis a STD will only hamper future development. Keep it experimental or
No might about it -- ARC is only useful with domain reputation. Of course, DKIM
is only useful with domain reputation, as were Domainkeys and IIM, so I don't
see why it's a problem now.
Much of the objective of DomainKeys/IIM/DKIM was to provide a reliable
domain identifier that could be
On 4 Apr 2024, at 13:31, John R. Levine wrote:
>> I don’t think it’s scope creep at all. The WG charter puts “Review and
>> refinement of the DMARC specification” in phase III, after “Specification of
>> DMARC improvements to support indirect mail flows”. It seems clear to me
>> that
I don’t think it’s scope creep at all. The WG charter puts “Review and
refinement of the DMARC specification” in phase III, after “Specification of
DMARC improvements to support indirect mail flows”. It seems clear to me that
standards-track DMARC needs to incorporate those improvements.
IESG
Sender reputation is in use everywhere. What is lacking is an omniscient
data source, but I have no hope of finding one. Small senders will always
be at a disadvantage because sender reputation is entirely based on past
experience, and smaller senders have less experience to draw upon. ARC
On 4 Apr 2024, at 12:08, Murray S. Kucherawy wrote:
> On Thu, Apr 4, 2024 at 12:02 PM Dotzero wrote:
>
>>
>>
>>>
>>> My overall point is that this thread makes it seem like we're not putting
>>> forward a complete solution. It feels a lot more like a proposed standard
>>> that for its clear
On Thu, Apr 4, 2024 at 12:02 PM Dotzero wrote:
>
>
>>
>> My overall point is that this thread makes it seem like we're not putting
>> forward a complete solution. It feels a lot more like a proposed standard
>> that for its clear success depends on a bunch of other things that range
>> from
On Thu, Apr 4, 2024 at 1:42 PM Murray S. Kucherawy
wrote:
> On Thu, Apr 4, 2024 at 10:21 AM Douglas Foster <
> dougfoster.emailstanda...@gmail.com> wrote:
>
>> Murray, I was hoping your proposal to advance ARC was serious.
>>
>
> If people think (and have evidence that) ARC is ready, then why
On Thu, Apr 4, 2024 at 10:21 AM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:
> Murray, I was hoping your proposal to advance ARC was serious.
>
If people think (and have evidence that) ARC is ready, then why would I not
be serious?
The WG needs to resolve that "if" though.
>
On Thu 04/Apr/2024 18:13:37 +0200 Murray S. Kucherawy wrote:
On Thu, Apr 4, 2024 at 8:50 AM Alessandro Vesely wrote:
I know what "contract" means abstractly, but what does this actually look
like to someone that's looking for specific guidance? The text you have
here, by itself, is vague
Murray, I was hoping your proposal to advance ARC was serious.
Google has solved the problem of limited ARC deployment. To my mind, this
means that we cannot revoke the experiment and we cannot do much to change
it, so we might as well advance it to standards track. It became a
de-facto
On Thu, Apr 4, 2024 at 8:50 AM Alessandro Vesely wrote:
> > I know what "contract" means abstractly, but what does this actually
> look
> > like to someone that's looking for specific guidance? The text you have
> > here, by itself, is vague and I don't think many operators will know
> what
> >
On Wed 03/Apr/2024 18:49:50 +0200 Murray S. Kucherawy wrote:
On Wed, Apr 3, 2024 at 4:16 AM Alessandro Vesely wrote:
Some sort of contract or agreement between sender and receiver seems to me
to be unavoidable if we want to leverage ARC without having a global domain
reputation system. We
14 matches
Mail list logo
