Yes, later in the thread we all agreed that "don't do this" is far better than any protocol solution.
On Mon, Nov 28, 2016, 11:30 Jim Fenton <fen...@bluepopcorn.net> wrote: > Waking up to this thread a little late... > > > On 11/14/16 7:38 AM, Michael Thomas wrote: > > On 11/13/2016 09:38 PM, Murray S. Kucherawy wrote: > > 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 a misconfiguration problem.It's a problem because it's > $spam/$malware/$bad regardless of who the recipient is. > > The rule is: if you think it's bad, don't sign it. If you sign it, you own > it. > > So to put Mike's comment a different way: Why is the MSA signing something > that isn't subject to scrutiny? If the message is just going back to the > sender, it doesn't need a signature. It sounds like this problem could be > addressed by putting signing after the outgoing spam check, with no change > to the protocol. > > > -Jim > _______________________________________________ > NOTE WELL: This list operates according to > http://mipassoc.org/dkim/ietf-list-rules.html >
_______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
