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

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sun, 13 Nov 2016 15:50:05 +0900

I've posted a draft that attempts to address an attack that's begun to
appear with DKIM.  Interestingly, we called it out as a possible attack in
RFC6376 and even RFC4871, but now it's apparently happening and being
annoying enough that people (I believe from the MAAWG community) are asking
if there's a protocol solution that's possible.

https://datatracker.ietf.org/doc/draft-kucherawy-dkim-rcpts/

Comments welcome.

-MSK
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: "Mark Delany" <[email-masked]>
Date: 13 Nov 2016 12:39:42 +0000

Hi Murray.

> 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?

This sounds like some sort of quarantine system which only looks at
verification status.

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.

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?

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?

Mark.

---

From: Martijn Grooten <[email-masked]>
Date: Sun, 13 Nov 2016 20:30:20 +0000

> https://datatracker.ietf.org/doc/draft-kucherawy-dkim-rcpts/

Thanks for this.

It isn't very clear to me how this proposal deals with receipients at
different domains, including but not limited to blind carbon copies. I
may be showing my ignorance of how DKIM signing engines work under the
hood, but unless the email is not signed until a copy has been created
for each receiving domain, my understanding of the draft is that this
would result in every receiving domain receiving an invalid copy of the
email.

I also think it wouldn't hurt to make point 2 of section 4.1 a bit more
explicit: should the addresses be converted to lowercase? To ASCII?

Finally, is there a reason the proposal doesn't sign the canonicalized
list of recipients separately and add this signature as a separate DKIM
tag? This could allow for a more smooth transition period.

One could even sign each recipient individually and add a list of
signatures to a separate DKIM header. This would allow the verifier to
check each recipient individually, which should be doable if their
number isn't too big and does not require knowledge of which signature
links to which recipient.

Martijn.

---

From: Scott Kitterman <[email-masked]>
Date: Sun, 13 Nov 2016 15:41:09 -0500

>https://datatracker.ietf.org/doc/draft-kucherawy-dkim-rcpts/

Wouldn't a DMARC option to allow senders to specify only messages that pass verification and alignment for BOTH SPF and DMARC accomplish the same result with less complexity and without the layering violation inherent in this proposal?

DMARC seems to be the policy engine of choice in the community (for better or for worse).  I think addressing this at the policy level makes more sense than changing the semantics of DKIM signatures after almost a decade of deployment.

Scott K

P.S. With my Debian OpenDKIM maintainer hat on, I'm not immediately convinced I'd want to enable this feature.  I don't know if other distro maintainers are on this list or not, but that's one opinion.  It's not guaranteed to be widely deployed.
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: [email-masked]
Date: Sun, 13 Nov 2016 15:40:59 -0800 (PST)

> 1. This standard is not backward compatible with existing DKIM
> implementations. It makes it useless. In addition, in it's current form
> it can not be implemented in most MTAs (see below)

It wouldn't work at all in our MTA without modifications because our general
filter interface currently receives recipient addresses after some processing
has been performed. We could add an option to change that fairly easily, but as
you note, that doesn't address all the issues.

> 2. This standard mixes transport standards (SMTP) and message standard.
> There are multiple issues as a result of this:

> 2.1 Same message may have multiple recipients on different MTAs while
> each MTA only sees it's own recipients. So, destination MTA can not
> verify signature, because it doesn't know all recipients. This can be
> fixed if message to every destination is  signed independently, but it
> breaks existing mail flows, because in most cases message is signed
> before placing to MTA queue.

We have sufficient flexibility in this regard to sign late (and as noted
above, verify early), and we can split by destination before signing
each variant separately.

What would be much more difficult is detecting this usage and turning off
splitting where feasible to avoid breaking the signature. That would be very
difficult.

The bottom line is that at best this will be very fragile, at worst it will
fail a significant percentage of the time.

> 2.2 Recieving MTA may e.g. limit the number of recipients and single
> message may be sent to different final recipients on the same MTA in
> multiple session as few different messages, each message with partial
> list of recipients.

Actually, this quickly turns into a hairball. The minute the receiving
system starts 4yz'ing some recipients the precomputed signature is going
to be rendered invalid and will have to be recomputed.

And how does the receiving MTA know when do this? It gets no indication
that it's dealing with this particular DKIM variant until after recipients
are processed. So it's only choice would be to do it unconditionally, or
to try and keep track of senders who use this feature.

