On Sat, Feb 11, 2023 at 2:35 PM Michael Thomas <m...@mtcc.com> wrote:
> 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 > Yep; there's no "right" way. I've seen both kinds of architecture work, and A-R tries to anticipate all sorts of options (by not precluding any of them). > 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. > It's certainly possible to collect data that might correlate something like "Subject signed vs. not signed" with a spam score, and that could feed in to a best practices document. I don't know who might be up for investing the time into such a survey, however. OpenDKIM used to collect such summaries from volunteer participants; I can see if the data sitting around in those tables had enough information for such a survey, but it almost certainly won't be current data. -MSK
_______________________________________________ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
