Sender authentication & zombies (was Re: Time to check the rate limits on your mail servers)

Sun Feb 6 21:18:35 UTC 2005

On Sun, 2005-02-06 at 09:41, J.D. Falk wrote:
> On 02/05/05, Douglas Otis <dotis at 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