Yuck.

> Actually same message to same destination may be
> sent to different MTAs (e.g. different MXs with same weight).
> 2.3 Canonization must be better defined. It's usual for MTA to e.g.
> lowercase the domain of recipient.

Our default is to leave the case of addresses alone by default, but sites often
do configure things to "right case" their business name. That said, Early
validation would avoid such issues for us. I think.

> All problems except 2.1 may be fixed by adding additional header, like e.g.
> DKIM-Transport-recipients
> which contains salted hashes (with some random salt) of all recipient
> addresses, and require this header to be added to DKIM signature and
> existence for every recipient's address' hash to be checked in this
> header. It is compatible with any current DKIM implementation.

If you're talking about hashing all recipients together, then I don't see this
solving all the problems except 2.1.

And if you're talking about hashing them separately, then why would you
insist that they all be present?

> 2.1 can also be solved in this case, but it disclosures BCCs of the
> message (even if this header is removed before delivery to mailbox)

Prior to delivery the bcc's are disclosed by being present in the envelope. So
as long as the sender adopts the approach of splitting by destination before
signing, only including the recipients for a given copy in the signature, and
the receiver removes the field prior to final delivery, I think it might
work.

But limiting the number of recipients to 1 when this extension is used would be
a much simpler approach. Of course there's some overhead involved in doing
this, but given the idiotically limited spam report mechanisms in place at some
sites single copy may be a requirement already.

> All problems may be solved by using asymmetric encryption instead of
> hashing, e.g. require domains with support for this standard to publish
> some public key (or to use special DKIM selector) via DNS record and
> encrypt recipient's addresses in the additional header with public key
> and only sign recipients for systems with this key published.

Yes, and that's really cute. Considerable overhead though.

> P.S. I just did a quick look into standard, sorry if I missed or
> misunderstood something.

So did I, and so do I.

Finally, my biggest concern here is that this, like most proposals that
involve complex linkages between the header and envelope, is complex
and loaded with pitfalls. (Just look at these two messages...) And at least
some of this spills over to both implementations and operational policy.

Can we really expect people to get this right?

				Ned

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 14 Nov 2016 14:38:30 +0900

> Hi Murray.

Mark!

> 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

Sort of, yeah.  It's any receiver that gives preferential treatment to
messages signed by particular domains.

> 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.

> that is handled by anything *but* the MUA?

Right, that seems to be the attack that needs addressing.

> rather than signatures. Or do SPF checks not help the scenario you're

SPF might indeed help for cases where there are no intermediate hops.

Both good suggestions.  Thanks!

-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 14 Nov 2016 14:48:01 +0900

On Mon, Nov 14, 2016 at 5:30 AM, Martijn Grooten <[email-masked]

> would result in every receiving domain receiving an invalid copy of the

Yes, if you have three recipients going to distinct MXes, and you want this
to work, you need to sign each copy individually.  You need to anticipate
how the message is likely to arrive, basically

> explicit: should the addresses be converted to lowercase? To ASCII?

In fact that's woefully underspecified and I show some ignorance, but
fortunately I have local help!  We've been discussing it in the hallway
track at IETF 97 in Seoul and some of the suggestions I've received are:

- just do a bytewise lexical sort, and don't try to interpret the addresses
at all
- apply NFKC to all of them before comparing
- other suggestions are imminent

> tag? This could allow for a more smooth transition period.

Now that's an interesting idea.

> links to which recipient.

I think that adds additional complexity beyond your previous suggestion and
I'm not sure what the incremental gain is.

-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 14 Nov 2016 14:50:01 +0900

On Mon, Nov 14, 2016 at 5:41 AM, Scott Kitterman <[email-masked]>
wrote:

> Wouldn't a DMARC option to allow senders to specify only messages that
> pass verification and alignment for BOTH SPF and DMARC accomplish the same
> result with less complexity and without the layering violation inherent in
> this proposal?
>

Doesn't that presuppose point-to-point handling?  The proposal here doesn't.

> DMARC seems to be the policy engine of choice in the community (for better
> or for worse).  I think addressing this at the policy level makes more
> sense than changing the semantics of DKIM signatures after almost a decade
> of deployment.
>

As the problem was presented to me, I haven't heard that DMARC is
specifically involved here.  It might be (maybe even "probably" is apt),
but I haven't heard that, so I limited this idea to just the DKIM signing
and verifying components of the system.

