Newsgroups: wclistserve.win.server
Received: by winserver.com (Wildcat! SMTP Router v7.0.454.6)
for
WINServer@winserver.com; Fri, 23 Nov 2018 14:34:45 -0500 Authentication-Results: dkim.winserver.com;
dkim=fail (DKIM_SELECTOR_DNS_PERM_FAILURE) header.d=tnabbs.org header.s=turbo-smtp header.i=tnabbs.org;
Received: from nbjjceehccci.turbo-smtp.net ([199.244.72.228])
by winserver.com (Wildcat! SMTP v7.0.454.6) with ESMTP
id 1998621441.45468.3888; Fri, 23 Nov 2018 14:34:44 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=tnabbs.org; s=turbo-smtp; x=1543606484; h=DomainKey-Signature:
Received:Received:From:To:References:In-Reply-To:Subject:Date:
Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:
Thread-Index:Content-Language; bh=oGOfzArR0idlAUa3idJLHUBTM2Mccj
m2srtklNfM+O8=; b=sJYxZwz0ps8yf75BFIflGfUfDZnwvkxwNxtoeusFWpBAoH
1xWlWPOb/TplcnG6L4R6uK6Zifgpp0EFHM/MKb5hqj+bNjjQdNAsX4cQmFUetXMF
8O+XK+6hOBze1yTRYGzyJTuUjCCSUHF+KUZ2lCO35URd/4zLx1o/d73zFJbF8= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
s=turbo-smtp; d=tnabbs.org;
h=Received:Received:X-TurboSMTP-Tracking:From:To:References:In-Reply-To:Subject :Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:T hread-Index:Content-Language;
b=qx9Pei+VqLGC2qX9oThUv2zeTFph1Az7zmRbiF6o/qglyO1VTV9bcpcIat3vzA
6uQyRj2AQeg6Fydyqe6krF/w41GvPfGbDyGf2A7dYMe2Zw5fEPMFDp75lO/CrOb+
rEWck0OoTWNouk30gZHL1Y5fBo2k+lWbEMebAcsjQ4tB4=;
Received: (qmail 22189 invoked from network); 23 Nov 2018 19:34:23 -0000 Received:
X-TurboSMTP-Tracking: 4702981405
From: "Antonio Rico" <
antoniorico@tnabbs.org>
To: <
WINServer@winserver.com>
References: <000001d481ee$00e95c00$02bc1400$@org> <
5BF6A96F.3000005@winserver.com> <
5BF81BF0.3020409@winserver.com>
In-Reply-To: <
5BF81BF0.3020409@winserver.com>
Subject: RE: [WINServer] dmarc
Date: Fri, 23 Nov 2018 14:34:05 -0500
Message-ID: <000001d48363$7f5c1890$7e1449b0$@org>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AdSDQPhyeaLD8e5iRiyNBHovT6EjFwAIj/dQ
Content-Language: en-us
Hi,
Will this open up the possibilities of mail bombs and mass email floods, if the
header conversion is not done securely?
-----Original Message-----
From:
listadmin-winserver@winserver.com [mailto:
listadmin-winserver@winserver.com] On Behalf Of Hector Santos
Sent: Friday, November 23, 2018 10:26 AM
To: winserver list
Subject: Re: [WINServer] dmarc
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" <
user@yahoo.com>
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" <
user@yahoo.com>
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" <
user@yahoo.com>
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" <
rewrite-agent@dmarc.winserver.com>
X-Original-From: "Joe User" <
user@yahoo.com>
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?
---------------------------------------------------------------------
To unsubscribe, send e-mail to
wclistserve@winserver.com with
UNSUBSCRIBE WINServer in the message body on a line by itself.
To contact the list admin, e-mail
ListAdmin@winserver.com ---------------------------------------------------------------------
--- Platinum Xpress/Win/WINServer v3.1
* Origin: Prison Board BBS Mesquite Tx //telnet.RDFIG.NET www. (1:124/5013)