RE: Time to check the rate limits on your mail servers

If each provider signed their messages AND included account identifiers
(as used by their access servers), then the providers themselves or some
third-party would have little trouble blackhole listing problematic
systems. There would be NO danger that something in the customers
system could be stolen.

A blackhole A record of 127.0.0.1 by the provider at the following:

<internal-identifier>._rl.<domain>.<tld>

Or if by a third-party, it could be

<internal-identifier>._rl.<domain>.<tld>.<third-party>.<tld>

This mechanism would also prevent a replay attack on signatures as well
as allow extraction of these problem accounts caused by compromised
systems. These people would quickly learn they have a problem, if they
use the mail services of the provider. If they do not, they should be
blocked by the provider outright. To prevent bounce traffic
unilaterally, BATV would be a better solution.

SPF et al does not allow safe reputation assertions. A reputation
assertion is the ONLY way this type of abuse can be prevented. Binding
MAILFROM or the FROM with some IP address will not stop spam. Within
two minutes, spammers will have adapted, and yet a tremendous expense
and disruption will have taken place for little benefit.

-Doug

Date: Sat, 5 Feb 2005 19:18:53 -0000
From: J�rgen Hovland

A cryptographic signature would be a perfect guarantee as it can be
used for direct identification and authorisation if you were

No, it's not direct. You trust whoever signed the key.

Note that I agree PGP key signing is less prone to attack than unsigned
SPF. The severity of the difference is a matter for discussion...

guaranteed that the only user of the signature was infact you and
not the spyware on your machine. The implementation is everything.

A cryptosig can ensure that the ISP didn't alter the message. AFAIK,
most MUAs pull cryptosigs from the registry/configs. Could malware do
the same? You bet.

To prevent spyware using your signature you can for example use some
sort of local signature engine and a fingerprint reader. It isn't

Specifics, please. You'd need to ensure that the fingerprint reader
would operate at a protection level that the spyware couldn't access.
That's currently an unrealistic assumption. A worthy goal, but a bit of
a stretch these days.

possible to steal the private key because only the engine can decode
it. Emails can only be signed with that signature by the engine, and
the engine needs your fingerprint first. But who really wants to
stick your thumb in the reader for every email you send?

*shrug* Put a print reader on a keyboard... hold down finger/thumb a
few seconds to authenticate... flush the queue for messages created
prior to auth...

[ snip ]

Now that you are identified and authorised - I can still send you
spam! How can I stop you from doing it? I can remove your

Exactly. You can still send spam, but the sender is accurate. IMNSHO
there is benefit in quickly determining *who* is responsible.

I don't claim to have the FUSSP. The lack of such does not mean that
partially-effective measures are worthless. (Hint: Nothing in the
history of mankind has stopped murder. Should we discount all laws,
punishments, et cetera?)

Eddy

SPF and Sender ID do not indicate who administers the machine. It is
important to understand that SPF and Sender-ID entities are completely
unrelated to server administration or ownership. Authentication, and
not just authorization, is required to prevent forgeries. Yahoo's
DomainKeys or Cisco's IIM could be enhanced to include a unique account
identifier, perhaps directly derived from the access server, which would
enable a means to directly confront this threat.

DK or IIM makes it clear who is administering the server and this
authentication permits reputation assessment. Add an account
identifier, and the problem is nailed. Reputation is required to abate
spam. SPF and Sender-ID CAN NOT support reputation because they REALLY
CAN NOT prevent forgeries. There isn't even a consensus which entity
should be checked with these schemes.

-Doug

Ah, so you're saying that only the reputation of individual
  e-mail addresses is worth paying attention to? How do you
  expect that to scale to billions of messages per day?

Isn't that called S/MIME and PGP? It hasn't scaled yet. I've received
two S/MIME messages in my life, and a few more PGP messages. A problem
is if the computer has been compromised, its likely the authentication
information stored on the computer has also been compromised or will be
when the user starts typing any missing information. Very few
consumer-grade computers have advanced security devices installed.

As I keep saying, a secure computer rarely DDOSes, spams or sends viruses.
And when they do, its much easier to whack the owner. So how do we keep
computers secure and fix the insecure ones?

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.

-Doug

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