-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
David MacQuigg wrote:
At 12:19 PM 5/22/2005 +0200, Julian Mehnle wrote:
My point is that even if a receiver always checks SPF first, it
won't avoid a DNS hunt. We can't assume that the owner/admin of a
domain/subdomain in the MAIL FROM identity has published an SPF
record just to tell us which other method he/she uses.
You are valuing not having to do a single DNS lookup (in order to find
out _if_ SPF can/should be used at all) over the receiver's freedom to
choose what authentication mechanism he finds useful. This evaluation
of yours is absolutely unpractical.
I think you may still have an "SPF only" perspective on this. If the
receiver does SPF only, then your are right. The question is simply -
Does this ID have an SPF record? In general, most receivers will have
available whatever methods are popular.
I think this is a misconception of yours. Receivers will only try those
authentication methods that they think are useful, for whatever definition
of "useful". Just look at how receivers are filtering spam: one receiver
uses SpamAssassin to filter all spam client-side and curses IP-address-
based blacklists, another does the reverse, rejecting mail server-side.
It will work the same way when it comes to sender authentication systems
such as SPF, DomainKeys, and CSV. The market is the receivers, not the
senders or the identity owners. And although it may theoretically be
possible to make the identity owners the market, it is definitely
unpractical to ask the senders for what they want, because the senders are
those who are generally untrustworthy and who we want to authenticate.
So without an explicit ID declaration, it will have to hunt for
authentication records in many places, like _client._smtp.<ID>.
We all understand this, and it really isn't as elegant as one might wish.
But I don't see how we could allow the _senders_ to determine what
authentication methods receivers should use. What if the identity owner
offers all of SPF, DK, and CSV, but the sender (let's assume a spammer)
chooses to only say "ID: CSV" because CSV is the least expressive or the
least strict of all? What if the receiver doesn't support CSV? Should he
then treat it like "ID: none" (or no "ID" statement, for that matter)?
The receiver never has complete freedom to choose the authentication
method.
Of course not, but at the end of the day, _receivers_ will decide in which
authentication methods they trust and which methods are too weak. Then
identity owners will have to follow. Hopefully, senders will have nothing
to say in it.
The ID owner specifies the methods, and the receiver gets to chose from
what is offered. My guess is that most receivers will have available any
authentication method that is being actively promoted and supported.
That would only be true if all authentication methods were equivalent. But
they aren't, and there are huge disputes over which methods are best.
"ID none" should be an immediate reject. I wouldn't accept mail from
any sender that says - "I know you want my ID, but I'm not going to
give it to you."
This makes your proposal 100% backwards incompatible to the current
system.
I don't understand what you mean by "backwards incompatible". Older
systems will not use the ID command at all. The SMTP client will not
send this command unless the SMTP server says in it's EHLO response that
it will be accepted.
So what about legacy clients that don't support it? Will those be
rejected, too? If no, what about clients (senders) that deliberately
choose not to support it to avoid having to offer some authentication
method they know they can't pass?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
iD8DBQFCkJpEwL7PKlBZWjsRAi0CAJ9bug6ffP655D9qmD23+bGs6EYgZwCeMZCj
j9HZS6xqm6BE3k54IHaQYiw=
=Ahrf
-----END PGP SIGNATURE-----