Jan Dušátko writes:
> Scott, Barry,
> as far as I understand, SPF are historic technology, but still have a
> reason why to use it. In my opinion (and concerns), it is also necessary
> to be aware of the extension of the individual protection methods
> provided by senders (amount of domains).
A small follow up about my DMARC view:
> On Jun 30, 2023, at 4:02 PM, Hector Santos
> wrote:
>
> Overall, imo, it is never a good idea to exerted changes on domains with bis
> specs, requiring them to change their current DMARC record to reinforce the
> security level they want using SPF in
> On Jun 30, 2023, at 3:32 PM, Murray S. Kucherawy wrote:
>
> On Fri, Jun 30, 2023 at 12:21 AM Jan Dušátko
> mailto:40dusatko@dmarc.ietf.org>>
> wrote:
>> Scott, Barry,
>> as far as I understand, SPF are historic technology,
>
> Not in any official capacity. RFC 7208 is a Proposed
On Fri, Jun 30, 2023 at 12:21 AM Jan Dušátko wrote:
> Scott, Barry,
> as far as I understand, SPF are historic technology,
>
Not in any official capacity. RFC 7208 is a Proposed Standard. In fact,
in IETF terms, it enjoys higher status than DMARC does right now.
The status of these protocols
On Fri 30/Jun/2023 04:07:46 +0200 Tero Kivinen wrote:
Alessandro Vesely writes:
[...]
ESPs can provide include files for those who wish otherwise.
I know that some companies in finland has included the iki.fi
IP-addresses ranges to their SPF records, because they had several
complains
Scott, Barry,
as far as I understand, SPF are historic technology, but still have a
reason why to use it. In my opinion (and concerns), it is also necessary
to be aware of the extension of the individual protection methods
provided by senders (amount of domains). This is not a deep analysis.
Alessandro Vesely writes:
> On Mon 26/Jun/2023 19:32:53 +0200 Douglas Foster wrote:
> > DKIM+SPF says "our domain, including subdomains covered by this policy,
> > will never use an ESP". (Since most ESP messages pass SPF based on the ESP
> > domain)
That is incorrect. It would also mean we will
Chair speaking and agreeing. While I do not think it's out of scope
to think about how DKIM replay attacks affect DMARC, I think it is out
of scope to design DMARC to address DKIM replay attacks. These two
things are very close to each other, and we're going to have to be
careful about it. But
On Thu, Jun 29, 2023 at 4:18 AM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:
> But I don't have a solution for ESP messages that use DKIM to authorize
> the From, but use their own domain for SPF Pas on Mail From. That
> requires tying the signature to the server and/or Mail
But I don't have a solution for ESP messages that use DKIM to authorize the
From, but use their own domain for SPF Pas on Mail From. That requires
tying the signature to the server and/or Mail From domain using a signature
token
On Thu, Jun 29, 2023, 1:25 AM Murray S. Kucherawy
wrote:
> On
On Wed, Jun 28, 2023 at 5:50 PM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:
> We are talking about SPF AND DKIM because of the problems with DKIM
> replay. Can someone summarize the state of the DKIM update options that
> have been ruled in or ruled out?
>
I'll clarify how I
We are talking about SPF AND DKIM because of the problems with DKIM
replay. Can someone summarize the state of the DKIM update options that
have been ruled in or ruled out?
We have the DARA proposal from Google, which is related to signature
replay, but focused on ARC. I am guessing that it
I think it's quite relevant.
The assumption that this is based on is there's a need to specify because SPF
data is not reliable enough for everyone. If that premise is correct (I don't
agree with it, but it's a separate issue), then I think telling people that
they should use DKIM because it
I think DKIM replay is largely irrelevant to this discussion (about
the sender specifying which authentication to use), because if that's
your biggest concern with respect to DMARC, then "SPF only" is the
answer. "SPF *and* DKIM" is not any better than that.
> You seem to imply that
Thank you for your analysis. However, it doesn't touch on DKIM replay.
I know this topic belongs to the other list. Let me briefly recall it, if this
doesn't take too many cycles from core matters: It occurs when a signed
message is replayed by unauthorized hosts to recipients which were
Doug, this is Wildcat! SMTP - one of the oldest SMPT packages around. Summary
here:
Without some signal at wcSMTP about DMARC, SPF will most likely remain a hard
rejection at WCSAP/SMTP (at RCPT state) before DMARC at DATA
Background:
Since 2003, out of the box, Wildcat! SMTP with add-on
+1
> On Jun 27, 2023, at 11:06 AM, Tobias Herkula
> wrote:
>
> Signing That, nothing to add.
>
> -Original Message-
> From: dmarc On Behalf Of Barry Leiba
> Sent: Tuesday, June 27, 2023 4:24 PM
> To: Alessandro Vesely
> Cc: dmarc@ietf.org
> Subj
Since 2003, here is my out of the box, Wildcat! SMTP with wcSAP and wcDKIM
add-on support, mail flow:
(Note: for the record, email is a small Part, but a supportive part for many
customer operations)
At SMTP, starting with connection
1) If Enabled, Check for DNS-RBL IP check, respond at step
Signing That, nothing to add.
-Original Message-
From: dmarc On Behalf Of Barry Leiba
Sent: Tuesday, June 27, 2023 4:24 PM
To: Alessandro Vesely
Cc: dmarc@ietf.org
Subject: Re: [dmarc-ietf] easier DKIM, DMARC2 & SPF Dependency Removal
I don't understand how most of your message
I don't understand how most of your message fits into this discussion:
you're comparing SPF's policy points with DMARC policy. we're talking
about SPF as an authentication mechanism together with DKIM (not
DMARC) as an authentication mechanism... and then using those
authentication results in
Ale, here is an attempt at a formal model. Application to the current
question is at the very end.
Any test (DKIM, SPF, ARC) has these result possibilities:
- Pass
- No data or uncertain result
- Fail
The test results are imperfect, so we have to consider these probabilities
On Mon 26/Jun/2023 20:13:53 +0200 Barry Leiba wrote:
I'm saying I don't want "and" to be an option, because I think it's
damaging to DMARC. There is no reason anyone should ever want to say
that, and providing the option asks for misconfigurations because
people think it's somehow "more
On Mon 26/Jun/2023 19:32:53 +0200 Douglas Foster wrote:
DKIM+SPF says "our domain, including subdomains covered by this policy,
will never use an ESP". (Since most ESP messages pass SPF based on the ESP
domain)
ESPs can provide include files for those who wish otherwise.
Best
Ale
--
It appears that Barry Leiba said:
>I'm saying I don't want "and" to be an option, because I think it's
>damaging to DMARC. There is no reason anyone should ever want to say
>that, and providing the option asks for misconfigurations because
>people think it's somehow "more secure". It's not
I'm saying I don't want "and" to be an option, because I think it's
damaging to DMARC. There is no reason anyone should ever want to say
that, and providing the option asks for misconfigurations because
people think it's somehow "more secure". It's not more secure. It
would be very bad for
DKIM+SPF says "our domain, including subdomains covered by this policy,
will never use an ESP". (Since most ESP messages pass SPF based on the ESP
domain)
This seems unlikely to be a reliable assertion, so the effect on
disposition is likely to be strongly negative, even without the effect on
On Mon 26/Jun/2023 14:51:34 +0200 Barry Leiba wrote:
If we consider this sort of thing, I want to push to keep one thing
off the table:
Saying that SPF *and* DKIM *both* have to pass is a VERY BAD approach.
Let's please just remove that from consideration. It has not been in
DMARC up to this
Just to clarify something:
On Mon, Jun 26, 2023 at 5:52 AM Barry Leiba wrote:
> I can accept some mechanism for the sender to say "SPF only", "DKIM
> only", or "either SPF or DKIM". I cannot except a version of DMARC
> where *both* must pass.
>
I think the proposal before us is to allow the
Barry,
I understand your concerns. Use SPF *and* DKIM could cause issues for
any kind of mail conferencing and forwarding. Situation are quite
complicated right now. Use of these method, as well as combination of
these methods, could lower deliverability due protection mechanism
contrary of
On June 26, 2023 12:51:06 PM UTC, florian.kun...@telekom.de wrote:
>
>> In theory, DKIM is enough for DMARC (this was always true), but in practice
>> it
>> is not.
>
>May be you can afford to use SPF, DKIM, DMARC in pure theory for your day job,
>but people here expect to apply it to solve
> In theory, DKIM is enough for DMARC (this was always true), but in practice it
> is not.
May be you can afford to use SPF, DKIM, DMARC in pure theory for your day job,
but people here expect to apply it to solve real problems with real email in
real life.
*SCNR* ... do not take that
If we consider this sort of thing, I want to push to keep one thing
off the table:
Saying that SPF *and* DKIM *both* have to pass is a VERY BAD approach.
Let's please just remove that from consideration. It has not been in
DMARC up to this point, and it would be really bad to add it.
Hector,
I think Levin's original suggestion to use the setting option like SPF
AND DKIM, SPF OR DKIM, SPF only, DKIM only is excellent. It could solve
a lot of problems. System administrators know best how to set up their
system and for what purposes they need that setting. I can imagine a
> If the DMARC spec makes that clear, I think we win. And recipients
> can still do what they want: if DMARCbis goes out with "use DKIM only"
> and a recipient wants to use SPF anyway, they can do that... just as a
> recipient that decides to use best-guess-SPF in the absence of actual
> SPF
Alessandro, I believe we are on the same wave. I support the DMARC1 tag
extension `auth=‘ idea. Do you have any suggestions for the text?
Technically we don’t need DMARC1-Bis. That document can move forward as is
and a new draft proposal I-D called “DMARC1-EXTENSION-AUTH” can be written
On Fri 23/Jun/2023 20:13:27 +0200 Hector Santos wrote:
On Jun 23, 2023, at 12:52 PM, John R Levine wrote:
On Thu, 22 Jun 2023, Emanuel Schorsch wrote:
I agree with John's point that dkim+spf doesn't make sense in the context
of strict DMARC enforcement (I think it provides value for p=none
On Fri 23/Jun/2023 22:56:59 +0200 Barry Leiba wrote:
If the DMARC spec makes that clear, I think we win. And recipients
can still do what they want: if DMARCbis goes out with "use DKIM only"
and a recipient wants to use SPF anyway, they can do that... just as a
recipient that decides to use
John, you have a solid theoretical argument, but mail senders are
pragmatists, not theorists.
There are still filtering products in use that evaluate SPF but not DMARC.
In the products that I have seen up close, they only act on SPF FAIL, and
ignore SPF NONE. But without certainty about how
> > Presumably, a sender who uses DMARC might publish SPF to cover
> > recipients who don't use DMARC, but would prefer that recipients use
> > DMARC (authenticated by DKIM only).
>
> I get that, but that's still simultaneously saying "use SPF to
> authenticate me" and "don't use SPF to
On Jun 23, 2023, at 1:54 PM, John R Levine wrote:
>
>> My understanding is that if `auth=dkim` then SPF would be ignored from the
>> perspective of DMARC. So if a receiver sees DKIM is not DMARC aligned and
>> only SPF is DMARC aligned then it would still be treated as a DMARC fail.
>
> That's
Presumably, a sender who uses DMARC might publish SPF to cover
recipients who don't use DMARC, but would prefer that recipients use
DMARC (authenticated by DKIM only).
I get that, but that's still simultaneously saying "use SPF to
authenticate me" and "don't use SPF to authenticate me." If
Presumably, a sender who uses DMARC might publish SPF to cover
recipients who don't use DMARC, but would prefer that recipients use
DMARC (authenticated by DKIM only).
Barry
On Fri, Jun 23, 2023 at 1:54 PM John R Levine wrote:
>
> > My understanding is that if `auth=dkim` then SPF would be
> On Jun 23, 2023, at 12:52 PM, John R Levine wrote:
>
> On Thu, 22 Jun 2023, Emanuel Schorsch wrote:
>> I agree with John's point that dkim+spf doesn't make sense in the context
>> of strict DMARC enforcement (I think it provides value for p=none domains
>
> Since the aggregate reports tell
>
> > It would be a way for senders to say "yes I checked that all my DKIM
> > signatures are working and aligned, I don't need you to look at SPF and
> > don't want to have the risk of SPF Upgrades.
>
> So why do you publish an SPF record? Presumably so someone will accept
> your mail who
My understanding is that if `auth=dkim` then SPF would be ignored from the
perspective of DMARC. So if a receiver sees DKIM is not DMARC aligned and
only SPF is DMARC aligned then it would still be treated as a DMARC fail.
That's my understanding.
It would be a way for senders to say "yes I
>
> > confused users misusing that option. I would support allowing the
> following
> > options for the auth tag:
> > "auth=dkim|spf (default value: same as current state), auth=dkim,
> auth=spf"
>
> The idea is that auth=dkim means you'd publish SPF records but hope people
> will ignore them,
Levine makes a good point. A less complex option would be:
auth=dkim # apply dkim only, ignore spf, dkim failure is
dmarc=fail
auth=spf# apply spf only, ignore dkim, spf failure is
dmarc=fail
the default auth=dkim,spf SHOULD NOT be explicitly be required. It
adds no
On Thu, 22 Jun 2023, Emanuel Schorsch wrote:
I agree with John's point that dkim+spf doesn't make sense in the context
of strict DMARC enforcement (I think it provides value for p=none domains
Since the aggregate reports tell you what authentication worked, I don't
even see that as a benefit.
Is there a use case for "SPF only"?
1) "We use ESPs but we never sign, so don't expect one."
2) "We have so many problems with DKIM reply that you should ignore
signatures even if they verify."
3) "We never sign, so if you see a failed signature, it is a fraud attempt."
None of these seem
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
> 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
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
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 to have their email DKIM signed
On Tue 20/Jun/2023 15:40:11 +0200 Todd Herr wrote:
On Mon, Jun 19, 2023 at 8:25 PM John R Levine wrote:
On Mon, 19 Jun 2023, Patrick Ben Koetter wrote:
I suggest that we do not only drop SPF, but also come up with better ways
(simplification, tools, exchange formats) to implement DKIM in
On Mon, Jun 19, 2023 at 8:25 PM John R Levine wrote:
> On Mon, 19 Jun 2023, Patrick Ben Koetter wrote:
> > I suggest that we do not only drop SPF, but also come up with better ways
> > (simplification, tools, exchange formats) to implement DKIM in order to
> allow
> > for a smooth transition.
>
John R Levine skrev den 2023-06-20 02:25:
On Mon, 19 Jun 2023, Patrick Ben Koetter wrote:
I suggest that we do not only drop SPF, but also come up with better
ways
(simplification, tools, exchange formats) to implement DKIM in order
to allow
for a smooth transition.
I'm scratching my head
On Mon, 19 Jun 2023, Patrick Ben Koetter wrote:
I suggest that we do not only drop SPF, but also come up with better ways
(simplification, tools, exchange formats) to implement DKIM in order to allow
for a smooth transition.
I'm scratching my head here. On my system I publish and rotate DKIM
71 matches
Mail list logo
