Re: Scope of SMTP Verify

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?

Knowing such identity, how can we use it to decrease spam? 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?

> 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
SMTP or other methods. In SMTP AUTH there is an extension for the MAIL
FROM command which does that.

But the questions once again is, how can we use this identity to reduce
spam? Reputation systems?

>     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.

> 3) The right of the SMTP client to send mails on behalf of the alleged
>    sender.
> 
>    This is what LMAP tries to do.
> 

Are there other ways?

> 4) The existence of the sender.
> 
>     Check for MX and A records of the return path.
> 
>     SMTP callback.

Message tracking protocol was also suggested for that. How would it help
against spam? Are the DDOS issues that are possible with callback
sufficient enough to cause harm?

Yakov