> >> An issue that I have been thinking on - and it is the reverse of this
> >> discussion - is that it is operationally difficult to maintain accurate SPF
> >> records for organizations with a lot of domains where the SPF records vary
> >> across the domains. I recently found this situation with one of our
> >> domains (an
> >> acquisition). This is similar to other situations where organizations are
> >> fairly good with adds and changes but not so much with deletes. This isn't
> >> anything that can be addressed through an RFC but I think it is worth
> >> noting.
> >
> > <chair hat off>
> I was surprised to see you take your chair hat off when responding to a
> discussion of scope. Being still fairly green when it comes to IETF process
> I’m not sure about this, but I would have presumed one role of the chair is to
> help ensure the WG stays within its approved scope.
Your presumption is correct.
> I’m asking about thi because I believe managing scope is critically
> important to the success of this WG and I’d like to know who plays what
> role in helping us stay on track. Thank you.
That would be the chairs.
> > This looks to me to be an operational issue with deploying SPF at scale.
> > This
> > WG"s charter is pretty specific that we're focusing on issues caused by
> > "mail
> > that does not flow from operators having a relationship with the domain
> > owner,
> > directly to receivers operating the destination mailbox". I don't see how
> > this
> > fits within that scope.
> >
> > So, while I'm sympathetic to the difficulties using SPF in this way,
> > I don't think it's in scope for the present effort.
> >
> > Ned
> The charter also states the WG "will also provide technical implementation
> guidance and review possible enhancements elsewhere in the mail handling
> sequence that could improve DMARC compatibility.” While I’m personally not
> too
> concerned about deploying SPF at scale, I am concerned about this particular
> aspect of the charter and preserving it. If we forget this aspect of our
> charter then we are left with nothing in our toolbox but to change DMARC
> itself
> to accommodate MLM’s and other "mail that does not flow from operators having
> a
> relationship with the domain owner, directly to receivers operating the
> destination mailbox” with no ability to at least “guide” other processors
> toward practices that would help them improve their compatibility with DMARC.
So let me see if I understand you correctly. You were surprised that I posted
a query (not an assertion) about something being in scope in my capacity
as a WG participant rather than as chair. And you are concerned that
there be effective scope management.
But at the same time you're concerned that we not tighten the scope so much as
to exclude implmentation guidance that you view as an important tool in
addressing DMARC issues.
If that's correct, then I confess I completely fail to understand your
concern/point here. The reason I posted as a participant and not as chair was
precisely because I *didn't* want to make an ex cathedra statement about the
appropriateness of discussing this SPF issue.
What I wanted was feedback as to whether or not people consider SPF deployment
advice on this issue to be in scope of the WG. I received one private response
to that agreeing that it isn't in scope and notihng on the list. And since
public discussion of that point has ceased, further consideration of the matter
seems moot.
Finally, in regards to the implementation advice aspect of our work, and again
speaking as a participant, I don't see how this particular issue meets the
criteria for that either since it has everything to do with not sending out
bogus SPF information and nothing to with with the interaction of SPF with
DMARC.
Ned
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
