william(at)elan.net wrote:
2. Formal documentation of sender rewriting (SRS)
Yes, I like this, Meng's old SRS draft is a bit old.
4. Documentation on how to use SPF to indicate of ip address
should not be involved in sending email (SPF PTR, similar
concept to MTAMARK)
That sounds difficult. The "namedroppers" just discuss some
"reverse DNS required" draft, Stephane still hates it. Markus
doesn't like SPF. Some don't like the ASRG. If it's almost
impossible to find a place where folks would talk together I'm
not very optimistic about any results.
5. Document putting it all together that describes how to do
verification of authorization during SMTP session
SIQ could be a part of "putting it all together". Some texts
how to use only relevant parts of v=spf1 could make sense:
SPF HELO alone or in combination with MAIL FROM. Combine SPF
HELO PASS with white lists. SPF FAIL policies without PASS
(addressing Scott's HARDPASS issues). Dito SPF PASS policies
without FAIL (pure white listing concepts). How to abort SPF
evaluations for "too complex" or "irrelevant" policies. The
whole field of "receiver policies" making any sense at all,
e.g. if a receiver considers anything but FAIL as "irrelevant"
it's fine. Considerations for working post-SMTP uses of SPF.
I think we should also start (slowly) working on next
version of SPF that would have scoping system
Scoping is unnecessary for SMTP, there are only four variables,
HELO id., MAIL FROM id., RCPT TO id, and the sending IP.
The RCPT TO is only relevant for stuff like a "forward master
plan" bypassing SPF checks, so it's actually only 3 variables,
all already completely covered by v=spf1.
But Scott's idea of some "DKIM STRONG" shortcut is interesting:
Receivers could abort SPF checks when they see this, later test
the DATA for a STRONG DKIM signature, and if it's not there or
invalid reject at the end of DATA.
For PS we could need interoperability reports, lessons learned
from the "experiment", maybe parts of a conformance test suite.
There won't be a "next version" of SPF, not in this decade, at
best we get a simplified v=spf1.1 (as proper subset of v=spf1).
I think we should setup system that allows SPF documents to
be submitted in similar ways to how Jabber is doing it with
JEP documents (http://www.jabber.org/jeps/jeplist.shtml).
Similar to IETF I think this should allow both for individual
submission, but also should allow for documents to be done as
part of SPF group activity.
Yes, that's a good idea. E.g. the options could get some kind
of "registry" allowing to add new ideas by submitting separate
drafts.
A hypothetical op=dkim deserves its own draft, it has lots of
traps and pitfalls in conjunction with mailing lists that have
nothing to do with the traps and pitfalls for say op=pra.
Other texts that could be interesting: A more radical version
of draft-hutzler wrt reject and recommending 2476bis with 6.1.
Maybe an explanation of the pre-1123 history of forwarding,
why it worked in theory, why and how 1123 5.3.6.a broke it,
and how SPF FAIL tries to fix it. Without this latter point
that could be a part of the 2821bis effort, all historical
crap and its priciples of operation extracted from 2821, the
rest is more manageable for 2821bis.
And BTW, your "original" stuff also needs to be finished.
Not directly related to SPF, but somehow still in the spirit
of "fixing SMTP". Hector proposed some BCP for mailing lists.
Tons of stuff that could be done. But no "scopes" <shudder />
Bye, Frank
-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to
http://v2.listbox.com/member/?listname=spf-discuss(_at_)v2(_dot_)listbox(_dot_)com