Re: [dmarc-ietf] AutoForward problems - Change log benefits to mailing lists

2020-09-07 Thread John Levine
In article ,
Murray S. Kucherawy   wrote:
>Another way to look at this: DKIM (and I believe SPF) only really tells you
>something interesting when it passes.  That means (for DKIM) the content
>was unmodified, and the signature is validated by a key that is verifiably
>present in some domain's DNS data. ...

Yes, exactly. 

With SPF, no sensible person rejects mail on SPF -ALL other than the
special case of plain -ALL that means it sends no mail whatsoever.
Other than that, neither DKIM nor SPF can distinguish between "this is
fake" and "this was sent by a route that SPF/DKIM can't describe."

-- 
Regards,
John Levine, jo...@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc


Re: [dmarc-ietf] AutoForward problems - Change log benefits to mailing lists

2020-09-07 Thread Murray S. Kucherawy
Historically, I've found that a negative source reputation is easy to
dodge.  It's trivial to come from an unknown IP address or register a new
domain name, so an actor with a negative reputation can trivially move to a
neutral one.  Thus, a receiver/verifier seeking to make a meaningful
judgement can only really focus on positive reputations when making
meaningful filtering decisions; everyone else is basically the same in
terms of value.

Another way to look at this: DKIM (and I believe SPF) only really tells you
something interesting when it passes.  That means (for DKIM) the content
was unmodified, and the signature is validated by a key that is verifiably
present in some domain's DNS data.  That means the domain announcing that
key implicitly "takes some responsibility" for the content just verified.
So the only variable here is the value, or reputation, of the verified name.

All of this is orthogonal to DMARC though, which doesn't care about
reputation.  It only cares about alignment, and specifically alignment that
is under complete control of the sender.

-MSK

On Sat, Sep 5, 2020 at 10:55 AM Douglas E. Foster  wrote:

> 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, bo