On Wed 15/Mar/2023 07:55:15 +0100 Wei Chuang wrote:
On Tue, Mar 14, 2023 at 9:11 AM Scott Kitterman <[email protected]> wrote:
For the replay resistance part of the question, I think it would make
sense to wait and see how the DKIM working group addresses the problem for
DKIM generally and then assess how their solution impacts ARC and how it
addresses the issue for ARC.
I think the question of spamminess is orthogonal to the authentication
questions that ARC attempts to answer. It's subjective, so I don't think
it can really play into ARC.
Additionally, if the intermediary thinks a message is bad (spam), then the
solution is to not send the message onward and try to make it someone
else's problem.
Likely the issue is that the intermediary doesn't think of the specific
message as being spam, yet is worried about the possibility of
authenticating spam so drops ARC for some scenarios. The receiver still
could benefit from seeing the Authentication-Results of the intermediary.
In other scenarios, the ARC headers are intentionally broken by a spammer.
Should non-malicious forwarders of those messages still generate ARC
headers? Keep in mind, the forwarder again might not realize the message
is spammy
I think running at least a minimal, conservative filter so as to drop blatant
spam, phishing and viruses is de rigueur. Otherwise you're akin to an open relay.
That said, ARC is still preferable in stead of DKIM as it doesn't involve
/claiming some responsibility for the message/.
Best
Ale
--
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
