On Sun, Nov 13, 2016 at 9:39 PM, Mark Delany <sx6un-fc...@qmda.emu.st> wrote:
> Hi Murray. > Mark! > RFC6376 and even RFC4871, but now it's apparently happening > > I'd be interested to hear about the actual scenarios. Are the targeted > users somehow given an indication that the email verifies and it's > from a credible domain and yet it contains a malevolent payload? > As I understand the attack: Spammer tries to send spam to a victim. The MSA blocks this because it's spam. However, the spam filter is not applied to mail sent by the spammer to itself, because why would that be a problem? So the spammer sends itself a piece of spam, which the MSA dutifully signs. Then the spammer downloads that message and remails it using whatever envelope it likes. The signature will continue to validate, carrying the reputation of the signing domain through any whitelist or other system that says this signer tends to send good mail. > This sounds like some sort of quarantine system which only looks at > verification status. > Sort of, yeah. It's any receiver that gives preferential treatment to messages signed by particular domains. > It's too bad formal communication to the MUA was eliminated in > DKIM. The original hope was that after a decade or so, MUAs would have > evolved to participate and make some rendering indication in such > situations. After all, an unknown-to-the-MUA to:/cc: recipient or > domain in a verified email is highly actionable. > Which channel was eliminated? I think RFC7601 could help if that's what you're referring to. > Anyway, based on your draft I presume the desire is still to retain > the binary verification status as a strong dispositional attribute > that is handled by anything *but* the MUA? > Right, that seems to be the attack that needs addressing. > In the section that discusses the impact on forwarded and list email > you might want to highlight that the proposal could further reduce > email to a point-to-point protocol. In which case an alternative > long-term strategy might be simply to insist on strong SPF checks > rather than signatures. Or do SPF checks not help the scenario you're > addressing here? > SPF might indeed help for cases where there are no intermediate hops. Both good suggestions. Thanks! -MSK
_______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
