Subj : Re: [WINServer] dmarc To : All From : winserver.support@winserver.com Date : Fri Nov 23 2018 09:25:36 Newsgroups: wclistserve.win.server Received: by winserver.com (Wildcat! SMTP Router v7.0.454.6) for winserver@winserver.com; Fri, 23 Nov 2018 10:25:30 -0500 Received: from [192.168.1.68] ([99.121.5.8]) by winserver.com (Wildcat! SMTP v7.0.454.6) with ESMTP id 1983666343.45468.3516; Fri, 23 Nov 2018 10:25:29 -0500 Message-ID: <5BF81BF0.3020409@winserver.com> Date: Fri, 23 Nov 2018 10:25:36 -0500 From: Hector Santos Organization: Santronics Software, Inc User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.8.1 MIME-Version: 1.0 To: winserver list Subject: Re: [WINServer] dmarc References: <000001d481ee$00e95c00$02bc1400$@org> <5BF6A96F.3000005@winserver.com> In-Reply-To: <5BF6A96F.3000005@winserver.com> Content-Type: multipart/mixed; boundary="------------000008050603030504010904" Let me help clarify a few things about DKIM, ADSP/ATPS and now DMARC. For over 12+ years, I've been working on DKIM with the IETF standards working groups. In 2006, I wrote a proposal called DSAP (DKIM Signature Authorization Protocol). It had the basic ideas of what ADSP/ATPS and DMARC now has, including a reporting concepts. I just felt that with the proof of concept already established, "reporting" was become redundant and even abused. So I didn't go deep into reporting in DSAP as DMARC eventually did. In 2011, we released the first version of wcDKIM that included ADSP and ATPS support. ADSP addressed the 1st party signature authorization and ATPS addressed the 3rd party signature authorization. This all predated DMARC which came when the it was discovered (by me) that ADSP could do damage to a list system if the list didn't support something list ATPS to address 3rd party list domains. But it was decided that ATPS didn't scale. So because of the LIST problem, ADSP was abandoned by the IETF. Ironically, the same people who abandoned ADSP, replaced it DMARC without fixing the 3rd party list domain problem. This was because DMARC was done outside the IETF by companies, who like me, believed in the DKIM Author Domain Signature Policy model that ADSP offered. It just didn't have Reporting, so DMARC replaced it and redundant reporting began. I know that if published a restrictive domain, its going to help reduce SPAM because receivers will reject the bad ones. I don't need a report telling me that you rejected a spam!!! From the very beginning, DKIM Author Domain Signature Policy (ADSP) concepts were very powerful. Using the email's From: address domain, you can publish a ADSP or DMARC DNS record to declare to the world, who can sign your mail. For the 1st party signature, the logic was simple: DKIM-Signature: d=yahoo.com From: "Joe User" This is 1st party because the signer domain "d=" is the same as the author from domain. If it was this: DKIM-Signature: d=winserver.com From: "Joe User" Then this is an example of a 3rd party signature and this is where DKIM ADSP and DMARC broke down. Both ADSP and DMARC gives you permission to reject this message because the domains are not aligned (don't match). If you lookup the yahoo.com DMARC DNS record: "v=DMARC1; p=reject; pct=100; rua=mailto:dmarc_y_rua@yahoo.com; It has a p=reject policy that says is the domains don't match, you may reject this. So what happen recently to us on this list and developers list, is what also has been happening to all LIST systems related to DMARC posted messages. If you used a domain, like yahoo.com, for list subscriptions, when you posted a message to the list, WcListServer turned around and begins to distribute to all the members of the list. When the member SMTP receiver rejected the message because it was a DMARC 3rd party signature, then wcListServe would make the member INACTIVE because wcSMTP could not send it out. This was a major problem and had to be addressed. So for the next AUP, we have a new SMTPFILTER-LISTCHECKER.WCX that comes with wcListServer that will check if the poster has a restricted DMARC or ADSP domain and disallow the post into the list. This will help protect the members of the list. But it is also desirable for people to use their Yahoo.com account for a list. So its possible in the future version of wcListServer to offer more user options: 1) Allow User to subscribe to a list in READ-ONLY mode, not posting, 2) Allow User to subscribe to a digest list because the From is always the list domain, 3) Offer a Rewrite of the From address so its a 1st party signature before it is distributed. 1 and 2 are easy. #3 is more questionable because it has been a long time taboo to never change the From: field. Except for a digest, this is never done, until DMARC and the need for list systems to resolve the distribution problem described above. So with #3, the 1st party validated email from a member that is going to post to a list: DKIM-Signature: d=yahoo.com From: "Joe User" A future option will allow WCLS to do "Rewriting" of from address to something like the following when the distribution begins: DKIM-Signature: d=dmarc.winserver.com From: "Joe User" X-Original-From: "Joe User" The above is NOT a standard -- it is a KLUDGE and how its done is still in question. Overall, it is not desirable to do a rewrite and the systems that I know already do a rewrite, make a secured 1st message into an unprotected 3rd party signature message. It changes the from but it signs mail with a 3rd party domain which brings us back to the original problem. What I want to do is create consistent DKIM signing rules for list systems that keeps the mail in a 1st party signature -- the from dmarc.winserver.com is the same as the signature d=dmarc.winserver.com domain. Anyway, it is still all new and in the future versions of Wildcat!. We will be addressing all this and then some. The next pending 454.6 release will address some things but not all, like we really needed to provide a SMTPFILTER-LISTCHECKER.WCX for people using WcListServer. The wcListServer html-subscribe.wcx also now checks for restricted domains, so you can't subscribe to a list if you have a restricted domain. This part will eventually change with the #1 and #2 and #3 options above. I know this is all seems complex, but that is what Wildcat! has always offered over the years with many of the complex ideas -- a simplified, sound, integrated system that offers you solutions right out of the box. We will do that with WCDKIM as well. Thanks -- Hector, Engineering & Technical Support Santronics Software, Inc. http://www.santronics.com (sales) http://www.winserver.com (support) http://www.winserver.com/AupInfo (Online AUP Help) Office: 305-248-3204 On 11/22/2018 8:04 AM, Hector Santos wrote: > The next AUP will include the new SMTPFILTER-LISTCHECKER distributed > with Wildcat! List Server. This checker is for controlling the list > email going into your mailing list on your wcListServe setup/system. > If you are not using wcListServer, then you don't need this. > > On 11/21/2018 6:00 PM, Antonio Rico wrote: >> Hi, >> >> Will the updated script to allow email that is blocked due to dmarc be >> included in this AUP? > begin:vcard fn:Hector Santos n:Santos;Hector email;internet:winserver.support@winserver.com tel;work:305-248-3204 version:2.1 end:vcard --- Platinum Xpress/Win/WINServer v3.1 * Origin: Prison Board BBS Mesquite Tx //telnet.RDFIG.NET www. (1:124/5013) .