Hector Santos wrote:
Philip Miller wrote:
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.
This is a problem of the initial design of SMTP. Initially, SMTP didn't
require authentication, so no one designed it in as an integral part of
client software. POP clearly required authentication, so it was built in,
and clients were forced to include it.
The intelligent thing for a mail client to do is automatically attempt to
AUTH (if it's offered, obviously) and then fall back on POP-before-SMTP.
This is reasonable behavior for the average case of a user who sends and
receives mail through the same ISP account. Users who have a more
complicated configuration would be perfectly able to change this, as it
should be no more than a checkbox. This is probably something we should take
account of in a BCP for mail client authors.
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.
OK, I misunderstood you the first time. That's exactly how I have my MTA set up.
The question is how will LMAP address systems like AOL who are now
automatically blocking dynamic IP machines at the connection level.
Either their policies will change to accept mail presenting valid LMAP
credentials despite their 'undesireable' IP address, or they won't. AOL has
been off in its own world for a long time, and we're not going to change
that. We should make LMAP as attractive as possible by playing up the
newly-available accountability, maybe pushing for legislation holding
LMAP-authorized MTA administrators responsible for the actions of those servers.
Does LMAP address IP ranges?
No. It addresses whether a given IP can send mail as a given domain, and
nothing else. If you meant "can a range of IP addresses be listed for a
domain?", I'm not sure, one of us would have to check the current SPF draft.
Are we ready to say that dynamic IP senders are no longer allowed?
Most of us would say no. AOL management says yes. We've seen that this was
not the decision of their system administrators. Brad Knowles, who was in
charge of their Internet mail gateway system for years, fought this policy
and failed.
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.
Eventually, the intent is that it would. Mail from a domain that doesn't
publish LMAP information could be treated as mail from an open relay.
There's no accountability at all beyond having the IP address the connection
was made from, which is exactly as much information as we have about
open-relayed mail now.
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.
OK, you point is clearer now. However LMAP is implemented in recipient MTAs,
authors would have to be sure not to preclude AUTHing.
Philip Miller
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg