----- Original Message -----
From: "Philip Miller" <millenix(_at_)zemos(_dot_)net>
To: "Hector Santos" <winserver(_dot_)support(_at_)winserver(_dot_)com>
Cc: <asrg(_at_)ietf(_dot_)org>
Sent: Monday, December 15, 2003 10:19 PM
Subject: Re: [Asrg] 6. Proposals: MTA MARK vs port 25 filtering?
POP-before-SMTP was an ugly hack to make up for shortcomings in existing
software. Unfortunately, it stuck. It's clearly obsoleted by SMTP AUTH,
but
there's no compelling reason for users to switch, and thus ISPs have to
deal
with the inertia of their users. I think we're going to have to live with
it
for a long time.
I was resistance to the idea myself until ISPs indicated their side of the
story. Easy end-user signs up with little or no instructions. They were
right. Once we added it, it is now rare for us to be telling our customers
they need to setup their mail client for SMTP authentication. Look at how
the software is written for the end user. The only easy setup is for POP3
login. SMTP authentication requires extra steps and instructions. It is
not obvious.
However, that does not change the fact that LMAP and user authentication
target 2 complentary but separate problems: domain forgery, which prevents
holding anyone accountable, and user forgery, which is a nuisance best
dealt
with by the organization that hosts the user's address, since they are
uniquely able to authenticate the user.
I agree. My point is only that most systems with ESMTP AUTH use it to trump
most (if not all) other restrictions, which is mainly routing. So as long
as you can login, it doesn't matter what machine you connect from or what
address you use for the return path. In our case, however, we have
restrictions for the return path in AUTH mode.
The question is how will LMAP address systems like AOL who are now
automatically blocking dynamic IP machines at the connection level.
Does LMAP address IP ranges?
Are we ready to say that dynamic IP senders are no longer allowed?
The way I see it from an implementation standpoint, LMAP can only be used
for a "accept" logic. It can't be used to reject for lack of a LMAP based
information.
LMAP AUTH
0 0 Low trust
1 0 X trust
0 1 Y trust
1 1 Z trust
Z is great, Y is still better than X. With just X, we are still
scratching our heads which is the point you are making I believe. What I
am saying, you don't need X if you have Y and I sincerely doubt systems are
going to remove this logic to programmatically require X before you can have
Y. As long as you have Y (AUTH), you are in. In short, Trust Z >=
Trust Y. With no X, Z=Y.
-- Hector
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg