Re: [dmarc-ietf] AutoForward problems - Change log benefits to mailing lists
Brandon Long <blong@google.com> Tue, 08 September 2020 22:05 UTC
Return-Path: <blong@google.com>
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 538E83A0474 for <dmarc@ietfa.amsl.com>; Tue, 8 Sep 2020 15:05:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.599
X-Spam-Level:
X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RkEffDo3sUpz for <dmarc@ietfa.amsl.com>; Tue, 8 Sep 2020 15:05:55 -0700 (PDT)
Received: from mail-vs1-xe32.google.com (mail-vs1-xe32.google.com [IPv6:2607:f8b0:4864:20::e32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48A1F3A041B for <dmarc@ietf.org>; Tue, 8 Sep 2020 15:05:55 -0700 (PDT)
Received: by mail-vs1-xe32.google.com with SMTP id p185so202799vsp.8 for <dmarc@ietf.org>; Tue, 08 Sep 2020 15:05:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=tZcDmRk5QeQkYlRUf+1wI/4XUMwrDLdSl+Bd/alin+0=; b=HmPlelmZ11fpmPt7WtFK2B+YUU8rl6n261IhKhdGscdzVxiVPkX3RvPKXO9EUrNfSn 31ob8XHWeBzr3OEg04vhZZS+SVPFXqNt7P2KlKuV2PoE6fwzx9/ufyI5P5Z66ZGvFx8l r7dG4jPxxA827PkAENAF2dHNpUl2+hwHaLnuf8omG05yrMtEh348rP71bEGvpuisV3fW V99KZKmqXH4/WQkQ7EH5O4bqxybPGhhIr0R9DeoEsNHQYLej7big8m60OBUxuPJh9Tj0 +PjKY2EWa1fsRgUhic4eW39r4muMwow9b6bZLP5TjgGoVS7dFZtcKstkY0WvbS3j/iq5 rp8g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=tZcDmRk5QeQkYlRUf+1wI/4XUMwrDLdSl+Bd/alin+0=; b=njqbq6ovzKaxL0HyhSoFf71anDwME47N9fe+zskKNXdLRSnc2+g86Hy8owdOr6S0Dn tLVz8UHkYTIsUvr5BKei1g9IkEXU7slw+hiWbhNEWfkEb2iUNC/4hjTZ27vngTn2bRhI uXvrzdkbv/mhGIYcqAkRxBxprvKSWKA71JyQ+Wj9S85g7DQ+geK1AnDxNNY5u+H9EMdC 6y/amXTyBqT9Ym74irHD4Pm5krT/q2tCDkffrOXjhBZ8Yp7Q5orgs39CGJK2u6g/vmZb I4ILpxFsMhXM6bP8x45Gsbj4VsCRc6qxooaFDGWqFCWQU0GDAUbtfF1lwHb8vUScXUUh 8tWA==
X-Gm-Message-State: AOAM532FDxePHg+evLMAsOibxd/qx/YXrwj2AQa0tI8SON04WqanoRMt wE7C82OMf5n/xC5KKTMe9f97c4DljEf4Bp/KmJPWO7l7aCQp
X-Google-Smtp-Source: ABdhPJwWrCeW4YObhHdw4QMXqSbdtRH5/JFz9hY/69jESNw/YiBPc9qIzjftfK2nsdhymBYH0dOThUcG1rnSu1RDB24=
X-Received: by 2002:a67:fc94:: with SMTP id x20mr758192vsp.33.1599602753820; Tue, 08 Sep 2020 15:05:53 -0700 (PDT)
MIME-Version: 1.0
References: <3010f47f2d614ee4a4005de50c589604@bayviewphysicians.com> <767e2dcc-e87c-1e90-2f86-486e51a3c29f@wisc.edu> <rirrip$1qcl$2@gal.iecc.com> <8134cf3514264790937acc27884fdc91@bayviewphysicians.com> <e3954174-1c29-3562-14e7-ae5ffc1ecedc@tana.it> <869dc317cba9410fb95ed5cf8d87204c@bayviewphysicians.com> <CAL0qLwbTcYvf9HKREQi=w_Lk8egRa+K1V-qHs5zo_u25iUNUjQ@mail.gmail.com> <000901d685d8$e5290830$af7b1890$@bayviewphysicians.com> <CAL0qLwYsbyy_Q80sW7H4FPDTcasQKPkA8vVe8cMn_1Gizwy7-w@mail.gmail.com>
In-Reply-To: <CAL0qLwYsbyy_Q80sW7H4FPDTcasQKPkA8vVe8cMn_1Gizwy7-w@mail.gmail.com>
From: Brandon Long <blong@google.com>
Date: Tue, 08 Sep 2020 15:05:40 -0700
Message-ID: <CABa8R6ugxjbrjgqT2Pg-DDvxLSVxhMZE5opDKbzwETe=SaunPA@mail.gmail.com>
To: "Murray S. Kucherawy" <superuser@gmail.com>
Cc: Doug Foster <fosterd=40bayviewphysicians.com@dmarc.ietf.org>, IETF DMARC WG <dmarc@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000ecec2f05aed489f1"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/tcl7I7syPmF0szXkOohj-KQA-aA>
Subject: Re: [dmarc-ietf] AutoForward problems - Change log benefits to mailing lists
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" <dmarc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dmarc>, <mailto:dmarc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dmarc/>
List-Post: <mailto:dmarc@ietf.org>
List-Help: <mailto:dmarc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dmarc>, <mailto:dmarc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 08 Sep 2020 22:05:57 -0000
On Tue, Sep 8, 2020 at 1:30 PM Murray S. Kucherawy <superuser@gmail.com> wrote: > On Tue, Sep 8, 2020 at 5:09 AM Doug Foster <fosterd= > 40bayviewphysicians.com@dmarc.ietf.org> wrote: > >> However, I disagree about negative reputation. Content filtering alone >> is insufficient and even more error prone. In the last year, I have had >> spam campaigns about LED lighting, stand-up desks, touchless thermometers, >> and knife sharpeners. I cannot anticipate all the ways that spammers will >> hide their dirty deeds. But I know it is spam, not merely unwanted >> advertising, because of receiving many similar messages from many different >> domains using many different servers. Third-party RBLs help but are >> insufficient. I am gradually building my own reputation database based on >> the traffic that I am receiving. By blocking the problem sources, I have >> been able to get the spam problem under something approaching good control. >> Content filtering is a useful tool for day-zero detection of a new spam >> source. Once a source is detected, it needs to be blocked. >> >> >> >> Whether a message passes SPF and DMARC criteria is part of my search >> critieria for unwanted traffic, but definitely not the only one. As has >> been observed, actual spoofing of the From address is not a huge part of my >> problem at present. This is largely because spammers have easy enough >> tools in Friendly Name spoofing and corporate logo misuse. But I also >> attribute that low volume to the existence of SPF and DMARC. >> > > Suppose I'm one of your touchless thermometer spammers. Your system > identifies me and the DKIM signing domain I'm using. I notice, through > well-established means, that my spam is no longer getting through to you. > So I register a brand new junk domain name, perhaps sadehaiuhfiewn.com or > whatever a few smashes of the keyboard yields, and start signing with that > instead of whatever domain I was using before. For a couple of bucks, I > have now escaped my negative reputation in your system. Maybe I bounce it > through a botnet too, so that you can't catch me with an IP reputation > either. > > Negative reputations are trivially shed. It follows that it's not > terribly useful to track them, at least not long-term. You end up with > records of spammy domains that you'll notice only sent mail for the > shortest of time ranges, long enough to get in undetected or under the > guise of "too new to block", and then abandoned when they stop working. > Blocking domains you've never heard of before is often disruptive when, > say, you join a loyalty program for some vendor you've never dealt with > before and actually do want their mail, so you're between a rock and a hard > place. > > Instead, positive reputations are the things on which you can reliably > act, giving such messages preferential treatment. It's generally a much > higher bar, plus the namespace of domains that manage to earn positive > reputations is small, and they tend to be well-behaved over longer periods > of time. > I disagree, we track reputations both good and bad, and they are incorporated in spam rules across the ladder. A surprising number of negative reputations are not shed, even at very-low... and sure, we do sunset reputations that go unused. At the very least, there is a time lag before the spammer notices the effect and switches. I mean, a blacklist is ultimately a determination that a reputation is so low as to block completely, and that seems to be the main way that anti-spam information is distributed and used by most medium to small providers. That set of botnet IPs definitely will get a low reputation themselves and end up on blacklists. And forcing the spammers to spend money on things like new domain names is part of the benefit. OTOH, we also don't believe in "too new to block", unknown reputation is a great reason to apply throttling at the least. Maybe some of this is large system stuff, where you can expect to see more traffic and things don't tend to be unique... but of course we also get complaints from very small volume folks as well. Brandon
- [dmarc-ietf] AutoForward problems Douglas E. Foster
- Re: [dmarc-ietf] AutoForward problems Jesse Thompson
- Re: [dmarc-ietf] AutoForward problems Doug Foster
- Re: [dmarc-ietf] AutoForward problems Jesse Thompson
- Re: [dmarc-ietf] AutoForward problems John Levine
- Re: [dmarc-ietf] AutoForward problems - Change lo… Douglas E. Foster
- Re: [dmarc-ietf] AutoForward problems - Change lo… Alessandro Vesely
- Re: [dmarc-ietf] AutoForward problems - Change lo… Douglas E. Foster
- Re: [dmarc-ietf] AutoForward problems - Change lo… Murray S. Kucherawy
- Re: [dmarc-ietf] AutoForward problems - Change lo… John Levine
- Re: [dmarc-ietf] AutoForward problems - Change lo… Doug Foster
- Re: [dmarc-ietf] AutoForward problems - Change lo… Murray S. Kucherawy
- Re: [dmarc-ietf] AutoForward problems - Change lo… Brandon Long
- Re: [dmarc-ietf] AutoForward problems - Change lo… Douglas E. Foster