On Thu, Jun 22, 2023 at 7:18 PM John Levine wrote:
> It appears that Emil Gustafsson said:
> >I don't know if there is a better way to encode that, but I'm supportive
> of
> >making a change that that would allow domains to tell us (gmail) that they
> >prefer us to require both dkim and spf
It appears that Emil Gustafsson said:
>I don't know if there is a better way to encode that, but I'm supportive of
>making a change that that would allow domains to tell us (gmail) that they
>prefer us to require both dkim and spf for DMARC evaluation (or whatever
>combination of DKIM and SPF
The #2 option (backward compatible with new auth tag) is a good
clarification what we were thinking and that Wei mentioned here:
https://mailarchive.ietf.org/arch/msg/dmarc/KeGbMfX91WJk_aziKsrRfI6AYkI/
I don't know if there is a better way to encode that, but I'm supportive of
making a change
>
>
> Barry, this is obviously a new relaxation option. From a mail system
> integration standpoint, the options are:
>
> 1) A version bump to DMARC2 with new semantics with backward DMARC1
> compatibility, or
>
> 2) Use a DMARC1 Extended tag option allowed by DMARC1. Alessandro cited
> an
> On Jun 22, 2023, at 9:54 AM, Scott Kitterman wrote:
>
> My conclusion (it won't surprise you to learn) from this thread is precisely
> the opposite.
>
> In theory, DKIM is enough for DMARC (this was always true), but in practice
> it
> is not.
>
> I don't think there's evidence of a
> On Jun 22, 2023, at 1:08 PM, Barry Leiba wrote:
>
>> I concur that this isn't really a problem for either working group to solve
>> as part of a standard,
>
> Well, the part that the working group needs to solve is whether the
> challenges of getting DKIM right are such that we need to
On Thu, Jun 22, 2023 at 8:59 AM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:
> Right, but the messages often get sent anyway. So the evaluator who
> blocks the message as malicious impersonation is blocking incorrectly
> because the fail result is unreliable. If it only
Dne 21. 6. 2023 v 10:59 Alessandro Vesely napsal(a):
On Tue 20/Jun/2023 09:29:13 +0200 Wei Chuang wrote:
Our proposal would be for DMARCbis to maintain the default for SPF
and DKIM support, and to support senders that want to drop SPF as one
of their DMARC authentication methods to avoid the
Colleagues,
We looked at data covering a time period of several months and more than a
quarter of a trillion DMARC pass results to get a sense for the impact of
what a change to DKIM-only might mean for DMARC. Here's what we found.
- 3.65% of all DMARC passes recorded had only an aligned SPF
> I concur that this isn't really a problem for either working group to solve
> as part of a standard,
Well, the part that the working group needs to solve is whether the
challenges of getting DKIM right are such that we need to retain SPF
to fill that gap, or whether the issues with relying on
On Thu, Jun 22, 2023 at 6:32 AM Todd Herr wrote:
> Marty also has the right to engage a third party to send the mail (again,
> as conveyed by their employer), mail that Marty and others at Marty's
> company will create. The third party here is most commonly referred to, in
> my experience, as an
How about this!
p=none or quarantine trusts SPF and DKIM, but p=reject trusts DKIM only.
This option addresses Google's desire for a strict rule to protect the most
aggressively attacked domains, while leaving flexibility for those who want
it.
DF
On Thu, Jun 22, 2023, 9:55 AM Scott Kitterman
My conclusion (it won't surprise you to learn) from this thread is precisely
the opposite.
In theory, DKIM is enough for DMARC (this was always true), but in practice it
is not.
I don't think there's evidence of a systemic weakness in the protocol. We've
seen evidence of poor deployment of
It's not easy to set a DKIM key, I can agree with that. I do think,
Marty should have tested before sending, though.
None of this, however, solves the issue of SPF weakening the DMARC
standard. The weakness in SPF is not incidental, but systematic. That is
- independent of the numbers - the
On Thu, Jun 22, 2023 at 9:18 AM Sebastiaan de Vos wrote:
> In that case, if I understand correctly, Marty is sending his E-mail
> untested and unmonitored. Is that not Marty's problem, really? Where are we
> heading if we try to fix that problem?
>
You seem to be ascribing malice to Marty here
In that case, if I understand correctly, Marty is sending his E-mail
untested and unmonitored. Is that not Marty's problem, really? Where are
we heading if we try to fix that problem?
On 22.06.23 14:59, Douglas Foster wrote:
Right, but the messages often get sent anyway. So the evaluator who
Right, but the messages often get sent anyway. So the evaluator who
blocks the message as malicious impersonation is blocking incorrectly
because the fail result is unreliable. If it only affects nuisance
advertising, the error may not matter to the evaluator. But I think the
problem affects
If I don't know how to control the zone for the domain I want to send
from, I can't authenticate my mail from that domain. Isn't that part of
the purpose of DKIM in the first place?
On 21.06.23 15:36, Todd Herr wrote:
Maybe Marty knows who does control DNS, and Marty is good at cutting
and
In a perfect world, we would have a two-tailed test, where PASS really
means "no malicious impersonation" and "FAIL" really means "malicious
impersonation". Absent that ideal, we can try for a one-tailed test,
either
"FAIL" means "malicious interpretation" but "PASS" only means "uncertain",
or
On Wed 21/Jun/2023 23:24:57 +0200 John Levine wrote:
It appears that Alessandro Vesely said:
After sleeping on it, I think the new tag could also specify DKIM /and/ SPF,
besides or and one only, ...
I am reasonably sure that when DMARC was designed they considered that and
rejected it.
On Wed 21/Jun/2023 15:36:44 +0200 Todd Herr wrote:
On Wed, Jun 21, 2023 at 4:22 AM Alessandro Vesely wrote:
On Tue 20/Jun/2023 15:40:11 +0200 Todd Herr wrote:
I can't speak for Patrick, but I don't think he's necessarily thinking of
different encryption algorithms here.
Not all who wish
21 matches
Mail list logo
