"william(at)elan.net" <william(_at_)elan(_dot_)net> wrote:
a. Analyze proposed solutions seen to SMTP identify theft problem
(LMAP options being considered that rely on validating MAIL-FROM or
EHLO do not really do much in fighting spam but only focus on improper
use of your domains in spammer emails but in my opinion that is
already good enough reason to have ASRG work on it considering it
provided original LMAP document).
As PHB pointed out, once you have a policy database, it's easy to
extend it to other policies. e.g. LMAP data could be "mail from MTA's
X, Y, and Z is OK, but allow mail from other sites if they use DK".
LMAP discussion draft has done some of it already I think.
The discussion document describes a number of ways how it interacts
with roaming users. I will be adding a few more comments to it in the
next revision.
The best line in it, though is from Hadmut:
Stopping mail forgery requires everyone to give up forging.
To put it a little more politely: If we had known 10 years ago what
we know today, how would the SMTP protocol/implementation/deployment
be different?
If we can describe where we are today, and where we would like to
go, then the steps to take become clearer. In this case, we may have
recommended that IEEE or ACM-style forwarding be done differently.
b. Analyze each type of user problem that listed above. and list possible
solutions (see A, B, C from John's original post) and which of these
A, B, C solutions will solve which problem then list of CONs for
each solution and possibly assign certain values to difficulty in
implementation and adaptation of each solution. Again nice chart
would help...
The LMAP discussion document does this a little, but not in any
great detail. The intent of LMAP is to allow recipients to discover
when senders are using names without the owners consent. If some
domains don't publish LMAP information, they obviously won't
participate in the process. That's fine for them.
The only question, then, is: Are institutions like IEEE/ACM able to
change their systems to interoperate in an LMAP-aware world?
A1: No. Then some of their users mail will get through, and some
might not, due to the recipients implementing LMAP checks.
Unless we're going to demand that the recipients NOT implement
LMAP, this falls within the recipients powers.
A2: Yes. Then the institutions and/or their users will have to take
additional steps (software upgrades, machines, etc.) in order to
have their messages satisfy the criteria of LMAP-aware
recipients. <Insert standard complaints about cost here.>
Yes, it's a cost. But they're protecting their names. How long do
you think it would take a company to require some kind of name
verification, once their name was used for spamming kiddie-porn?
Hmm... that's why LMAP was invented in the first place, to protect
domains which were being abused. I don't see much opposition to LMAP
from those sites, but instead only from domains not getting abused.
Given that, the opposition looks a little funny to me. "We're not
getting abused, so we don't want to use or publish LMAP. We still
want to communicate with abused domains, so we demand that they don't
implement LMAP, because it's a pain for us to change our behavior".
I hate to think that's an accurate summary of the pro/con arguments,
but it's at least close.
Alan DeKok.