Other SMTP verification methods

"Alan DeKok" <[email protected]> Mon, 01 Mar 2004 13:37:42 -0500
Newsgroups gmane.ietf.asrg.smtpverify
Message-ID <[email protected]>
Yakov Shafranovich <[email protected]> wrote:
> Since LMAP seems to be on its way to the IETF and there is an
> LMAP-specific list at the IMC (www.imc.org/ietf-mxcomp/), I wanted to
> ask the present company whether there is anything else useful OTHER than
> LMAP for dealing with spam on SMTP level including authentication of the
> SMTP session via other methods.

  Some kind of distributed SMTP AUTH could be useful.

  e.g. an originating MTA "logs in" to a recipient MTA, using
"[email protected]".  The recipient MTA then somehow authenticates
that user ID, using information published by "example.com".

  This is functionally similar to LMAP, though with arguable more work
on the part of the originator.


  A "vouching" system, to create a web of trust could help.  This
system would be resilient to spammers introducing bogus data, as they
would only be able to create a web of trust among themselves, with
little connection to non-spammers.


  Another system would be to bug the anti-spam companies for lists of
IP's.  A public list containing IP's of MTA's, and how long that IP
has been an MTA could be made available.

  Recipients could check the list, and choose to accept less traffic
from MTA's who haven't been around long.  The benefit here is that
it's a whitelist, and would automatically not list dynamic IP's.  And
if spammers want to get their MTA on the list, they have to be
long-lived, and thus available to be caught by blacklists.

  Of these systems, the last one is the least cost to set up, and will
probably stop the most spam (in combination with a blacklist.)  The
only difficulty with implementing it is political, not technical.
Those lists already exist.  Publishing information in DNS is already
possible.  But the organizations with that information don't want to
publish it, or don't want to be held responsible for lawsuits if they
do publish.

  Alan DeKok.