Michael Deutschmann wrote:
"This feature was intended so that a SMTP client could authenticate
*itself* to another {using the ordinary AUTH command}, yet indicate
that a given mail's origins were either not authenticated or
authenticated to be from somebody else {using the AUTH= argument
to MAIL FROM:}"
Yes, thanks, I missed the "yet..." part.
it's good for our purpose that AUTH= is per message, since this would
allow a forwarder MTA to collect messages which need different TENBOX
tokens attached and send them all in a single connection.
What's a "TENBOX token" ? In the AUTH RFC the AUTH= parameter value is
an <addr-spec>. 2554bis fixes that to a <Mailbox> as secified in 2821,
eliminating the optional CFWS (comments, folding, white space) in 2822.
[SMTP extension]
# Each service extension registered with the IANA must be defined in
# a formal standards-track or IESG-approved experimental protocol
# document.
Right, no SMTP extensions by independent submissions directly to the
RFC editor, or in other informational RFCs.
[SASL mechanisms]
# SASL mechanism name (or prefix for the family):
# Security considerations:
# Published specification (recommended):
# Person & email address to contact for further information:
# Intended usage:
# Owner/Change controller:
I've never looked at that one before, no expert review, first come -
first served, no RFC required. RFC 4422 let's IANA decide what they
like or don't like. Outrageous. Until today I thought that it's a
no-nonsense registry maintained by the SASL WG... :-(
for ESMTP it seems one must submit to the RFC sausage-machine to
bag a keyword.
At least that guarantees that there is a proper spec. (like 4405).
For the SASL registry it's only coincidence that nobody submitted
ROT13-LOGIN with "intended use: common" so far.
Well, you can apparently turn SPF PASS into a SASL mechanism if
that's what you really want. RFC 4422 recommends (lower case) an
I-D and public review. There are some simple "xml2rfc" examples
in the openspf repository, maybe start with...
http://www.openspf.org/svn/project/specs/drafts/draft-kitterman-spf-tbd-00.xml
...as template.
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/?list_id=735