Seth, Selectively quoting of comments and not answering any technical
comments or questions should also not be tolerated. It waste people
time especially which rudely told we lack substance and credibility.
This damages people's reputation when he torts engineers in these IETF
forums.
Did you say anything to him? Should that be tolerated?
I'm trying my best to participate without the snide remarks and
reputation hurting remarks. I take it very personal because I have
seen how it can
hurt people. He should stop doing that.
--
Hector Santos, CTO/CEO
Santronics Software, Inc.
https://secure.santronics.com
https://twitter.com/hectorsantos
On 9/30/2020 10:37 PM, Seth Blank wrote:
Hector, please constrain your comments to the technical matters at
hand, not the actions of others.
This thread is veering towards ad hominem attacks which will not be
tolerated.
Seth, as Chair
On Wed, Sep 30, 2020 at 7:12 PM Hector Santos
<hsantos=40isdg....@dmarc.ietf.org <mailto:40isdg....@dmarc.ietf.org>>
wrote:
On 9/29/2020 6:54 PM, Dave Crocker wrote:
> On 9/29/2020 3:41 PM, Hector Santos wrote:
>>
>> Do you have an algorithm that replaces the current one?
>
> I've no idea what any of your note has to do with the DKIM protocol
> specification.
wow.
> By way of a small example, DKIM does not have o=.
Right, you were instrumental in attempting to "separate" policy from
DKIM to create DKIM-BASE, a success, it allowed progress to be made
with DKIM, but it never separated the signer::author identity
association primarily because, once again, DKIM-BASE is still
inherently bound to the 5322.From field. You never separated the
DKIM
anchor identity and it was stated many times, until then, we will
always have the signer::author relationship and policy protocols
based
on this relationship.
Until it is changed, DKIM will always have this self-signed
signer::author relationship. That goes back to DomainKeys with o=,
early DKIM with o=, removed in DKIM-BASE as you gracefully pointed
out
but it moved to ADSP (now DMARC).
> But really, nothing in your note concerns the published and approved
> specification.
Published and approved, yet seeking further comments. From I had
already read and understood from the start, all in once sentence:
Extract 5322.Sender, if found, use this for DMARC lookup, if not
found, fall back to 5322.From
Correct? Anything else?
The only systems that this will work with is compliant downlink
receivers. Non-compliant receivers are still a problem. At the end
of the day, the Mailing List Server (MLS) still needs to support
DMARC
on the inbound side.
--
Hector Santos,
https://secure.santronics.com
https://twitter.com/hectorsantos
_______________________________________________
dmarc mailing list
dmarc@ietf.org <mailto:dmarc@ietf.org>
https://www.ietf.org/mailman/listinfo/dmarc
--
*Seth Blank*| VP, Standards and New Technologies
*e:*s...@valimail.com <mailto:s...@valimail.com>
*p:*415.273.8818
This email and all data transmitted with it contains confidential
and/or proprietary information intended solely for the use of
individual(s) authorized to receive it. If you are not an intended and
authorized recipient you are hereby notified of any use, disclosure,
copying or distribution of the information included in this
transmission is prohibited and may be unlawful. Please immediately
notify the sender by replying to this email and then delete it from
your system.
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
