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)

  • From: Douglas Otis
  • Date: Sun Feb 06 16:19:59 2005

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

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.