John Glube wrote:
* Do we have a clear understanding of where it is we want
to go with spf2.0?
See Message-ID <0eeb01c4b1de$60d62700$0200000a(_at_)ringo> resp.
<http://article.gmane.org/gmane.mail.spam.spf.discuss/10822>
posted by Chris Haynes.
* Do we need a statement of work, along with estimated time
frames for work completion?
A public list of "known issues" would help. This list would
also contain "closed issues" (in the benevolent dictator IESG
model). Time frames might help in certain cases to enforce a
decision.
* Do we have any input documents?
mengwong-00 (historical), protocol-03 (informational),
letczner-00 (current working document), schlitt-00 (proposed
fixes for known issues in lentczner-00), kucherawa-00 (idea),
leibzon-00 (status TBD, but at least informational).
For more input about HELO we could use the CSV-drafts (?)
For more input about PTR we should read the MTAMARK draft.
If there are SRS resp. SES drafts, we want them as input.
My article with the properties modifier tried to summarize
four proposals by Hector, Meng, Scott, and William.
* Who is going to write up any input documents for
discussion, if none exist?
The authors (e.g. Mark, Wayne, William) resp. the editors
(Mark, N.N.).
* How will this work be reviewed? By the list? Do we need
discussion moderators?
By the future list "moderated" by the chair(s). But please
don't use the /mtr style with public moderations unless it's
absolutely necessary. The chair(s) and editor(s) identify
consensus, reflected in the public list of known issues and
the future current working document(s).
what is the fundamental problem in terms of the SMTP protocol
which is causing difficulty and what is the most effective
way of rectifying this problem, with the least overhead and
which is the easiest to implement?
The fundamental problems are forged MAIL FROM addresses, the
pitiful state of RfC 2821 allowing this, too many MAY in 2476,
and the solution for this part of the problems is SPF. And
maybe MASS resp. DK if William's 2822-idea doesn't fly. And
maybe something like MTAMARK.
Break "forwarding to third parties", it's fundamentally bad
like open relays. And like closing all open relays SPF won't
be the FUSSP.
* William's approach, supported by William's submitter
proposal; or
* an implementation using a signed envelope sender concept.
No, William's "eh" idea doesn't depend on his submitter idea,
these concepts are unrelated.
And an alternative to his submitter idea (for forwarders) is
Meng's "local white list" proposal (with a SPF-HELO test).
Bye, Frank
Subject to any objections, I believe it is appropriate that
Meng and Mark indicate their positions in response.