-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
David MacQuigg wrote:
At 07:54 AM 5/20/2005 -0500, Daniel Taylor wrote:
David MacQuigg wrote:
At 06:10 PM 5/19/2005 -0700, william(at)elan.net wrote:
On Thu, 19 May 2005, David MacQuigg wrote:
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.
We're talking about a syntax that might be useful for SPF, CSV,
DomainKeys, etc. None of these require pre-negotiation. I hope this
isn't the start of a debate on the meaning of "authentication".
So, to get back on track, assume you are a well-equipped receiver, and
you have available any method that might be needed, including the three
I mentioned. All you know about the incoming mail is it's IP address,
the following two commands:
EHLO mailserver7.bigforwarder.com
MAIL FROM:<bob-at-sales.some-company.com>
What do you do to avoid a DNS hunt?
<snip>
For SPF the answer is ridiculously simple.
We don't know yet if the sender uses SPF.
And if he is using anything but SPF it is beyond the scope
of the SPF specification.
You query TXT for sales.some-company.com against the source IP.
If you want to check permission for HELO, you do the same for
mailserver7.bigforwarder.com.
Since bigforwarder.com is probably in trusted forwarders, you might
ignore a FAIL on MAIL FROM:, but definitely would not ignore a FAIL
on the EHLO.
Probably ... probably ... We need to remove this uncertainty about the
sender's intent.
Not at all. For our purposes (spf-discuss), the sender is either using
SPF or not. We have 2 identities that we can verify, and anything
beyond verifying those 2 identities with SPF is a concern for others.
A specification for a modification to SMTP that would allow the sender
to specify the protocol that the sender would like to be identified
by would be completely outside the scope of SPF, and I would consider
it a bad idea from the git-go.
<snip>
OK, I think I see the problem. I should not have used "ID", or anything
suggesting "identity" as the keyword. That will immediately block
consideration by anyone who has strong beliefs about which identity a
sender should be using. I need a more neutral term.
Let's try this again. We need some way to avoid the DNS hunt that
Daniel just described. Here is the incoming message:
EHLO mailserver7.bigforwarder.com
CLUE bigforwarder.com
MAIL FROM:<bob-at-sales.some-company.com>
So, if someone at bigforwarder.com wants to forge e-mail from
sales.some-company.com, they just have to tell us to ignore the identity
for sales.some-company.com. I don't care how big the forwarder is, there
is always the possibility that they will be compromised. What you
propose is adding a loophole big enough to drive a planet through.
The only way around your loophole is to do exactly what it is you are
proposing it to avoid, which is check the available identities against
all available verification methods.
At this point, we have no idea what method will be used. Without a
clue, we have no idea where to look for some possible authentication
records. We need to do a DNS query to every possible location for those
records (mailserver7.bigforwarder.com,
bigforwarder.com, sales.some-company.com. some-company.com,
_client._smtp.mailserver7.bigforwarder.com, etc.) and we need to look
for records of type TXT, SRV, SPF, etc.) This still doesn't cover the
identities found in the mail headers. Even after all these queries, we
still can't conclude the search. We need to transfer at least the
headers, look for DomainKeys, and maybe a few others, and the result of
all this effort may still be - no authentication found! This entire
hunt will be repeated at every forwarder along the way.
With a clue, all we need is one query to _AUTH.bigforwarder.com.mail.net
(or some other neutral location). The response to that one universal
query should be packed with useful information - ratings from reputation
services, list of authentication methods, even some parameters needed
for the authentication.
And here you make it even worse. A centralized validation authority?!
Who will pay for it? And who will trust it?
- --
Daniel Taylor
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFCjhU88/QSptFdBtURAmmAAJ9UBsziwSDOxhJoPCbJVWBC8l4bWgCfTT0X
jUQ/y3X9vCOsF54ch64P3+U=
=BzKB
-----END PGP SIGNATURE-----