> P.S. With my Debian OpenDKIM maintainer hat on, I'm not immediately
> convinced I'd want to enable this feature.  I don't know if other distro
> maintainers are on this list or not, but that's one opinion.  It's not
> guaranteed to be widely deployed.
>

Why is this a distribution issue?

-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 14 Nov 2016 14:57:22 +0900

On Mon, Nov 14, 2016 at 6:01 AM, Vladimir Dubrovin <[email-masked]>
wrote:

> implementations. It makes it useless. In addition, in it's current form it
> can not be implemented in most MTAs (see below)
> 2.1 Same message may have multiple recipients on different MTAs while each
> MTA only sees it's own recipients. So, destination MTA can not verify
> signature, because it doesn't know all recipients. This can be fixed if
> message to every destination is  signed independently, but it breaks
> existing mail flows, because in most cases message is signed before placing
> to MTA queue.
> multiple session as few different messages, each message with partial list
> of recipients. Actually same message to same destination may be sent to
> different MTAs (e.g. different MXs with same weight).
>

Yes the current text in the document already calls all of those issues out.

> lowercase the domain of recipient.

That's a good point.

> existence for every recipient's address' hash to be checked in this header.
> It is compatible with any current DKIM implementation.
>
2.1 can also be solved in this case, but it disclosures BCCs of the message
> (even if this header is removed before delivery to mailbox)
>

Also an interesting idea.

> encrypt recipient's addresses in the additional header with public key and
> only sign recipients for systems with this key published.
>

If you do asymmetric encryption, with or without a distinct selector,
aren't you basically doing the same thing I'm proposing, other than where
it gets recorded in the message?

-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 14 Nov 2016 15:04:57 +0900

> validation would avoid such issues for us. I think.

Long ago some MTAs use to mess with the case of the domain names in the
envelope.  Assuming some of them are still out there, wouldn't we want to
fold everything to lowercase (or uppercase; pick one) before doing the sort?

> insist that they all be present?

I think he's trying to avoid being clobbered by an envelope that gets split
downstream.  If you as a verifier have the full original recipient set,
then all you care about is that your recipient set is a subset of the
original set.

> sites single copy may be a requirement already.

It's also the most common use case in threat space, as I understand it.

> some of this spills over to both implementations and operational policy.

Indeed; I don't think that's avoidable if we want to try to tackle this
problem versus punting it back up to layers 8 and 9.  But maybe that's the
best thing one can do.

I wonder that every time I write a draft anymore.  :-)

-MSK

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 14 Nov 2016 02:37:30 -0500

>Doesn't that presuppose point-to-point handling?  The proposal here

Your proposal breaks all non-point-to-point handling, if I understand it correctly, so whether you make DKIM signatures non-forwardable or do it in DMARC policy, it's the same end result.
>and verifying components of the system.

I think your pushing a substantial change to DKIM and to the extent this is a reasonable problem to solve, DKIM isn't the right layer in the email authentication stack to do it.
>Why is this a distribution issue?

Because so far this looks like a source of interoperability problems and bug report headaches I could do without.

I think the solution to "I have a problem that results when I sign spam" is "don't do that", not the entire community turns on its head to work around someone's local configuration problems.

Scott K

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 14 Nov 2016 17:34:19 +0900

On Mon, Nov 14, 2016 at 4:37 PM, Scott Kitterman <[email-masked]>
wrote:

> Your proposal breaks all non-point-to-point handling, if I understand it
> correctly, so whether you make DKIM signatures non-forwardable or do it in
> DMARC policy, it's the same end result.
>

How does it break all non-point-to-point handling?  It does break if the
envelope has to change, but that's not what I think of when you say
"point-to-point"; it makes me think of mail from A to C that happens to
transit B, which should survive just fine.

> I think your pushing a substantial change to DKIM and to the extent this
> is a reasonable problem to solve, DKIM isn't the right layer in the email
> authentication stack to do it.
>

Ah, yes, that's a plausible argument.

> I think the solution to "I have a problem that results when I sign spam"
> is "don't do that", not the entire community turns on its head to work
> around someone's local configuration problems.
>

Yes, I agree that's the preferable solution.  It sounds as if there are
some operators (well, at least one, I think) that are having a problem for
which "don't do that" is an expensive solution, and a question has been
posed about the possible existence of an easy, incremental protocol
solution for it.  It's fine if the answer is "no", but I'd like to have the
discussion without prematurely slamming any doors.

