On Tuesday, May 12, 2015 12:16:19 AM Hector Santos wrote:
> On 5/11/2015 10:17 PM, Stephen J. Turnbull wrote:
> > Scott Kitterman writes:
> >   > Actually, the idea behind MARID was to come up with a single
> >   > solution
> > 
> > Is there something we can learn from MARID?  I don't see it in the
> > context of the current discussion, as MARID had little to say about
> > third parties (it treated them as first parties, and handled third
> > party issues by suggesting "certification registries"), and explicitly
> > disclaimed authentication of authorship claims.
> 
> MARID main trust was with SPF and CEP (Micrsoft's XML version of SPF
> renamed to SenderID when it was changed to a SPF syntax), but the
> MARID group was open to other proposals to compete with the SPF
> solution.  Those other proposals included:
> 
>      - Domainkeys that included a simple always/sometimes sign policy,
>      - DKIM, a better Domainkeys with extended third party policies,
>      - CSV/DNA, an SMTP EHLO level Reputation Method.
> 
> These were the first introductions of the idea for Signature TRUST
> MODEL and the chain of trust which eventually became the main focus in
> the DKIM-WG working group.
> 
> But the main focus in MARID was with the SPF idea and there was
> outputs from MARID -- a direction to complete the four RFCs and to
> treat them as experiments:
> 
>      RFC4405   SUBMITTER SMTP Service Extension
>      RFC4406   Sender ID: Authenticating E-Mail
>      RFC4407   Purported Responsible Address (PRA)
>      RFC4408   Sender Policy Framework (SPF)

Don't take my word for it.  Here's the list of active/published documents for 
MARID:

https://datatracker.ietf.org/wg/marid/documents/

[Note to save everyone time, none are listed]

As indicated when the working group closed [1] none of the follow-on 
experimental documents were products of the working group, in fact, deviations 
from what the working group had agreed on were the source of one appeal.

[1] http://www.imc.org/ietf-mxcomp/mail-archive/msg05054.html

Going back and trying to justify things in this working group based on a 
revisionist history of a decade old failed working group isn't going to get us 
anywhere.

Scott K

_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc

Reply via email to