
On Sun, 2005-02-06 at 09:41, J.D. Falk wrote:
On 02/05/05, Douglas Otis <dotis@mail-abuse.org> wrote:
Without authenticating an identity, it must not be used in a reputation assessment. Currently this is commonly done by using the remote IP address authenticated through the action of transport. In the name space there are two options, the HELO and a validated signature. DK and IIM are attempting to allow the signature solution to scale.
Heh, you don't need to convince me that DomainKeys is a good idea. I just don't see how you're jumping from the issue of end-user authentication (which is not free from zombies, as others have explained already) to domain-level reputation. Where's the link? If you're talking about adding user-level signatures to something like DomainKeys (which we already have in s/mime), how do you propose to scale that to interact with the reputation determination for billions of messages per day?
Take something like the DomainKey, and add an opaque identifier to the signature, derived from a user authentication process. This could be from an access server or a verification that resolves a dynamic address assignment to a persistent identifier. DomainKeys can scale. Adding an optional opaque persistent identifier will also scale, as this information is already collected. The reason for adding this identifier is two fold. One, it can be used to guard against replay attacks. Two, to assist in identifying compromised systems. Blocking by the provider scales; the identifier makes it easier to locate the problem via abuse reports. The signature ensurers that the provider can accurately attribute abuse. In addition, the provider should want to include the identifiers to protect their reputation in the face of a replay attack, which they can not block otherwise. By convention, the provider can publish their own identifier blackhole-listing just to address the replay attack, whereas known compromised systems should be blocked outright. The signature protects the provider from possible blocking and blackhole-listing errors, as the users will not believe they were the cause of their own problem. -Doug