-MSK

---

From: Martijn Grooten <[email-masked]>
Date: Mon, 14 Nov 2016 08:53:32 +0000

On Mon, Nov 14, 2016 at 02:48:01PM +0900, Murray S. Kucherawy wrote:
> On Mon, Nov 14, 2016 at 5:30 AM, Martijn Grooten <[email-masked]>
> wrote:
> 
> Yes, if you have three recipients going to distinct MXes, and you want this to
> work, you need to sign each copy individually.  You need to anticipate how the
> message is likely to arrive, basically

This sounds like something that could easily go wrong, unless signing
agents take a very cautious approach and create individual copies for
each recipient domain. And even then, as the draft already mentions in
section 5, it could go wrong if the verifier doesn't get the complete
list of recipients.

> Now that's an interesting idea.

Other than that it makes the proposal backwards-compatible, it also
gives some insight in possible replay attacks against DKIM. And it
allows a spam filter that uses DKIM to make more granular decisions,
e.g. "this looks like a replay attack, but the sender is a known list
server, so it's probably okay".

> I think that adds additional complexity beyond your previous suggestion and I'm
> not sure what the incremental gain is.

It would allow for more flexibility. The current proposal checks whether
the set of recipients seen by the verifier is the same set as that seen
by the signing agent, while to prevent replay attacks, it only matters
that the former is a subset of the latter.

Mind you, it may still add too much additional complexity. And maybe
there is an easier way to solve this cryptographically. I'll look
around.

Martijn.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 14 Nov 2016 18:09:25 +0900

On Mon, Nov 14, 2016 at 5:53 PM, Martijn Grooten <[email-masked]

> server, so it's probably okay".

Yeah, so far I'm liking this idea even better than the original.  I'll do
up a new version and see what it looks like.

-MSK

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 14 Nov 2016 07:42:16 -0500

> transit B, which should survive just fine.

Within an ADMD, internal relaying should survive just fine, since, as you say, 
RCP TO doesn't change, but I don't think that's an interesting case.  Email 
authentication check tend to be very fragile if not done at the edge of the 
ADMD for lots of reasons.

What I was thinking of was non-point-to-point handling while between two 
ADMDs.  Typically mailing lists or transparent forwarding.  In both of those 
cases, RCPT TO changes.  One set of advice given to mailing list operators 
about DMARC has been to change their list setup so that they don't break DKIM 
signatures (and some have done that).  This proposal would make that 
impossible.

Between two ADMDs, you would not be able to change RCPT TO, so it would have 
to go direct.  At that point, if you engage DMARC alignment requirements on 
the SPF check, you achieve the same result.

Also, if you make this a DMARC policy choice, then the added restrictions 
associated with restricting changes to RCPT TO only affect senders that have 
opted into the policy choice.

> discussion without prematurely slamming any doors.

OK.  Ultimately, "don't sign spam" has got to be the solution or reputation is 
going to suffer, so I think they are going to have to eventually bite the 
bullet and fix it.  I don't think an opt-in extension to DMARC like I suggest 
above is unreasonable and I think it would be able to be deployed more 
quickly.  So far though, I don't see fixing it in DKIM as a good way to go.

Scott K

---

From: Michael Thomas <[email-masked]>
Date: Mon, 14 Nov 2016 07:38:44 -0800

On 11/13/2016 09:38 PM, Murray S. Kucherawy wrote:
> On Sun, Nov 13, 2016 at 9:39 PM, Mark Delany <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Hi Murray.
>
>
> Mark!
>
> 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.

Mike

---

From: Hector Santos <[email-masked]>
Date: Mon, 14 Nov 2016 13:19:35 -0500

On 11/13/2016 1:50 AM, Murray S. Kucherawy wrote:> I've posted a draft 
that attempts to address an attack that's begun to
> appear with DKIM.  Interestingly, we called it out as a possible
> attack in RFC6376 and even RFC4871, but now it's apparently happening
> and being annoying enough that people (I believe from the MAAWG
> community) are asking if there's a protocol solution that's possible.
>

Thanks for the write up.  I'm just now reading this (a quick review) 
and I have several points to make about this effort:

 From what I read so far, this is 1::MANY distribution issue and less 
