Re: [ietf-dkim] draft-kucherawy-dmarc-rcpts

["Murray S. Kucherawy" <[e-mail]>]

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 <[e-mail]> 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 <[e-mail]>
> 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