>
> If it were part of the message headers,
The headers provided were obtained from a message while it was being held
by the server under quarantine.
What I provided is what was seen by the server. I don't have access to the
actual message, so I can't provide the headers "after" delivery
The DKIM-Signature suggests obtaining the DNS TXT record selector1._
> domainkey.doccs.ny.gov , but this record does not
> exist, so OpenDKIM cannot validate DKIM-Signature.
It doesn't ??
dig txt selector1._domainkey.doccs.ny.gov
; <<>> DiG 9.9.13-P1 <<>> txt selector1._domainkey.doccs.ny.gov
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 17480
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 4, ADDITIONAL: 9
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;selector1._domainkey.doccs.ny.gov. IN TXT
;; ANSWER SECTION:
selector1._domainkey.doccs.ny.gov. 120 IN CNAME selector1-doccs-ny-gov._
domainkey.nysemail.onmicrosoft.com.
selector1-doccs-ny-gov._domainkey.nysemail.onmicrosoft.com. 3600 IN TXT
"v=DKIM1; k=rsa;
p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDglPZqou3VjxpfYnG7VTqADdgcySvxefYieIn7SIKM5H7FCnQv8zzQgB31fvvvGQcgOf393XuEzSL2ulPZ5pMpnnK4IY5oPyHmCF8lNnKoJ0PdPFmBbTO9B2WUVRKG0oEt70x3CHWfxIQOxRhKqja7CNJBKXsA5AaXSv1YIiG/SwIDAQAB;
n=1024,1456441596,1"
;; AUTHORITY SECTION:
onmicrosoft.com. 122947 IN NS ns1.bdm.microsoftonline.com.
onmicrosoft.com. 122947 IN NS ns4.bdm.microsoftonline.com.
onmicrosoft.com. 122947 IN NS ns3.bdm.microsoftonline.com.
onmicrosoft.com. 122947 IN NS ns2.bdm.microsoftonline.com.
;; ADDITIONAL SECTION:
ns1.bdm.microsoftonline.com. 122947 IN A 40.90.4.208
ns2.bdm.microsoftonline.com. 122947 IN A 64.4.48.208
ns3.bdm.microsoftonline.com. 122947 IN A 13.107.24.208
ns4.bdm.microsoftonline.com. 122947 IN A 13.107.160.208
ns1.bdm.microsoftonline.com. 122947 IN AAAA 2603:1061::d0
ns2.bdm.microsoftonline.com. 122947 IN AAAA 2620:1ec:8ec::d0
ns3.bdm.microsoftonline.com. 122947 IN AAAA 2a01:111:4000::d0
ns4.bdm.microsoftonline.com. 122947 IN AAAA 2620:1ec:bda::d0
Funny, it resolves for the server, as it did the day it was received (It
was the first thing I checked)
The server in question receives 2000 - 4000 emails a day from hundreds of
domains.
The only issues I see are with messages (like this one) sent from Microsoft
services.
problem is not with OpenDKIM in this case, but with the lack of
> understanding of DKIM and DMARC
You're right... That must be it :\
No, the problem is not with OpenDKIM, It's with the messages being received.
On Fri, Feb 1, 2019 at 9:52 AM Дилян Палаузов <dilyan.palauzov_at_aegee.org>
wrote:
> Hello Ken,
>
> the message contains a new line before Thread-Topic. So the following,
> unparsable “authentication-results; spf=none
> (sender IP is )smtp.mailfrom=xxxxxx_at_doccs.ny.gov; ” is not part of the
> email. It is unparsable, because there is a
> semi-colon instead of a colon after the header-field.
>
> If it were part of the message headers, I would classify the mail as spam
> (quarantine) anyway, as putting semi-colon
> after authentication-results or any other header field is an indication
> for spam.
>
> The email does not include Authentication-Results header, inserted by your
> site, containing the DKIM-Signature
> evaluation, that is why OpenDMARC ignores DKIM-Signature and, redirecting
> such a message means also SPF and therefore
> DMARC will fail.
>
> The DKIM-Signature suggests obtaining the DNS TXT record selector1._
> domainkey.doccs.ny.gov , but this record does not
> exist, so OpenDKIM cannot validate DKIM-Signature.
>
> Looking at the code generating “Jan 10 15:36:42 weaver opendkim[4235]:
> x0AKafla028855: failed to parse authentication-
> results: header field”, OpenDKIM just tries to parse each header and
> unparsable headers are ignored. The purpose of
> parsing all the headers, is to let OpenDKIM remove all other AR-headers,
> that were inserted before the email arrived in
> the system, in order to prevent OpenDMARC evaluate headers confirming the
> DKIM validation, when those headers were
> inserted before the email arrived at your site.
>
> Now, OpenDKIM emits for “authentication-results; spf=none (sender IP is
> )smtp.mailfrom=xxxxxx_at_doccs.ny.gov;” a warning
> and ignores it. I think this is valid behaviour.
>
> Summa summarum, the problem is not with OpenDKIM in this case, but with
> the lack of understanding of DKIM and DMARC.
>
> Regards
> Дилян
>
> On Fri, 2019-02-01 at 07:58 -0500, Ken wrote:
> > > despite being asked, you do not share the exact header, that cannot be
> parsed.
> >
> > There you go
> >
> > Return-Path: <?g>
> > Received: from GCC01-DM2-obe.outbound.protection.outlook.com (
> mail-eopbgr840077.outbound.protection.outlook.com [40.107.84.77])by
> weaver.campbus.com (8.14.9/8.14.9) with ESMTP id
> x0AD7Bws013004(version=TLSv1/SSLv3 cipher=AES256-SHA256 bits=256
> verify=FAIL)for <local_user_at_campbus.com>; Thu, 10 Jan 2019 08:07:12 -0500
> > Authentication-Results: weaver.campbus.com; dmarc=fail (p=quarantine
> dis=quarantine) header.from=doccs.ny.gov
> > DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=doccs.ny.gov
> ;s=selector1;h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;bh=nle3m1ypJwIQJcEYxNcs+Ir/fcHuMGnDz4yqI+qTars=;b=0M3G0N6YRSxSUP9QdLY5O9boBg+AxQf48/z10u8TgBHEYO4GJfEUoedSH4qteMfrHDw+IQhpV+dRkv+pk0ggaxMkaWVgzGutk+NiZoRzpYoRCjcJwuCs2pRcqNpScxd/LseV2AnrAfBRi3W7Xs8ExaYN6H0Dcbm2zHqmU6oDf/k=
> > Received: from BN6PR09MB1203.namprd09.prod.outlook.com (10.172.17.149)
> byBN6PR09MB1202.namprd09.prod.outlook.com (10.172.17.148) with Microsoft
> SMTPServer (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384)
> id15.20.1516.14; Thu, 10 Jan 2019 13:07:10 +0000
> > Received: from BN6PR09MB1203.namprd09.prod.outlook.com([fe80::1854:9727:aad7:f8ac])
> by BN6PR09MB1203.namprd09.prod.outlook.com([fe80::1854:9727:aad7:f8ac%8])
> with mapi id 15.20.1516.016; Thu, 10 Jan 201913:07:10 +0000
> >
> > Thread-Topic: Quote
> > Thread-Index: AdSoJ+0X16qh1PIvSx+JI5nsInSggwAu0HkAAACE3rA=
> > Date: Thu, 10 Jan 2019 13:07:10 +0000<
> BN6PR09MB12035CECDBD9887F8B20678BA4840_at_BN6PR09MB1203.namprd09.prod.outlook.com
> ><
> MWHPR09MB12149BD5AA8ED63B6F76E79CA48B0_at_MWHPR09MB1214.namprd09.prod.outlook.com
> ><0533931a-48f6-b74b-ca8f-c45adbd4540e_at_campbus.com>
> > In-Reply-To: <0533931a-48f6-b74b-ca8f-c45adbd4540e_at_campbus.com>
> > Accept-Language: en-US
> > Content-Language: en-US
> > authentication-results; spf=none (sender IP is )smtp.mailfrom=
> xxxxxx_at_doccs.ny.gov;
> > x-originating-ip: [161.11.121.220]
> > x-ms-publictraffictype:
> Email1;BN6PR09MB1202;6:Br+3ZjjSYR6GFOoOs/95+tb+pn+Tb7xYcOzNtisc5LyI3XpDKgsf27L4uRELHU5jjNtjM/uqe0P/OTgJaQ/3KaG41FaIYV4D/d8uhKMxu2Kzhe+tEfiX7SMSKM+SMIh+kaX9ranK60sQosjcb1UnQVT5ljk2GqrVP5vQFAAhuacsInz5HRaRTatcqbNT0yIu8NVV+31huRBj2CzGp/Tl/YbLzk5cyk2lJDVjByav1GakJtae8ow59PVCdAYvbxE3ca4A3CyriiHjreIhwKwZumzJ7GbP3dCS4h1+9bNxZsI6vN/bNx9m/bhef5sMK2UiveqAmK/3Rt3jReU0S0WdZe2QY8p/1fVwVhOy2IYrbq3+9DTy3Hc0QRvmr+3jGSr+E70YVqYicHiihxTqeSCfO2YTEPtSSxncImPuO4d4Du2bQSdThqM89s2uxtqbq/Q7DsQWKsTktTNhwaGz46gIzA==;5:JsBKFw2bWc4sBKQWwzj0N5qFpMWQpktj5edhbD74zrcZayIaZUq6iQRzQMTa1ysY2UD2aGZJv6yrNUP3Isj236YqGABUc8UH9sxFvZWWMc3YeyB9WI8YyTM1MUHhhYAuYRO0vFluM7OTDg2SAVNBrCMECLoh2j4P6Q7VZmn1gyjicfP1Z8iVt6ebulMhAq02fLHRo3XvHSLfjf61OHriIQ==;7:ymhwgOTL87vWV/YChB0vk5CB09S1JobjU4s3KYTpSyB30eRX3kpD1YFXtHviPZfJC4db6QHAg4jX/KT8kxhVpzIp8Qc8D321j1YiSmCh9NR+s+ggitY4ToxZOR5si+z8ZPu1FlfORQ4O8Ed3Wmb2tA==
> > X-ms-exchange-antispam-srfa-diagnostics: SOS;
> > x-ms-office365-filtering-correlation-id:
> d7791c0a-e60c-4f00-66bd-08d676fc880c
> > x-ms-office365-filtering-ht:
> TenantBCL:0;PCL:0;RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600109)(711020)(4618075)(2017052603328)(7153060)(7193020);SRVR:BN6PR09MB1202;
> > x-ms-traffictypediagnostic: BN6PR09MB1202:<
> BN6PR09MB120283FC5D80069A559BC65BA4840_at_BN6PR09MB1202.namprd09.prod.outlook.com
> >
> > x-forefront-prvs:
> 0913EA1D60SFV:NSPM;SFS:(10009020)(39860400002)(376002)(396003)(136003)(346002)(366004)(199004)(189003)(221733001)(66066001)(5660300001)(6436002)(7116003)(229853002)(71190400001)(74316002)(71200400001)(256004)(68736007)(5024004)(14444005)(733005)(86362001)(53936002)(476003)(3480700005)(6916009)(606006)(14454004)(236005)(54896002)(6306002)(446003)(9686003)(97736004)(486006)(72206003)(55016002)(11346002)(99286004)(25786009)(316002)(2906002)(76176011)(8676002)(81166006)(81156014)(186003)(6116002)(6246003)(33656002)(6506007)(3846002)(53546011)(105586002)(7736002)(102836004)(26005)(7696005)(106356001)(790700001)(478600001)(8936002);DIR:OUT;SFP:1101;SCL:1;SRVR:BN6PR09MB1202;H:
> BN6PR09MB1203.namprd09.prod.outlook.com
> ;FPR:;SPF:None;LANG:en;PTR:InfoNoRecords;A:0;MX:1;
> > received-spf: None (protection.outlook.com: doccs.ny.gov does not
> designatepermitted sender hosts)
> > x-ms-exchange-senderadcheck:
> 1zRbjbDBbanxwjSRVF5qKGxF54I7Bu7ZQ3vIRcOUI9L7vRomLC/cG8IOeZFp0esKWHzFGde4ogl9tG/41W1d1iiXb7cei5S0Lv+Y4oTlamb5wxvOmqIX+CddW0GeLIcNPDQuI1CQmGTuJ3JoIhKWIewFV0svGsD5fJTeTwAYn0xEN6A47M4lQ0mYE4t4n4amiyhNI6FQa8qHU28pg56Hu9qxmeVUQCAv6LoqqS9eLCtEHSZlD+Y0c7cjSWUoRDqbmDrn+iVUevh9dPOdS8ahmtIXlOKE/t+wrPCyOt/0cHoyiOGC0F9b5IzE3yz66XsFP
> > spamdiagnosticoutput: 1:99
> > spamdiagnosticmetadata: NSPM
> > Content-Type:
> multipart/alternative;boundary="_000_BN6PR09MB12035CECDBD9887F8B20678BA4840BN6PR09MB1203namp_"
> > MIME-Version: 1
> > X-OriginatorOrg: doccs.ny.gov
> > X-MS-Exchange-CrossTenant-Network-Message-Id:
> d7791c0a-e60c-4f00-66bd-08d676fc880c
> > X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Jan 2019
> 13:07:10.5423(UTC)
> > X-MS-Exchange-CrossTenant-fromentityheader: Hosted
> > X-MS-Exchange-CrossTenant-id: f46cb8ea-7900-4d10-8ceb-80e8c1c81ee7
> > X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR09MB1202
> >
> >
> > On Fri, Feb 1, 2019 at 3:19 AM Дилян Палаузов <dilyan.palauzov_at_aegee.org>
> wrote:
> > > Hello Ken,
> > >
> > > despite being asked, you do not share the exact header, that cannot be
> parsed.
> > >
> > > In order to do anything further, I repeat this for third and last
> time, you need to be in a possession of a message that
> > > fails validation with OpenDKIM. Send this message to
> ymail/gmail/hotmail and see if they validate it.
> > >
> > > If you are not in a possession of such a message, and you cannot
> obtain it, if you don’t share the failed AR-headers,
> > > then nobody can help you further.
> > >
> > > Regards
> > > Дилян
> > >
> > > On Thu, 2019-01-31 at 21:40 -0500, Ken wrote:
> > > > > To my knowledge, OpenDKIM does not parse AR-headers, it inserts
> AR-header, which OpenDMARC parses.
> > > >
> > > > Jan 10 15:36:42 weaver sm-mta[28855]: x0AKafla028855: from=<
> angelo.fazzina_at_uconn.edu>, size=13144, class=0, nrcpts=1, msgid=<
> BN7PR05MB5859DDA9E65680D1B18A8C4A98840_at_BN7PR05MB5859.namprd05.prod.outlook.com>,
> bodytype=7BIT, proto=ESMTP, daemon=MTA, relay=
> mail-eopbgr750108.outbound.protection.outlook.com [40.107.75.108]
> > > > Jan 10 15:36:42 weaver opendkim[4235]: x0AKafla028855:
> mail-eopbgr750108.outbound.protection.outlook.com [40.107.75.108] not
> internal
> > > > Jan 10 15:36:42 weaver opendkim[4235]: x0AKafla028855: not
> authenticated
> > > > Jan 10 15:36:42 weaver opendkim[4235]: x0AKafla028855: failed to
> parse authentication-results: header field
> > > > Jan 10 15:36:42 weaver opendkim[4235]: x0AKafla028855: bad signature
> data
> > > > Jan 10 15:36:42 weaver sm-mta[28855]: x0AKafla028855: Milter insert
> (1): header: Authentication-Results: weaver.campbus.com;\n\tdkim=fail
> reason="signature verification failed" (1024-bit key) header.d=
> uconn.onmicrosoft.com header.i=_at_uconn.onmicrosoft.com header.b=IbXOR6Eh
> > > > Jan 10 15:36:42 weaver opendmarc[19796]: x0AKafla028855: uconn.edu
> none
> > > > Jan 10 15:36:42 weaver sm-mta[28855]: x0AKafla028855: Milter insert
> (1): header: Authentication-Results: weaver.campbus.com; dmarc=none
> (p=none dis=none) header.from=uconn.edu
> > > >
> > > > > Please clarify
> > > > > * where does that unparsable Authentication-Results header
> originate from
> > > >
> > > > Microsoft presumably
> > > >
> > > > > how the header looks exactly
> > > > > If yahoo/gmail/hotmail validate the unchanged email, then the
> problem is probably with opendkim/your site.
> > > >
> > > > It's not my end. Microsoft emails are the only messages the server
> receives where there's consistent issues.
> > > > I'm also not the only one seeing this issue.
> > > >
> > > > http://lists.opendkim.org/archive/opendkim/users/2018/12/3776.html
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > On Thu, Jan 31, 2019 at 7:01 PM Дилян Палаузов <
> dilyan.palauzov_at_aegee.org> wrote:
> > > > > Hello,
> > > > >
> > > > > you write, that
> > > > > 1. OpenDKIM is unable to parse AR-header,…
> > > > > 2. resulting OpenDMARC to fail
> > > > >
> > > > > To my knowledge, OpenDKIM does not parse AR-headers, it inserts
> AR-header, which OpenDMARC parses.
> > > > >
> > > > > Please clarify
> > > > > * where does that unparsable Authentication-Results header
> originate from,
> > > > > * what is OpenDKIM supposed to do with it,
> > > > > * how the header looks exactly,
> > > > > * how does the header inserted by OpenDKIM look exactly, and
> > > > > * whether forwarding unchanged/redirecting/sending the problematic
> mail to yahoo/gmail/hotmail does validate DKIM-
> > > > > Signature?
> > > > >
> > > > > If yahoo/gmail/hotmail validate the unchanged email, then the
> problem is probably with opendkim/your site.
> > > > >
> > > > > OpenDKIM is offered in source code. You can ask your distribution
> to include that patch. The patch was usable at the
> > > > > time and is integrated in the develop branch (
> https://github.com/trusteddomainproject/OpenDKIM/commits/develop).
> > > > >
> > > > > I am not an oracle to tell you, whether it is better to integrate
> the three-years-old patch yourself, wait for a new
> > > > > stable OpenDKIM version to be released and offered by your
> distribution, or to contact your distribution to integrate
> > > > > just the significant patches.
> > > > >
> > > > > Regards
> > > > > Дилян
> > > > >
> > > > > On Thu, 2019-01-31 at 17:13 -0500, Ken wrote:
> > > > > > > From the discussion on this mailing list from January 2019, I
> could not understand:
> > > > > > > - Does OpenDKIM sign in a way, that other software does not
> validate, or
> > > > > > > - does OpenDKIM not validate, emailis signed by Microsoft?
> > > > > > > - does the TXT record to be queried for validating
> DKIM-Signature exists in reality and OpenDKIM does not obtailn it for
> > > > > > > the purposes of validation?
> > > > > > > - Who creates that Authentication-Results (AR):, that cannot
> be parsed by OpenDKIM? If other sites creates them, then
> > > > > > > the local system shall add its own AR header and ignore what
> the other site inserted.
> > > > > > > - Does the validation work, if the same email is sent to
> hotmail, google and yahoo?
> > > > > >
> > > > > > The only issue I'm seeing is with messages signed by Microsoft
> do not validate.
> > > > > > OpenDKIM is unable to parse the authentication-results: header
> field resulting in OpenDMARC failing to verify the messages signature
> > > > > >
> > > > > > > In the posted example, DNS TXT selector1-Q2e-onmicrosoft-com._
> domainkey.Q2e.onmicrosoft.com exists now, perhaps the local DNS server
> cannot fetch it.
> > > > > >
> > > > > > No, that was the first thing I thought of. DNS resolves them
> with no problem.
> > > > > >
> > > > > > > but opendkim 2.10.3 normalizes it to "Header:<new line>text".
> > > > > > >
> > > > > > > This is fixed on the develop branch, with opendkim 2.10.3
> validation will fail, cf.
> > > > > > > https://sourceforge.net/p/opendkim/bugs/226/ .
> > > > > >
> > > > > > This may very well be the cause of the problem. Is the patch
> usable? Or is it better to just wait for an official release at this point?
> > > > > >
> > > > > > > The persons in TDP are currently overloaded.
> > > > > > > TDP is non-for profilt orginizations.
> > > > > >
> > > > > > That explains a lot. The efforts of everyone involved at TDP is
> greatly appreciated
> > > > > >
> > > > > >
> > > > > > On Thu, Jan 31, 2019 at 3:32 PM Дилян Палаузов <
> dilyan.palauzov_at_aegee.org> wrote:
> > > > > > > Hello,
> > > > > > >
> > > > > > > Microsoft tends sometimes to send emails like:
> > > > > > >
> > > > > > > Header:<new line>
> > > > > > > <spaces/tabs>text
> > > > > > >
> > > > > > > which under relaxed canonization is converted to
> > > > > > >
> > > > > > > Header:text
> > > > > > >
> > > > > > > but opendkim 2.10.3 normalizes it to "Header:<new line>text".
> > > > > > >
> > > > > > > This is fixed on the develop branch, with opendkim 2.10.3
> validation will fail, cf.
> > > > > > > https://sourceforge.net/p/opendkim/bugs/226/ .
> > > > > > >
> > > > > > > The README was recently updated to describe cases, where
> sendmail can break the signatures.
> > > > > > >
> > > > > > > My reading of RFC 6376, section 3.2:
> > > > > > >
> > > > > > > tag-list = tag-spec *( ";" tag-spec ) [ ";" ]
> > > > > > > tag-spec = [FWS] tag-name [FWS] "=" [FWS] tag-value [FWS]
> > > > > > >
> > > > > > > is that whitespaces can be left out. So v=;a=;c=; without
> spaces and with content after the equal sign is
> > > > > > > syntactically valid.
> > > > > > >
> > > > > > > From the discussion on this mailing list from January 2019, I
> could not understand:
> > > > > > > - Does OpenDKIM sign in a way, that other software does not
> validate, or
> > > > > > > - does OpenDKIM not validate, emailis signed by Microsoft?
> > > > > > > - does the TXT record to be queried for validating
> DKIM-Signature exists in reality and OpenDKIM does not obtailn it for
> > > > > > > the purposes of validation?
> > > > > > > - Who creates that Authentication-Results (AR):, that cannot
> be parsed by OpenDKIM? If other sites creates them, then
> > > > > > > the local system shall add its own AR header and ignore what
> the other site inserted.
> > > > > > > - Does the validation work, if the same email is sent to
> hotmail, google and yahoo?
> > > > > > >
> > > > > > > In the posted example, DNS TXT selector1-Q2e-onmicrosoft-com._
> domainkey.Q2e.onmicrosoft.com exists now, perhaps the
> > > > > > > local DNS server cannot fetch it.
> > > > > > >
> > > > > > > To the curios of you, asking why there is no OpenDKIM release
> made, that includes the fix for the for-3years-known-
> > > > > > > immediate-newline-after-the-colon and other errors, my
> information is:
> > > > > > >
> > > > > > > - OpenDKIM is managed by the Trusted Domain Project (TDP) and
> any change on the code means legal obligations for the TDP
> > > > > > > in terms of IP, bylaws, and some requirements towards the code
> quality. The persons in TDP are currently overloaded.
> > > > > > > TDP is non-for profilt orginizations. For half a year or so
> TDP is looking for additional persons to work on TDP. This
> > > > > > > persons have to be local, meaning more or less that only if
> one lives in San Francisco, has preferably also written some
> > > > > > > RFCs, and is not overloadad, will s/he be entitled to release
> a new version OpenDKIM, that is to the current knowledge
> > > > > > > error-free.
> > > > > > >
> > > > > > > For the record, linking with libunbound for doing DNSSEC
> fetches within opendkim, neither the code on master nor on the
> > > > > > > develop branches works, cf.
> https://github.com/trusteddomainproject/OpenDKIM/issues/14.
> > > > > > >
> > > > > > > Regards
> > > > > > > Дилян
> > > > > > >
> > > > > > >
> > > > >
> > >
>
>
Received on Fri Feb 01 2019 - 20:35:48 PST