On Wed, Apr 5, 2023, at 5:20 PM, Seth Blank wrote:
> When we talk about DMARC and interoperability, we have to remember that there
> are THREE participants within DMARC that need to interoperate, the sender,
> the receiver, and the domain owner. We keep on discussing the sender and
> receiver re
On Wed, Apr 5, 2023, at 4:41 PM, Jim Fenton wrote:
> This got me to musing: What if IETF decided to remove its From address
> rewriting and started bouncing all incoming mail to its mailing lists from
> domains that have a p=reject (and maybe p=quarantine) policy? I don’t think
> it would be pre
On Wed, Apr 5, 2023 at 5:41 PM Jim Fenton wrote:
> On 1 Apr 2023, at 8:25, Dotzero wrote:
>
> > Hmm, let's apply this to DMARC.
> >
> > " But it interoperates just fine once you make the effort."
> >
> > Nobody forces a Sender to publish a DMARC record. Nobody forces a
> receiver
> > to validate
On April 5, 2023 10:20:28 PM UTC, Seth Blank
wrote:
>On Wed, Apr 5, 2023 at 2:57 PM Scott Kitterman wrote:
>
>> My understanding is that the IETF doesn't do implementation
>> specifications. I'm not sure what problem that's related to
>> interoperability this is meant to address.
>>
>> I thin
I believe there’s a critical use case we missed with the tree walk,
specifically around policy and reporting discovery, not determining
organizational domain alignment.
One of the reasons we discussed a tree walk for DMARC bis in the first
case, was a specific problem with larger more complicated
Yes, imperfections will always be with us.That is my point.
Why should we expect that millions of organizations, operating
independently, will produce a result where the good guys always have
perfectly correct information?
My implementation expects problems.Separating the harmless mistake
On Wed, Apr 5, 2023 at 2:57 PM Scott Kitterman wrote:
> My understanding is that the IETF doesn't do implementation
> specifications. I'm not sure what problem that's related to
> interoperability this is meant to address.
>
> I think the ticket should be closed without action
The purpose of D
My understanding is that the IETF doesn't do implementation specifications.
I'm not sure what problem that's related to interoperability this is meant to
address.
I think the ticket should be closed without action
If you really think we need this, I think the Enforcement definition needs
som
On 1 Apr 2023, at 8:25, Dotzero wrote:
> Hmm, let's apply this to DMARC.
>
> " But it interoperates just fine once you make the effort."
>
> Nobody forces a Sender to publish a DMARC record. Nobody forces a receiver
> to validate DMARC. Nobody forces mailing lists to accept mail from domains
> wh
https://github.com/ietf-wg-dmarc/draft-ietf-dmarc-dmarcbis/issues/96
I tried to write up an INFORMATIONAL paragraph, for ticket #96, and it kept
on coming out strangely and did not feel appropriate in the document as a
section unto itself.
However, I think we can meet the intent of this ticket by
On Apr 5, 2023, at 3:58 AM, Douglas Foster wrote:The sad thing is that there is no need to do a bandage pull if evaluators can learn how to serve the interests of their users properly. I don't throw away any mail based on Sender Authentication failure alone. But I also don't tolerate the idea
The sad thing is that there is no need to do a bandage pull if evaluators
can learn how to serve the interests of their users properly. I don't
throw away any mail based on Sender Authentication failure alone. But I
also don't tolerate the idea that I have to accept malicious impersonation
in o
I’m with Doug on this one. The bandage should be pulled off quickly and sympathy expressed to those who miss backward compatibility. I wouldn’t say utilitarianism is the right frame but here why wouldn’t it be morally right not to mention technically sound to inconvenience and anger the few to crea
13 matches
Mail list logo
