ietf-dkim
[Top] [All Lists]

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

2016-11-13 23:40:57
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 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