What I am trying to accomplish is different than what can be accomplished with
the canned-modifications indicator.To explain, I need to digress into my
theory of operation for spam filters:
1) Source identification allows assignment of a Source reputation. Source
reputation is more important than content filtering, because hostile content
always comes from a source that should not be trusted. Content filtering
always produces false positives and false negatives, and the workarounds to
those errors are always dependent on source identification
2) Impersonation is always attractive to an attacker because it allows him to
exploit the reputation of the impersonated identity. Therefore impersonation
is an inherently untrusted activity.
3) Spam filtering will assign sources to three reputation groups: negative
reputation (rejected), neutral reputation (acceptance depends on content
filtering), and positive reputation (some or all content filtering bypassed.)
SPF and DMARC are designed to block impersonation, and mailing lists look like
impersonated traffic, so the message moves from neutral to negative reputation.
How to overcome that?
One solution is to use out-of-band information to justify overlooking the
negative clues, then implementing local policy based on that informatoin, so
that traffic is moved from negative reputation to positive reputation. ARC
and canned-modification tagging are approaches to providing in-message data
intended to support application of that local policy.But we have found no
way to ensure the out-of-band information flow needed to justify the local
policy, for all of the mediators that need that status. We have also
identified no method for the recipient to notify the mediator that the local
policy is established, although this could also be handed out-of-band.
However, these techniques have the benefit of depending on the mediator and the
recipient, and not on the sender.
A second solution depends on explicit sender authorization to eliminate the
apparent impersonation. This category encompasses conditional signatures,
ATSP, RHSWL, DKIM delegation, and SPF inclusion. These approaches require the
involvement of sender, list, and recipient. We have concluded that these
approaches are victims of unlikely participation by senders, and further
limited because the list does not know if a recipient will recognize the
sender's authorization.Finally, I observed that this solution cannot help
with the problem created by spam filter tagging prior to an auto-forward, so it
cannot solve the whole problem.
A third solution is to abandon DMARC and allow impersonation to be unrestricted.
I am suggesting a fourth approach. This one seeks to address the
impersonation problem by clearly identifying each part of the message to its
source, so that impersonation is not an issue, and each source's contribution
is evaluated based on that source's reputation and that source's content. The
goal is to move the imputed source reputation from negative to neutral, rather
than from negative to positive. If the source reputation can be defaulted to
neutral, the approach can be used by any mediator without prior registration
with recipients and without any prior authorization by senders.
But on continued reflection, I realize that this approach requires complete
isolation between the content added by a mediator and the content provided by
the originator. Any other changes to the original content could maliciously
alter the original intent of the author, and an automated spam filter has no
ability to identify changes of intent. So is there a group of mediators who
only require the ability to add a subject prefix, subject suffix, body header,
or body footer?
- The better spam filters offer URL rewrite, which alters original content.
The weaker spam filters may only use these four features, but they are the ones
that are least likely to add an exotic new feature like dual authorship
detection. So I reluctantly conclude that there is no significant opportunity
for using this approach on the "spam filter with auto-forward" problem.
- But is there is a group of mailing lists that only need these four
capabilities? I was hoping so.
DF
From: Alessandro Vesely
Sent: 9/5/20 5:36 AM
To: dmarc@ietf.org
Subject: Re: [dmarc-ietf] AutoForward problems - Change log benefits to mailing
lists
On Fri 04/Sep/2020 04:05:24 +0200 Douglas E. Foster wrote:
>
> Of the three types of content changes that I proposed, the easiest to specify
> and get implemented is the first type, where the mediator only adds content,
> adds a change log indicating the additions, and signs the result. I am
> hoping
> and assuming that if mailing lists have freedom to add their branding to the
> subject and body, most lists would not need to make more complex changes.
The change log must not be a generi
