On Mon, 23 Jan 2006, Stuart D. Gathman wrote:
The SRS/SES plan is simple, the original localpart is everything after
the last '='. Recognizing whether the localpart is, in fact, signed
is not that critical, since the policy can simply compare both
before and after extraction.
Its not that simple, the scheme should at the very least provide for
standard way to express the scheme name and where its data is (which
to be fair both srs and ses do).
However, there seem to be a number of localpart coding schemes that do not
follow the SRS/SES plan.
1) What are the common localpart coding schemes other than SRS and SES?
2) How many different markers for the original localpart are there
(that we know about)?
VERP (several forms), SRS (several forms), SES, BATV
3) Should establishing a standard separator for localpart signing
prefixes be a future goal of SPF (after current RFC, yada, yada)?
Yes we should. I mentioned it on the list several times before and
on ASRG and at mipassoc's clear (they don't have separate batv list).
I think there is not much chance of reconciling with BATV folks
(and it has not been adopted beyond John's system) so we should just
go ahead and write document that reconcile common from SRS & SES.
Actually I think the documents should be as follows:
1. General documents for adding specialized "tags" (better worth
maybe worth looking for...) in the ReturnPath or for that
matter as part of some other email address field
2. Document describing SRS concept and referencing #1 (and SPF) to
provide scheme for its encoding.
3. Document describing SES concept (as being private signature) and
referencing #1 to provide scheme for its encoding.
4. Document describing SES address public verification system (i.e. dns
verification) and referencing #4 and SPF with how it can be used
Or is it too far off topic? It seems too trivial to have its own RFC.
No, its not trivial at all. And experimental RFC is exactly the right
pass for it.
Where should such a standard go?
IETF if they are willing to accept it (to be honest after number of
recent events I'm not so sure about IETF, but I see nothing better
nearby either...)
--
William Leibzon
Elan Networks
william(_at_)elan(_dot_)net
-------
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