At 10:11 PM 4/13/2005 -0400, Radu Hociung wrote:
Dave Crocker wrote:
What MIME types does a recipient support?
What servers does a target host support?
With extremely few exceptions, Internet mechanisms do not support a
test-before-using model.
If I read your reply correctly, you would support such an initiative which
would advertise what else is available.
My main point was that the absence of similar mechanisms suggests that it
might be difficult to create one for this case.
Such mechanisms seem inherently useful, so their absence from 35 years of
operational effort implies the presence of some barriers.
Would you not consider the HELO response an example of such a mechanism?
It communicates what the abilities of the server are.
How about the Accept: and Accept-language: mechanisms in HTTP GET
requests? (they list the MIME types that the browser can handle and the
content languages that the user can understand, respectively)
The ssh credentials negotiation might be a good example also (where the
server advertises what methods are available):
Authentications that can continue: publickey, password, keyboard-interactive
There may be other such examples too.
Dave's idea was to also provide a mechanism for a domain to list what
authentication/authorization methods it supports?
I must have missed something? Please point it out if so.
My proposal was limited to having the sender declare its Identity, and
avoid the confusion over which Identity the receiver should use in
authentication. I wouldn't object to having the sender also declare the
available authentication methods, but I don't see that as having any
benefit. This is based on my assumption that one query to the declared
Identity will always be the minimum, and that one query can return not only
the available methods, but most of the needed parameters as well.
This thread was originally about my proposal to respond to an IESG concern,
without compromising the principle that SPF records must be interpreted as
defined in the SPF spec. We then moved to the impossibility of adding
anything to the existing SMTP commands, and from there to the need to avoid
"hunting" for the authentication records.
Please let's continue the discussion above in the thread "Discovering the
Method". Unanswered questions in this thread include - What are the
barriers to adding a short string at the end of the HELO/EHLO and/or MAIL
FROM commands? Can we safely assume that current mail receivers will
simply ignore it along with all the other garbage they ignore? Or will
something actually break? What about the difficulty of modifying MTA
software so it will at least preserve the full commands, including any
appended ID= string?
--
Dave
************************************************************ *
* David MacQuigg, PhD email: dmquigg-spf at yahoo.com * *
* IC Design Engineer phone: USA 520-721-4583 * * *
* Analog Design Methodologies * * *
* 9320 East Mikelyn Lane * * *
* VRS Consulting, P.C. Tucson, Arizona 85710 *
************************************************************ *