Meng Weng Wong wrote:
So, while we work on the fun development side of things,
like SES, op=, and bashing PRA, we need to keep getting SPF
and SRS into MTAs
The "funny" op=trusted was essentially your idea to solve the
forwardig issue, and among the "funny" people disliking SRS for
various reasons were the admin of the university of Cambridge
and the admin of a German university.
For some more "funny" PRA-bashing see also chapter 6.2 in
<http://www.libsrs2.org/srs/srs.pdf>, the part ending with:
| SUBMITTER is therefore bad and should be excluded from any
| future protocol.
I've no idea about the "fun" factor in SES, but somebody said
here that PRA breaks it.
Everything else is secondary to the success of the project.
An RfC is essential for the project, because what sticks after
MARID is "too broken for the IETF". Only geeks know that MARID
never really discussed SPF (minus one week before it was closed
without consultation with the WG), and if you now think again
that SRS is important something better than an PDF or the old
draft-mengwong-sender-rewrite-01.txt might be essential. The
list on <http://www.libsrs2.org/status.html> doesn't claim to
cover all mailers.
Are they really all "opensource advocates", the "funny" folks
like Hector, you, Scott, and William, whose ideas are listed as
op= options ? Maybe James and Wayne really are, but they all
want an RfC. Even you, Jim, and Philip need it for Sender-ID
resp. for accredit=.
And there's nothing wrong with writing "unglamorous" websites
working with every browser, some of "us" do or did care about
this, e.g. a certain <http://www.seas.upenn.edu/~mengwong/>
the people who are involved in this project for fun have not
shown much interest in tackling it
Investing free time in something is not always "fun". And it's
not "funny" if 3rd parties twist the work into a technically
flawed business.
I continue to seek funding to pay professionals to do that
With a convincing idea like SPF you don't need this, they do it
because they want it as a feature in their free or commercial
products. They do need a spec. however, something changing
whenever they look at it is irrelevant. Professionals won't
accept any "CYA" attitude instead of a proper specification.
Those "funny" folks interested in anti-phishing might be also
interested in William's "eh" proposal. It certainly doesn't
depend on any "funny" op= stuff, it could be also something
like eh=from.sender. Only eh=1 and pra=yes would be "funny",
a general op=eh,pra enumeration for options is less messy.