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

[Brandon Long <[e-mail]>]

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

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

On Mon, Nov 21, 2016 at 4:04 PM, Brandon Long <[e-mail]> wrote:

> 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
>
> On Nov 15, 2016 12:52 PM, "Murray S. Kucherawy" <[e-mail]>
> wrote:
>
>> On Wed, Nov 16, 2016 at 5:11 AM, Michael Thomas <[e-mail]> wrote:
>>
>>> 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?
>>>
>>
>> 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
>>
>> _______________________________________________
>> 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