From nobody Thu Sep 10 15:50:57 2020 Return-Path: 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 2F3FF3A0FF7 for ; Thu, 10 Sep 2020 15:50:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bayviewphysicians.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 Mf8Y-VBiPmTl for ; Thu, 10 Sep 2020 15:50:54 -0700 (PDT) Received: from mail.bayviewphysicians.com (mail.bayviewphysicians.com [216.54.111.133]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 413FA3A0FF0 for ; Thu, 10 Sep 2020 15:50:54 -0700 (PDT) X-ASG-Debug-ID: 1599778250-11fa3109a8e36a0001-K2EkT1 Received: from webmail.bayviewphysicians.com (smartermail4.bayviewphysicians.com [192.168.1.49]) by mail.bayviewphysicians.com with ESMTP id q7QoCt03E1yQOuZb (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NO); Thu, 10 Sep 2020 18:50:50 -0400 (EDT) X-Barracuda-Envelope-From: fosterd@bayviewphysicians.com X-Barracuda-RBL-Trusted-Forwarder: 192.168.1.49 X-SmarterMail-Authenticated-As: fosterd@bayviewphysicians.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bayviewphysicians.com; s=s1025; h=message-id:reply-to:subject:to:from; bh=OjfxQMRMcM9ZQfRlBeNaEbhCjJDD2GHLCTNQukMt1VI=; b=qlFfQn7emh9saB+q+kbTY0+PkTxZSSdCbqGYUfT+P0z1UlL9IfEmT2+pzAGiltl4P 1XbuQ8oRPWB6aJRN1R2wLv4IDXP+SlPTed+FEo12VFFQ0zQNkkxXiDeKMYgMkKSgx 3DibfR06Ux5YzRujyBrSDnDcOiA9Oi3c/pjyCKnGY= From: "Douglas E. Foster" To: "dmarc-chairs@ietf.org" CC: "dmarc@ietf.org" Date: Thu, 10 Sep 2020 18:50:41 -0400 X-ASG-Orig-Subj: Issue submission - Mailing list security and potential solutions using DMARC Reply-To: fosterd@bayviewphysicians.com Message-ID: <81937b856c4a4a40b313ae6b9b7af97b@bayviewphysicians.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=9277fe582da14779980b7ff9e66d88b9 X-Exim-Id: 81937b856c4a4a40b313ae6b9b7af97b X-Barracuda-Connect: smartermail4.bayviewphysicians.com[192.168.1.49] X-Barracuda-Start-Time: 1599778250 X-Barracuda-Encrypted: ECDHE-RSA-AES256-SHA384 X-Barracuda-URL: https://mail.bayviewphysicians.com:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at bayviewphysicians.com X-Barracuda-Scan-Msg-Size: 10418 X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.84540 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message Archived-At: Subject: [dmarc-ietf] Issue submission - Mailing list security and potential solutions using DMARC X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Sep 2020 22:50:56 -0000 This is a multipart message in MIME format. --9277fe582da14779980b7ff9e66d88b9 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Recently, I have become worried about the risks associated with using my re= gular email on this list, especially since everything goes into a long-term= archive. I am wishing that I had subscribed using a disposable account. = A general safety principle is to limit how and when one's email addre= ss is released, because once it is released, it cannot be taken back. T= here are a number of potential problems associated with releasing actual em= ail addresses onto a mailing list. Address Harvesting Any subscriber could potentially be harvesting email addresses from the lis= t, and forwarding them to a spam source. The spammer can tune his attacks= more closely using other information gathered from list posts, including t= he list area of interest and other information disclosed in the course of l= ist discussions. If the harvesting is occurring, list participants and li= st operators have no method for identifying and closing the leak. Badly Behaved Subscriber / Stalking If a subscriber starts behaving badly toward another member, particularly i= n some form of cyber-stalking, the list operator can discharge the perpetra= tor from the list. Unfortunately, the discharge action does not cut off a= ccess to the victim, because the victim's personal email address has alread= y been disclosed. Malicious Content filtering A well-run list will implement a variety of techniques to prevent hostile c= ontent from being distributed. However, once personal addresses have bee= n disclosed, a bad actor can bypass those filters by sending the same prohi= bited traffic directly to any subscribers who have posted to the list. C= onsequently, the burden of defense remains on the recipient organization, b= ecause the list defenses are too easily evaded. List Spoofing A well-run mailing list is likely to breed an elevated level of trust among= the participants. As a result, a successful spoof of the mailing list is= that much more likely to be successful. To the recipient, the DMARC lis= t is primarily identified by the subject tag and the IETF footer. The abs= ence of attachments and the text-only format are additional clues. These = are arguably "trust indicators", and we have discussed that trust indicator= s have limited effectiveness. For example, many MUAs will make URLs in a= text-only message into a clickable link, blurring the visual distinctivene= ss between text and html messages. An attacker could potentially replica= te the subject tag and footer, apply a non-DMARC address, and send it from = his own server. The incoming email filter is unlikely to have the sophis= tication to recognize that this format is only supposed to come from IETF, = so the message is likely to be allowed and the users are at risk of being d= uped. The Alternative All of these problems can be avoided if the subscriber is given an alias at= enrollment, and the alias is used for all messages relayed on the subscrib= er's behalf. For this list, my alias could be DougF.dmarc@ietf.org. Me= ssages sent to an alias address must be submitted through the list operator= , and the list manager should have logic to reject messages from a non-subs= criber that are targeting a subscriber alias. Because the personal email address is only known to the list operator, harv= esting is impossible. Any aliases that are harvested from the list will b= e unusable by a spammer operating outside the list. For the same reason, if a misbehaving subscriber is ejected from the list, = he immediately loses access to the people who were the victims of his actio= ns. List spoofing becomes less effective as well. Legitimate list messages ca= n be validated using DMARC with p=3Dreject on the list domain. Spoofed m= essages that reach the user will not have a From address in the list domain= and will not follow the pattern of list aliases. Overall, I conclude that mailing lists have much to benefit from intelligen= t use of DMARCv1 as previously specified. --9277fe582da14779980b7ff9e66d88b9 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Recently, I have b= ecome worried about the risks associated with using my regular email on thi= s list, especially since everything goes into a long-term archive.   I= am wishing that I had subscribed using a disposable account.    =   A general safety principle is to limit how and when one's email add= ress is released, because once it is released, it cannot be taken back. &nb= sp;   There are a number of potential problems associated with releasi= ng actual email addresses onto a mailing list.

Address Harvesti= ng

Any subscriber could potentially be harvesting email addresses= from the list, and forwarding them to a spam source.   The spammer ca= n tune his attacks more closely using other information gathered from list = posts, including the list area of interest and other information disclosed = in the course of list discussions.   If the harvesting is occurring, l= ist participants and list operators have no method for identifying and clos= ing the leak.

Badly Behaved Subscriber / Stalking

If a = subscriber starts behaving badly toward another member, particularly in som= e form of cyber-stalking, the list operator can discharge the perpetrator f= rom the list.   Unfortunately, the discharge action does not cut off a= ccess to the victim, because the victim's personal email address has alread= y been disclosed.

Malicious Content filtering

A well-ru= n list will implement a variety of techniques to prevent hostile content fr= om being distributed.    However, once personal addresses have be= en disclosed, a bad actor can bypass those filters by sending the same proh= ibited traffic directly to any subscribers who have posted to the list. &nb= sp;  Consequently, the burden of defense remains on the recipient orga= nization, because the list defenses are too easily evaded.

List S= poofing

A well-run mailing list is likely to breed an elevated le= vel of trust among the participants.   As a result, a successful spoof= of the mailing list is that much more likely to be successful.   &nbs= p;To the recipient, the DMARC list is primarily identified by the subject t= ag and the IETF footer.   The absence of attachments and the text-only= format are additional clues.   These are arguably "trust indicators",= and we have discussed that trust indicators have limited effectiveness. &n= bsp;  For example, many MUAs will make URLs in a text-only message int= o a clickable link, blurring the visual distinctiveness between text and ht= ml messages.    An attacker could potentially replicate the subje= ct tag and footer, apply a non-DMARC address, and send it from his own serv= er.    The incoming email filter is unlikely to have the sophisti= cation to recognize that this format is only supposed to come from IETF, so= the message is likely to be allowed and the users are at risk of being dup= ed.

The Alternative

All of these problems can be avoide= d if the subscriber is given an alias at enrollment, and the alias is used = for all messages relayed on the subscriber's behalf.    For this = list, my alias could be DougF.dmarc@ietf.org.   Messages sent to an al= ias address must be submitted through the list operator, and the list manag= er should have logic to reject messages from a non-subscriber that are targ= eting a subscriber alias.

Because the personal email address is o= nly known to the list operator, harvesting is impossible.   Any aliase= s that are harvested from the list will be unusable by a spammer operating = outside the list.

For the same reason, if a misbehaving subscribe= r is ejected from the list, he immediately loses access to the people who w= ere the victims of his actions.

List spoofing becomes less effect= ive as well.   Legitimate list messages can be validated using DMARC w= ith p=3Dreject on the list domain.    Spoofed messages that reach= the user will not have a From address in the list domain and will not foll= ow the pattern of list aliases.

Overall, I conclude that mailing = lists have much to benefit from intelligent use of DMARCv1 as previously sp= ecified.

--9277fe582da14779980b7ff9e66d88b9--