On Thu, 19 May 2005, David MacQuigg wrote:
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>
How did you ever manage to invent that mailfrom syntax :)
Without the ID command, you will waste a bunch of DNS queries and possibly
conclude this sender offers no authentication.
He doesn't!!!!!
If sender wants to authenticate, he can just go ahead and use AUTH command,
Authentication involves mutual pre-negotiated trust.
On the other hand its the recipient that decides which identity (not
address, but identity type) it needs for whatever mechanism it wants to
use to find if client can be trusted (i.e. accreditation/reputation call).
Note that its important to understand that if there was no pre-negotiated
trust then all decisions should be left to recipient and nothing that
sender gives about its identity can be believed.
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.
The thing is if those identities involve different domains/addresses, you
still end up searching from all those locations. If they involve same
domain, there is some value in having lookup at one dns record instead of
several and be able to see policies for multiple identities and verification
records for different authorization methods (i.e. I agree with you that
there is value in putting cryptographic verification into SPF record as
modifier, but as I'm worried about size of such records, my preference
has always been on fingerprint data in dns, rather then public key;
additionally with crypto auth info, its easy to specify exact location, so
all that is needed is really to confirm that specified location is
associated with correct identity, which means something like SRV).
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.
Which identity?!!!! You do not know if it is "Sender" or "From" or "MAILFROM"
and without that the info you have means nothing (also note that all the
above I listed are identities associated with message sender but you're
taking it to mean that each identity would be one associated with last
hop, which is only true for EHLO). You also can not actually verify the
majority of identities until you see message header and for most
cryptographic proposals (domainkeys BUT NOT metasignatures) you need
entire messge data before you can verify.
--
William Leibzon
Elan Networks
william(_at_)elan(_dot_)net