North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: Sender authentication & zombies (was Re: Time to check therate limits on your mail servers)
On Sun, 2005-02-06 at 09:41, J.D. Falk wrote: > On 02/05/05, Douglas Otis <[email protected]> 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
|