of a 1::1 direct, private email path issue but the 1::1 path is being 
exploited to prepare a 1::many distribution at some systems?

Not excluding another possible tech solutions/proposals to close this 
"security loophole,"  the code changes required are significant, both 
at the signer and verify. With integrated systems, passing the 
distribution list to the signer is required.  There is much change to 
be considered.

If it promotes code changes, then we should consider other DKIM 
related situations as well to be included in what is essentially an 
DKIM Update.  For example, John's double signature proposal can be 
considere, and in addition, we could also review the "i=" AUID 
identity to see if it can help.  Our package can the i= for list 
distributions.

But this here bothers me:

    9.  Implementation Status

    The next release of OpenDKIM will implement this proposal.  OpenDKIM
    is in widespread use, including at very large installations, so use
    and utility of this extension can be easily observed.

Since this is a security loophole, I'm concern that this proposal 
needs a very thorough review, including reviewing other proposals and 
solutions. You could be jumping the gun to implement something that 
will be harder to pull back and once again, the IETF needs to remember 
that not everyone uses OpenDKIM.

Thanks for your consideration

-- 
HLS

---

From: Martijn Grooten <[email-masked]>
Date: Tue, 15 Nov 2016 16:53:19 +0000

On Mon, Nov 14, 2016 at 07:42:16AM -0500, Scott Kitterman wrote:
> bullet and fix it.

I think you underestimate how difficult it is to detect spam in cases
like this. Good spam, from a spammer's point of view, looks like
legitimate email, except that it's sent in bulk, or links to some bad
site (malware/phishing), or has a malicious attachment. The attachment
aside, none of this has to be present when the first instance of the
email is sent (and signed). And even detecting new malware isn't as
trivial as it may sound.

Martijn.

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 15 Nov 2016 11:56:11 -0600

>email is sent (and signed). And even detecting new malware isn't as

Not at all.  As I understand the scenario, the provider knows it's bad, doesn't send the mail on to the outside world, but still gives a signed copy back to the originator (which is then available for replay).

Given that scenario, they've already done the hard part.

All the protocol solutions being discussed have huge negative implications for email.  I've yet to see a proposal I think should be implemented (my suggestion about a now DMARC policy option still seems the least bad to me, but I don't particularly like it).

Scott K

Scott K

---

From: Martijn Grooten <[email-masked]>
Date: Tue, 15 Nov 2016 19:17:29 +0000

On Tue, Nov 15, 2016 at 11:56:11AM -0600, Scott Kitterman wrote:
> Not at all.  As I understand the scenario, the provider knows it's
> bad, doesn't send the mail on to the outside world, but still gives a
> signed copy back to the originator (which is then available for
> replay).

My understanding is an attack where the email is sent to an outside
address owned by the sender, who then gets a copy of the email, signed
by the provider who didn't think the email was bad.

Signing an email that you know is bad does indeed sound like a bad
idea.

Martijn.

---

From: Michael Thomas <[email-masked]>
Date: Tue, 15 Nov 2016 11:26:10 -0800

> Signing an email that you know is bad does indeed sound like a bad

That's not how i read it, but even if it was it would still require the 
mail be signed by a provider which presumably should pass judgment on it
to decide to sign or not. If they signed something bad, they own the 
ding on their reputation, or whatever.

It's not like you can change the bits in the mail once they're signed 
and still keep a valid signature, so I'm not seeing what the problem is 
here.

Mike

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 16 Nov 2016 04:57:36 +0900

On Wed, Nov 16, 2016 at 4:17 AM, Martijn Grooten <[email-masked]

> Signing an email that you know is bad does indeed sound like a bad

There's always some time window between a spammer discovering a new
technique that gets past filters and those filters learning about the new
attack via whatever ML is in use.  That might be when this attack is most
effective.  You can't label as spam that which you don't identify as spam.

-MSK

---

From: Michael Thomas <[email-masked]>
Date: Tue, 15 Nov 2016 12:11:03 -0800

On 11/15/16 11:57 AM, Murray S. Kucherawy wrote:
> On Wed, Nov 16, 2016 at 4:17 AM, Martijn Grooten 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
> technique that gets past filters and those filters learning about the 
> new attack via whatever ML is in use.  That might be when this attack 
> is most effective.  You can't label as spam that which you don't 
> identify as spam.

So, when the filters catch up, it will then mark it as spam again 
regardless of the DKIM signature.

