ietf-mxcomp
[Top] [All Lists]

Deficiencies in LMAP

2004-03-03 10:09:33

  One of the biggest objections to LMAP is that spammers can register
domains, and publish fake LMAP information for "owned" machines.  In
this situation, LMAP does nothing to stop, or even slow down, the
flood of spam.

  I've posted this summary previously on ASRG, and the smtp-verify
sub-list, but I thought I should post it here, too.

  The idea is to (ab)use rDNS, and to publish LMAP records there,
too.  One of the key records to publish is which domains are permitted
to publish LMAP records for this IP.  Or, the information could be
which DNS servers are allowed to publish LMAP records for this IP.

  e.g. Once it has an SMTP connection, the recipient may then decide
to query LMAP for a domain: example.com.

  The steps it goes through are now:

  LMAP query : reverse_ip._lmap_.example.com -> pass/fail

  If pass, look get hostname for rDNS of the IP (a.b.c.d.example.net),
and do an LMAP query:  example.com._lmap_.a.b.c.d.example.net

  If this query fails, it can look up the IP of the DNS server(s) for
example.com, in _lmap_.a.b.c.d.example.net.

  I vaguely recall something similar being discussed months ago on
ASRG, but I don't remember if it was this method, or something
different.

  Pro's: solves the largest complaint against LMAP.
  Con's: requires more information to be in DNS, and more DNS lookups.

  There is a simple argument against this addition to LMAP, and LMAP
in general: This method helps only if all domains participate in it.

  I don't see that argument as holding much water, as the same
argument applies to *any* system which may be deployed.  If the
potential participants see a benefit to deploying this solution, then
they have incentive to do so.  If there is no benefit, then the
solution is a bad one, and will be rejected by most participants,
independently of what we decide here.

  Alan DeKok.


<Prev in Thread] Current Thread [Next in Thread>