ietf-mxcomp
[Top] [All Lists]

Re: Benefits/costs of authorizing different identities

2004-04-02 20:00:52

Dave Crocker wrote:

Meta issue:  You use the phrase "assert a policy" which appears to
actually mean "support authentication".  If that is not what you
actually meant, then please explain.
I mean to advertise information about which IP addressses, holders of keys, etc. that domain authorizes to use its identities. For example, by publishing SPF records in the DNS.

By that phrase, I specifically do not mean "verify authentication". The set of domains that publish a type of policy and the set of domains that are able to verify that incoming messages are consistent with published instances of that type of policy are distinct. In the case of From:, the set of domains that will publish a policy is expected to be much smaller than the set of domains that will be capable of verifying published policies.

As stated, this asserts that there are no strategic, long-term effects
that we can expect to achieve.

No, it does not. We can achieve strategic, long-term effects other than reducing the volume of spam. For example, in the case of MAIL FROM, we can reduce the collateral damage caused by spam and virus bounces.

As much as I encourage us all to pay
attention to the community's dismal track record in controlling spam,
an assessment of history (through statistics) that is then
mechanically applied to predict an equally bleak future strikes me as
a tad cynical and a whole lot less pragmatic than one might initially
think.
My assesment of the speed of which spammers are able to react to a changing ecosystem comes from my experience at a large spammer target. It doesn't mean one can't put a serious crimp in their activities, but when one is evaluating a countermeasure one has to consider the ways in which they will react to it.

My assessment of the current mxcomp proposals is that they will not lead to a long-term reduction in the volume of spam. Some of the proposals have other long-term benefits and these benefits may well justify their cost.

The problem, as I see it, is to attack core characteristics of spam.
Forged identity is not a core characteristic of spam. (It is for phishing, but then you can get into issues of misleading identities.) It has a high correlation with spam in the current ecosystem, but spammers can react by changing that.

Reducing the ability to spoof addresses does not eliminate spam,
directly. As noted, it means that spammers will "simply" create
throw-away addresses, even more than they do now. However
authenticated names are accountable names. With authentication we can
build serious accountability schemes that really do go to the heart of
the abuses.
That would be an example of a long term effect other than reducing the volume of spam.

When a design causes a fundamental problem in a legitimate system
mechanism, and the response is to require changing that legitimate
mechanism, there are two problems.

These are costs and indeed need to be considered.

These references to "desired forgery" that many folks are making are
just plain wrong.

They are not forgeries.

They are authorized uses of names and addresses.
They are unauthorized per the explicit policy advertisement made by the domain holder. The MTA sending mail with the identity is not on that domain's list of authorized servers.

Now the entity that caused that message to be sent through that MTA might be the same entity that the domain issued that address to, but the mechanism is not capable of permitting the domain holder to advertise a policy fine grained enough to cover that case.

If you have a better term for this case, please suggest it.