At 01:05 PM 5/23/2005 -0400, Mark Shewmaker wrote:
On Mon, May 23, 2005 at 09:21:47AM -0700, David MacQuigg wrote:
> The statements of the objections are brief, and I hope accurate.
Imagine a sender attempts to send a message with statements such as:
(For simplicity I'm just showing part of the sender's side of the smtp
conversation.)
EHLO a.example.com
MAIL FROM:<user(_at_)b(_dot_)example(_dot_)com>
[...]
DATA
[...]
Resent-Sender: user(_at_)c(_dot_)example(_dot_)com
[...]
.
(And just to make things even more simple, let's assume that MS decided
to actually license their senderID patent claims in an open-source
compatible way, and that the technical problems with it were resolved.)
I would want to reject the mail as being a forgery if any of the
following is true:
1. a.example.com claims via its spf or csv record that the client
is forging its name in the helo string.
2. b.example.com's spf record says via its spf record that the
client does not have its permission to use
"user(_at_)b(_dot_)example(_dot_)com"
in this way.
3. c.example.com says that the client does not have its permission
to use "user(_at_)c(_dot_)example(_dot_)com" as a pra.
I then want to reject the mail if any of the following reputation
problems exist:
1. If my trusted reputation server tells me something bad about
user(_at_)b(_dot_)example(_dot_)com
2. If user(_at_)b(_dot_)example(_dot_)com doesn't get an spf pass and my
trusted
reputation server tells me something bad about a.example.com
(I'm fine with receiving mail from "good" domains sent from
spammy servers.)
3. If my trusted reputation server tells me something bad about
user(_at_)c(_dot_)example(_dot_)com(_dot_)
How does an "ID d.example.com", which presumably tells me c's claims
about what *it* is okay with me doing, help me with the above?
The problems with using Resent-Sender as the declared ID are that it is a
header field, requiring transfer of data before it is used, and it has
existing semantics, which may be in conflict with the ID needed by CSV, for
example. We need something that we can check *before* transferring any
data, and that will allow *any* domain name to be used as an ID.
The whole procedure above is going to require many DNS queries. You won't
know whether any of the identities a, b, or c, offers authentication until
you do a DNS query on each of those identities. You will also have to
check all parent domains, in case some authentication records might be
found there.
Now, I can see that:
1. I'll have another way of rejecting mail as a forgery.
That is, I can reject mail connections that d.example.com's ID
record claims is a forgery.
It's not another method, but rather a way of finding out what existing
methods you are supposed to use.
Objection: The new ID will require a new method to authenticate it.
Does this capture your concerns? If not can you state a different objection?
2. I'll also have another way of rejecting mail for reputation reasons,
if repuation servers are made for recording reputation of mail that
ID's have said pass their tests.
Reputations will be an essential part of any complete system. Spammers can
generate all the names they want, and even authenticate those names by
whatever method they choose.
However, I don't see how either of those things help me accomplish my
preexisting goals.
So again, how *exactly* does an ID claim from an untrusted party help me
accomplish my listed goals?
What you have listed as goals, the authentication of specific identities, I
regard not as goals, but as means to accomplish a goal. I would state the
goal as "authenticating an offered identity, using whatever method is
offered by that identity and is acceptable to me". This is a goal all
methods can share.
What I learned in my years of working with software developers is that I
have to separate the requirements from the implementation. Get an
agreement on a clear set of requirements, and a smart developer can figure
out how to implement it. In case you missed it, here are the requirements
from the draft:
1) This protocol must not favor any one authentication method over
another. It must allow an arbitrary number of Forwarders using different
methods to work together in the same authenticated transfer.
2) Each Sending Mail Transfer Agent (MTA) in an IP-authenticated transfer
must declare, in the SMTP session, the Identity responsible for the transfer.
Do you agree these are reasonable requirements? If you had to implement
them, how would you do it?
I've moved these requirements from section 4 to section 2, giving them a
little more emphasis.
--
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 *
************************************************************ *