Re: Scope of SMTP Verify

On 2004-03-03 07:32:07 +0100, Hadmut Danisch wrote:
> On Tue, Mar 02, 2004 at 10:17:51AM +0100, Peter J. Holzer wrote:
[Authenticating the client computer. SMTP AUTH and similar methods]
> >
> > E.g., "This is Joe's laptop". Or "This is the same computer that sent
> > spam last week".
>
>
> Who is Joe? In some countries human names are as volatile and
> arbitrary like dynamic IP addresses.

Some specific Joe I know. Not any person named Joe. Joe has a laptop, he
has an email account and a password. He travels a lot, and uses whatever
network is available at the hotel, conference, etc. When he connects to
his provider's or employer's MSA, he authenticates with account name and
password.  Regardless of the IP address it will be known that this is
Joe's laptop which is connecting. (Not necessarily the same laptop as
last week, but we assume that Joe doesn't buy a new laptop every week,
and we also assume that he is careful with his password).

Of course, since account name and password form a shared secret, this
only works with specific SMTP servers (which can verify his password),
not all of them.

TLS with TLS-level client auth could work globally, because the
private/public key pairs are (probably) unique.

> > The IP address is only an indicator of identity for systems with static
> > IP addresses.
>
>
> The pair (IP address, time) is an indicator. Since LMAP verifies while
> the SMTP connection is alive, this is sufficient.

Erm, the subject of this thread is not "what is wrong with LMAP", but
"what ELSE could be verified at the SMTP level". I was NOT AT ALL trying
to attack LMAP, simply trying to give a (hopefully complete) list of
data which could be verified during an SMTP session.

So to come back to "identifying a client computer", the pair (IP
address, time) is not a useful indicator alone, because I need other
information to establish identity. If I know that the IP address addr_1
of a computer is static, I can establish the identity of (addr_1,
time_1) and (addr_1, time_2) and the non-identity of (addr_1, time_1)
and (addr_2, time_3). But if I don't know that the address is static, I
cannot know that the same IP address at different times belongs to the
same computer.

> > Some kind of reputation system.
>
> "reputation system" is something magic which we can't describe
> sufficiently. It's more a religious thing than a technical mechanism.
> Tell me how exactly your reputation system should work and I'll tell
> you why it won't work.

I was intentionally vague here, because IMHO the questions "who is this"
and "is he likely to send spam" are mostly independent.

You have some means of establishing an identity, e.g.,

"The IP address 10.2.3.4" (getpeername(2))

"An MTA authorized to send mail for Domain example.net" (LMAP)

"The user [email protected]" (SMTP AUTH)

"The owner of the private key (long number)" (TLS client auth, PGP,
S/MIME, ...)

etc.

Then you need want to know about the reputation of the identity you just
established. This could ask a local white/black list, a public blacklist,
whatever.

> Of course, since it is not precisely defined, it's always easy to
> believe, that it will do the job, since nobody can show the flaws of
> a yet completely undefined term.

A reputation system is a system for storing and retrieving reputations.
The RBLs are reputation systems for IP addresses. Somebody reports IP
addresses as spammers, open proxies, whatever, and you can ask "hat IP
address 10.2.3.4 a reputation of being an open proxy?" and base your
decisions on the answer. If some kind of LMAP is widely deployed, there
will be reputation systems for domains. Just as RBLs now, they will vary
in quality. Discussion about reputation systems is interesting, but
independent of the means of establishing identity.

	hp

--
   _  | Peter J. Holzer    | I think we need two definitions:
|_|_) | Sysadmin WSR       | 1) The problem the *users* want us to solve
| |   | [email protected]         | 2) The problem our solution addresses.
__/   | http://www.hjp.at/ |    -- Phillip Hallam-Baker on spam

[demime 0.99d.1 removed an attachment of type application/pgp-signature]