At 11:04 AM -0800 03/11/2004, Edwin Aoki wrote:
There are some really good points here that I think we'd do well to
adopt. Nonetheless, I still see one issue that seems to keep coming
back in every discussion that I've had in every context of spam
prevention:
There are multiple entities being authenticated and multiple
decisions made to authorize. Let me see if I can try to put this
into an example:
I (Edwin Aoki, aoki(_at_)aol(_dot_)net) try to send a piece of mail to (for
example) Dave Crocker.
In my mind, here are the various sender assertions that could be
made (without reference to any specific proposal):
* I, Edwin Aoki, authored (created) this message
* I, Edwin Aoki, sent (caused to be injected into the mail stream)
this message
* A machine at 1.2.3.4 is authorized to send mail
* A machine at 1.2.3.4 is authorized to send mail on behalf of AOL (aol.net)
And at the receiver, I can use the information asserted by the
sender to make assertions such as:
* I can verify that Edwin Aoki authored this message (or not)
* The MTA from which my MTA received this message is listed as being
allowed to send mail (or not)
* The MTA from which my MTA received this message is listed as being
allowed to send mail on behalf of the domain listed in the message
(or not).
I believe the scope of the work we taking on is about MTA authorizaton, rather
than verification of authorship or permission to inject into the mail stream.
Assuming for a moment that the available mechanisms to check the credentials of
those injecting mail into the stream are used, I believe the point
we're trying to reach
is:
"* The MTA from which my MTA received this message is listed as being
allowed to send mail on behalf of the domain listed in the message
(or not)."
From a very high level perspective, there are two ways of achieving that:
Publish a record that describes the set of MTAs allowed to send mail
on behalf of a domain, and then check to ensure that an MTA is a
member of that set.
Publish a record for each MTA that describes what it is permitted to do,
then check those permissions against what the MTA is attempting.
Speaking personally, I don't see much point in saying that an MTA is permitted
to speak on behalf of *any* domain, as assertions of that type seem to me
to lead toward the same arguments that closed down most open relays. So
my take is that a record published about an MTA would have to describe
for which domains it is permitted send mail.
If that is correct, the key questions look like "is it operationally
more sensible
to publish a description of the set, and have recipients check the set, or
publish the MTA record and have recipients check the record?" and "is the
optimization required for handling a set harder or easier than the
optimizations
required for handling an MTA record". Buried in both is a question
about how trust
in the answer received is managed.
Speaking personally, obviously, not in any particular role,
regards,
Ted Hardie