Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field

[Seth Blank <[e-mail]>]

Hector, the chairs hear your frustration, thank you for not escalating
further, and would be happy to speak with you off list on the matter.


On Wed, Sep 30, 2020 at 8:05 PM Hector Santos <hsantos=
[e-mail]> wrote:

> 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=[e-mail] <mailto:[e-mail]>>
> > 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
> >     [e-mail] <mailto:[e-mail]>
> >     https://www.ietf.org/mailman/listinfo/dmarc
> >
> >
> >
> > --
> >
> > *Seth Blank*| VP, Standards and New Technologies
> > *e:*[e-mail] <mailto:[e-mail]>
> > *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
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/dmarc
> >
>
>
>

-- 

*Seth Blank* | VP, Standards and New Technologies
*e:* [e-mail]
*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.