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-fcsr7(_at_)qmda(_dot_)emu(_dot_)st
<mailto:sx6un-fcsr7(_at_)qmda(_dot_)emu(_dot_)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