Re: Some thoughts on SMTP Verification

Alan DeKok wrote:
> Yakov Shafranovich <[email protected]> wrote:
...
> 
>>1. "What" - what are we seeking to do with SMTP verification. It seems 
>>to me that what we want to do is to make sure that none of the 
>>parameters in the SMTP session are forged and also that the MTA is 
>>authentic, and is not a hijacked computer. If would be helpful if we can 
>>clarify as to what type of data we want to know.
> 
> 
>   The ultimate question is: Is the message interesting to the
> recipient?  We can't know that until the message is accepted and read,
> but we have to be clear that all of the data we're looking for is a
> surrogate attempt to answer that question.
> 

What kind of data that we are looking for can help us with that? Would 
passing some metadata about the message via SMTP or some other mechanism 
help? What kind of metadata would it be?

> 
>   At the minimum, protocol/network information.  Number of messages,
> size of messages, transmission rate (bandwidth), rough hints as to the
> content of the message.
> 

And if spammers lie about that data, what do we do - reject the email? 
How would we handle spam sent via hijacked computer and routed through 
an ISPs MTA?

>   In addition, we have a layer of information on top of the network:
> who else accepted messages from this person (e.g. PHB's vouching
> suggestions), how long this message source has been around, what
> organizations this source has been involved with.
> 
>   An ESMTP extension could communicate "domain FOO says I'm a source
> of nice message".  The recipient can then ask domain FOO if that's
> true.  This would avoid LMAP's problem of overloading the meaning of
> the EHLO/HELO and MAIL FROM fields.  It also avoids LMAP's problem of
> people being able to register domains, for the sole purpose of
> publishing bogus LMAP policies.
> 

This kind of like the "chain of trust" used in PGP. Sounds like an 
interesting idea to me! What would spammers do in theory to get around 
such system?

> 
>>2. "Why" - the goal is to make sure that a specific message is not spam 
>>as early as possibly, even within the SMTP session. The basic reason of 
>>why is to make the Internet players more accountable for their actions. 
> 
>   Then there should be a long-lived repository of information.  People
> can't practically be held accountable if they can only be held
> accountable for short periods of time.
> 
>   This means that any self-published method of accountability will
> always be inadequate, as people can pop up and disappear within a few
> days.  Yet another blow to LMAP.
> 

On the other hand any long-lived repository can be abused. In 
particular, this article 
(http://techupdate.zdnet.com/special_report/Stratton_Sclavos.html) 
indicates that Verisign wants to become the central repository for all 
kinds of information. If that happens, likehood for abuse is high.

In a web of trust system, there might be a balance. Would such system scale?

> 
>>3. "When" - as early as possibly. If we can reject the connection before 
>>the HELO prompt, that would be the best. Rejecting anytime during the 
>>SMTP session before the final 250 answer is also desirable.
> 
> 
>   An ESMTP extension hinting at mime content type may be useful,
> especially if it has information about the rough size of the mime
> types.  "99% zip file, 1% text: looks like a virus to me.  Go away..",
> or "99% DOC file, I don't do that..."
> 

The spammers can lie about that, would we reject email that does not 
match the extension?

> 
>>4. "Where" - it seems that the best place to deal with spam is at the 
>>SMTP level not at the MUA, since it gives us a chance to reject the mail 
>>as early as possible. However, the MUA should be able to do that as 
>>well, and should also be able to display results of the SMTP session 
>>verification process.
> 
> 
>   The MUA also needs to give feedback to the MTA.  This ability is
> lacking in many systems.  If the MTA realizes that most of the
> messages of type X it keeps are discarded by the MUA, then it's better
> for the MTA to discard them earlier in the process.
> 

Actually this is something the filtering subgroup is looking into.

> 
>>5. "How" - leaving the LMAP proposals aside which publish information 
>>about MTA/domain name relationships, there is a range of other 
>>mechanisms available to us: ESMTP extensions, other DNS methods, 
>>possibly out of band protocols, TLS with matching certificates, etc.
> 
> 
>   Systems to slow down the rate of messages would help, too.  Coupled
> with feedback from MUAs, and MTA could say "messages from example.com
> are almost always accepted by the MUA, allow them large bandwidth.
> Message from example.net are always marked as spam, so give them small
> bandwidth".
> 

How woudld standards facilitate that?

>   I still think that a major cause of the problem is the imbalance
> between senders and receivers.  If there were two orders of magnitude
> fewer SMTP originates (as opposed to email message originators), then
> spam would be a much easier problem to deal with.

And the hijacked computers make it even worse.

Yakov