At 04:43 PM 5/19/2005 -0700, william(at)elan.net wrote:
On Thu, 19 May 2005, David MacQuigg wrote:
Who said anything about random identities? Did you read the draft, or
just the noise in the discussions?
Read it, its bad. Both the idea and the implementation text is not compatible.
The fundamental flow is assuming that authorization means authentication
and that it does not matter what you authorize.
The declared Identity is the one accepting responsibility for the
transfer. Other identities may be checked, as required by the various
methods, but if the result is PASS, the declared Identity accepts
responsibility. Example: If the declared Identity offers only a
DomainKey, don't waste time checking the EHLO or MAIL FROM identities.
That is exactly the problem that I'm talking, you do not understand about
identities and you also do not understand that there is no one "declared"
identity it all depends on what you're going to do and what you're trying
to protect.
OK, let's nail this down. Here is the example incoming email, with the
proposed ID command. Assume you have no prior relationship with the
sender, so you don't know what authentication method he uses.
EHLO mailserver7.bigforwarder.com
ID bigforwarder.com
MAIL
FROM:<<mailto:bob(_at_)sales(_dot_)some-company(_dot_)com>bob(_at_)sales(_dot_)some-company(_dot_)com>
Without the ID command, you will waste a bunch of DNS queries and possibly
conclude this sender offers no authentication. For each possible Identity
(mailserver7.bigforwarder.com, bigforwarder.com, sales.some-company.com,
some-company.com) you need to search every possible location for DNS
records (<Identity>, _client._smtp.<Identity>, ...), and we still haven't
searched all the header identities. This is what I mean by DNS "hunting" -
searching for records that may not be there.
With the ID command, the receiving MTA does a DNS query for a TXT record at
a standard location, like _AUTH.bigforwarder.com.mail.net The query
returns a record that specifies exactly what methods are supported by the
owner of the Identity.
Now tell me what is wrong with this.
--
Dave
************************************************************ *
* David MacQuigg, PhD email: david_macquigg 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 *
************************************************************ *