Re: Some thoughts on SMTP Verification

Yakov Shafranovich <[email protected]> wrote:
> I wanted to share a few thoughts with you. Leaving the LMAP proposals 
> aside, are there any other methods or changes that can help verify the 
> SMTP transaction as being authentic?

  To who?  The parties involved in sending a message are at least:

  a) the originator of the message
  b) the owner of the machine sending the message
  c) the owner of domains named in the message

  These may all be the same person/administrative domain, but they
don't have to be.  LMAP addresses parts of c), MTA-MARK addresses b),
and I'm not sure what can address a).

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

> [A side comment: I would like to ignore the LMAP proposal for the policy 
> discussions. What I want to look at here, is if we were making a policy 
> mechanism for email from scratch, what would it look like?]

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

  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.

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

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

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

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

  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.

  Alan DeKok.