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 forwarding/conferencing principle. But the goal of
protection methods is to ensure the authenticity of the e-mail source.
This means that the sender is responsible for protecting the
domain/brand. And this ultimately requires that the owner has methods
that are able to provide enough data to ensure its full verifiability.
Whether these methods are properly implemented is the responsibility of
the sender's system administrator, whether they are checked upon receipt
is the responsibility of the recipient's system administrator. Some of
organization checks SPF only, some DKIM only, some SFP then DKIM, some
SPF and DKIM (but logic of that use OR), in few tenth of precents also
followed by DMARC. And some of organizations still does not check anything.
Please, can you consider the possibility that the owner of several
hundred or even several thousand domains is trying to protect his
business and does not have the possibility to provide verifiable
authenticity? If he understands the situation with their impacts, the
possibility of using SPF and DKIM is a method to ensure adequate
protection. By this I mean protection from where the mail can be sent
and at the same time whether it will be signed. Despite the problems
with mail conferences and forwarding, this may be an acceptable way to
solve specific problems. In other cases, how we can mitigate as much of
situation mentioned above?
If the possibility of using only DKIM, I see the risk of how the DMARC
policy will be evaluated. If the error state of the policy is ensured
for specific cases (non-existent public key, non-existent subdomain,
non-existing signature), I have no problem with the approach. All that
is needed to ensure is a precise procedure, what conditions the
implementation must meet. And we need method, how we can enforce use of
DKIM, else we will be in situation without any protection. This is a
reason, why I concern about protection.
Regards
Jan
Dne 26. 6. 2023 v 14:51 Barry Leiba napsal(a):
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.
Deliverability would be worse than ever because we would get the worst
of both: fragility of SPF when messages are relayed/forwarded, *and*
problems caused by misconfigurations in *either* SPF *or* DKIM.
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.
Barry, as participant
On Sat, Jun 24, 2023 at 3:01 PM Jan Dušátko
<[email protected]> wrote:
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
great many reasons for and against those combinations. What seems to me
to be important here is that DMARC is able to use policies to solve not
only common but also error states. In that case, it is able to
successfully solve the problems caused by the attackers.
Jan
Dne 23. 6. 2023 v 19:23 Hector Santos napsal(a):
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 additional security value. I would like to note that some DNS
Zone Managers with DMARC record support will add the complete tags
available for the protocol with the default conditions making the
record look more complex than it really it.
Other system integration options would (forgive me for I have sinned):
atps=1 # we support ATPS protocol for 3rd party signer.
rewrite=1 # we are perfectly fine with Author Rewrite
--
HLS
On 6/22/2023 10:18 PM, John Levine wrote:
It appears that Emil Gustafsson <[email protected]> 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 they desire).
I really don't understand what problem this solves. More likely people
will see blog posts telling them auth=dkim+spf is "more secure",
they'll add that without understanding what it means, and all that
will happen is that more of their legit mail will disappear.
If you're worried about DKIM replay attacks, let's fix that rather
than trying to use SPF, which as we know has all sorts of problems of
its own, as a band-aid.
R's,
John
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
