Re: Scope of SMTP Verify

Peter J. Holzer wrote:
> On 2004-03-01 21:20:44 -0500, Yakov Shafranovich wrote:
> 
>>Peter J. Holzer wrote:
>>
>>>On 2004-02-28 20:24:30 -0500, Yakov Shafranovich wrote:
>>>
>>>
>>>>What I do want to discuss here, is different ways to deal with spam on
>>>>the SMTP level OTHER than LMAP, which is what I tried to start with my
>>>>message on different possibilities such as SMTP level passing of
>>>>parameters, etc. This is something that should be done here, while the
>>>>LMAP proposals can be discussed at the IMC.
>>>
>>>
>>>I can think of several items which can be verified at the SMTP level
>>>(not necessarily in any useful order):
>>>
>>>1) The identity of the SMTP client. SMTP auth exists, but doesn't seem
>>>  to be much use between random hosts on the internet (It is useful for
>>>  authenticating users to their "home MTA").
>>>
>>>  Various plausibility checks (check for PTR records, check HELO
>>>  parameter against IP, ...) also fall into this category.
>>>
>>
>>We know the identity of the SMTP client based on its IP. What other
>>kinds of identity are possible?
> 
> 
> E.g., "This is Joe's laptop". Or "This is the same computer that sent
> spam last week".
> 
> The IP address is only an indicator of identity for systems with static
> IP addresses.
> 

For those systems, is an IP address sufficient identity? For dynamic 
systems, is the actual "dynamic" of the address the only reason why we 
would need other identification systems beside IP?

> 
>>Knowing such identity, how can we use it to decrease spam?
> 
> 
> Some kind of reputation system. I think this is true for all methods
> which establish an identity of an originator or relay. Simply knowing
> that the message was sent by or through X doesn't tell me anything about
> whether the message is spam or not. Only if I also know whether X is
> likely to send spam or ham, I can  estimate whether the message will be
> spam or ham. (This is also true for LMAP - it just shifts the problem
> from the client's IP address to the domain)
> 
> 
>>If through a blacklist/whitelist system, do existing blacklist and
>>whitelists suffice? If they do not, how would reputation systems of
>>the future able to avoid the same problems that plague today's
>>blacklists?
> 
> 
> Good question :-)
> 

Well that's the problem. So far we haven't gotten good answers. Besides 
"web of trust" and "reputation systems", are the other possibilities 
that can be used with identity to reduce spam?

> 
> 
>>>2) The identity of the sender of a message.
>>>
>>>   This is currently only possible with cryptographic signatures in the
>>>   message, not at the SMTP level. (That distinction might be academic)
>>>
>>
>>If you trust the MTA, you can trust it to pass the sender's identity via
> 
>   ^^^^^^^^^^^^^^^^^^^^
>   That's the crux, isn't it? I don't trust any random MTA connecting to
>   my MTA's port 25.
> 

But we do want to allow a new domain to make its own MTA and not having 
to "pay the piper" to some gatekeeper in order to send mail. So the 
basic question  of trusting the incoming MTA vs. the need to allow 
messages from unknown MTAs is an issue.

> 
>>SMTP or other methods. In SMTP AUTH there is an extension for the MAIL
>>FROM command which does that.
> 
> [...]
> 
> 
>>>   An ESMTP extension to pass a signature of relevant envelope
>>>   information (return path, envid(?), size(?), ...) and a timestamp
>>>   could be devised.
>>>
>>
>>There actually is a proposal at the IETF for passing all headers via an
>>SMTP extension which might be similar to what you are thinking of.
> 
> 
> I looked through the internet draft abstracts, but couldn't find it. Do
> you have an URL handy?
> 

http://www.ietf.org/internet-drafts/draft-klensin-email-envelope-00.txt

Yakov