So what exactly is the problem here?

Mike

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 16 Nov 2016 05:51:27 +0900

> So what exactly is the problem here?

I suppose when the filters catch up, the spammer can no longer get
$HIGH_REPUTATION_MAIL_SERVER to sign that message until the next hole is
discovered.  But everything submitted and replayed prior to that has
already gone out and been delivered on the basis of that reputation.

That's the problem here.

-MSK

---

From: Brandon Long <[email-masked]>
Date: Mon, 21 Nov 2016 16:04:30 -0800

In examples we've seen, the mail is delivered to a host and immediately
(seconds) picked up by the spammers botnet and millions of copies sent.

Short of charging an exorbitant amount of money per message sent, I don't
see how any service can prevent sending a single spam message with 100%
accuracy.

Brandon

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 21 Nov 2016 16:27:20 -0800

What's the actual damage here?  Does, say, gmail.com's reputation suffer
when it signs spam that then gets replayed?

---

From: Brandon Long <[email-masked]>
Date: Mon, 21 Nov 2016 21:16:51 -0800

Well, besides the obvious damage of phishing/spam mails that may make it
through filters because of this, yes, this can also be used to damage the
reputation of senders.

Gmail can probably weather the reputation issue, since we're a large high
volume service, and antispam folks would have to mitigate in order to let
through the regular high volume of "good" mail.  Users tend to hate false
positives more than false negatives.  Same with most high volume / well
known senders.

It's the medium senders who are can be caught in a bind, effectively
blacklisted.  It's kind of like IP reputation or blacklisting if your
server gets owned and is used to send spam, cleaning up after that is a not
fun for the admin.  Previously, most systems wouldn't have blacklisted a
server for literally sending a single spam message (maybe if the recipient
happened to be a particularly strong spam trap, but that would be pretty
amazing).  Now, a single spam message can be multiplied into blacklisting
by dozens of mailbox providers.

And, if you think about it, spam is in the eyes of the recipient.  If you
take this message I'm composing right now and send a couple billions copies
to the top 10 mailbox providers, how many spam markings will it get?  With
some of the spammers we deal with, all they're looking for is clicks on the
links in the email, there is nothing particularly commercial about the
content itself.

To believe that you can keep email "the same as it's been" and prohibit
sending even a single weaponizable message is to ignore reality.

That said, at this point most of the major mailbox providers have had to
deal with this and have some level of mitigation in place.   The rate at
which we can deploy a new protocol to fix an attack like this is always
going to be challenging, but it may be that this attack will continue and
move down market in time, so a protocol could be available as other folks
are abused or targeted.  None of that speaks to whether this proposal is
the right solution or if there is a good one.

Brandon

On Nov 21, 2016 4:27 PM, "Murray S. Kucherawy" <[email-masked]> wrote:

---

From: Brandon Long <[email-masked]>
Date: Tue, 22 Nov 2016 20:30:13 -0800

On Tue, Nov 22, 2016 at 8:05 AM, John Levine <[email-masked]> wrote:
> Now I'm really confused about what problem we're trying to solve here.
> You are of course right that there are messages that become spam if
> they're remailed a zillion times, but there are also messages that
> don't.  If I send a message to, say, nanog, it goes to a lot of
> people, the DKIM signatures usually survive, and it's not spam.
>
> If the bulk remail is spam, that will presumably affect the reputation
> of the places from which it is remailed.  That's not enough?
>

In a reputation based system, you take reputation on various features of
the message, and whether or not a message is spam depends on all of those
features, and then feeds back into each of those features.

So, the IPs for the botnet the message is spammed from will certainly take
a hit, or may already be bad.  The reputation of the dkim auth domain is
likely also to suffer, though.

In an IPv6 world, domain auth may play a higher role than IP for
reputation, given the high number of IP addresses.

Of course, the obvious mitigation there is to be more careful of dinging
dkim auth when spf auth doesn't pass or match.

Brandon

---

From: Jim Fenton <[email-masked]>
Date: Mon, 28 Nov 2016 11:28:55 -0800

Waking up to this thread a little late...

On 11/14/16 7:38 AM, Michael Thomas wrote:
> This sounds like a misconfiguration problem.It's a problem because
> it's $spam/$malware/$bad regardless of who the recipient is.
>
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

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 28 Nov 2016 19:32:22 +0000

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 <[email-masked]> wrote:

> 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