On 2/10/23 9:23 PM, Murray S. Kucherawy wrote:
On Fri, Feb 10, 2023 at 8:09 PM Michael Thomas <m...@mtcc.com> wrote:
I've always thought that the likelihood of a protocol level
solution for
this issue is pretty close to zero if not zero. The various proposed
solutions in the problem draft haven't given me any reason to
dissuade
me of that notion.
That said, I think that we might be able to catalog some clues that
something is suspicious which taken with many other clues can be
used to
by a receiver to make an ultimate decision of spamminess. A good
example
is the unsigned To: and Subject: lines. Even if it's strictly
allowed by
the spec, that doesn't mean it's not suspect. It could be really
useful
to collect this clues as input signals to a larger preponderance of
evidence.
Authentication-Results already noted the idea that a signature, even a
valid one, might still be considered not acceptable to the verifier
and reported differently for one reason or another. An unsigned
Subject was the classic example.
Dealing with this in A-R nicely removes it from being dealt with at
the protocol level, where I would argue this sort of logic doesn't belong.
It's never been especially clear to me whether deployments do their
filtering up front, ie at the MX, or farther down the line. There are
certainly advantages to do it right at the MX with less burden on using
AR to signal all of what the filters consider the interesting bits that
standard A-R might not support. But there may be good architectural
reasons to postpone the filtering to later in the pipeline even if means
that you're holding the spam longer before discarding it.
But regardless of A-R just cataloging what those interesting bits might
be could be useful in documenting how they can be used to detect replay
spam. Also: I think there is more to it than whether the signature
verifies, per say. The signature actually verifies, but it's the
scrutiny that matters. Saying it doesn't verify essentially decouples
from any reputation of the domain. But that is hardly the only way to
look at it. Saying it verifies, but has problems is another way to view
it. For wetware investigators an A-R that did that could be really
confusing.
Mike
_______________________________________________
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim
