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 <fenton(_at_)bluepopcorn(_dot_)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-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
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html