On 11/21/2014 12:56 PM, Tim Draegen wrote:
WG,
The work found here:
http://trac.tools.ietf.org/wg/dmarc/trac/wiki/MilestoneOneWiki
..is almost complete. However, there is a note (reinforced by
feedback during the recent in-person meeting) to recast the collected
issues in terms of RFC 5598. Once this recasting is done, Milestone 1
will be officially met.
If you’re handy with the language found in RFC 5598, please consider
helping out. Getting the language correct now will only make
everything better later on.
Hi Tim,
I did participate and was acknowledged in the production of RFC5598.
Since I like to get my main points out of the way, here goes.
One of my very few concerns at the time I envisioned during RFC5598
production is that its used SIEVE as its baseline "IETF" standard
language for hooking in scripts. Understood, the email architectural
document wanted to cover IETF sanctioned protocols and documents.
Thats not the case in reality with different system using different
server-side hooking language. In addition, it made an assumption that
POST SMTP (after the mail is accepted) processing was the way things
were done. See Figure 5: "Protocols and Services." When RFC5598 was
produced "SPF" was still a "TABOO" among the IETF key cogs. It was a
new "experiment" so clearly it was not going to get the attention it
needed for an example of SMTP dynamic processing (before acceptance).
It is a known fact, many of the key IETF folks were against SPF at
the time.
So the idea of spawning a job, shim, hook, what have you off SMTP
states was still something that was still not widely acceptable. You
had to be an advanced package to do this, a more nimble
package/vendor/service to explore the more modern stuff. In fact,
some folks was surprised to learn, dynamic SMTP filter processing was
indeed increasing in practice when SPF was becoming more popular and
DKIM itself began to be deployed at the DATA state hence raising
issues about increasing SMTP session TIME delays. Major discussions
about this about delaying/scaling high throughout systems. We have an
very old RFC that raise that point about increasing sessions time that
could cause SMTP client drops to occur, hence concerns about dupes,
etc. I felt that better hardware and speeds was changing all this
which is why DKIM and DMARC are now possible at DATA today.
SIEVE, at the time, also didn't have DNS lookup capabilities so that
would need to be added to the SIEVE language if it wants to be used as
an example IETF sanction scripting tool for add-on protocols, like
SPF, DKIM and DMARC, and even DNS RBL stuff.
In short, RFC5598, nearly a 10 year old document itself, does need
updating itself to FIT the more modern DYNAMIC SMTP level and data
filtering models in existence today. The SIEVE description in
section 4.1.0 added at the time, I considered "open-ended" enough to
not be terribly locked down, but it does need updating. RFC5595 needs
to be more open-ended in this regard.
The whole idea of how any SMTP LEVEL FILTER and/or POST SMPT (POST
ACCEPTANCE) FILTER is done should be talked about at length because
that is how its going to be different among systems, including whether
or not they can actually do the stuff we want to do with a multiple
protocol add-on DMARC Policy layer. Just consider what the
programmers are using for the scripting tools. You are seeing LUA out
there now. But you are not going to see that with other systems. It
shouldn't matter what they use, all this needs to be generalized. But
the key point, not all of them is going to be using SIEVE.
PS. A group of editors spontaneously formed during the in-person
meeting. The group will tackle Milestone 2 — which is to transform
issues learned and documented in Milestone 1 + proposed solutions for
each into a real reviewable draft. This is not a closed group, so if
you’d like to be actively involved, just say so.
I prefer to review the ideas before they are written and burned in
stone, because if there is one thing I learn among the authors here,
once its written, its very hard to correct at that point. Too high a
burden. Many of the key problems we have today with DKIM is because of
exactly this point, the document were changed and it was now a higher
burden to make the corrections, i.e. the importance and exclusion of
the Author Domain Identity from the DKIM specification, getting that
idea back into the equation was lost, hence the problem we have today.
DKIM is a TRUST document. DMARC is about SELF-SIGNING POLICY
document. I also consider SPF a DOMAIN POLICY specification. DKIM
excluded the self-signing part (when the IETF draft standard was ADSP)
and was left only with TRUST model. Ideally that fine, but think
code. If one is only looking at DKIM, SPF and not ADSP, oops, I mean
DMARC, then passing the author to the filtering components is less
important. Designers need to know, the author identity is part of the
software interfacing and that means DATA and/or POST SMTP processing.
DKIM itself SHOULD be updated (perhaps an errata) to get the model
corrected for passing the one required binding header 5322.From passed
into the assessment model.
--
HLS
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
