----- Original Message -----
From: "Brett Watson" <famous-mail-ng(_at_)nutters(_dot_)org>
To: <mail-ng(_at_)imc(_dot_)org>
Sent: Thursday, February 05, 2004 8:17 PM
Subject: Re: list of user-visible goals
On Fri, 6 Feb 2004 08:10, Iljitsch van Beijnum wrote:
I've had some similar ideas while planning my own mail-ng system, and the
general conclusion I reached was that we need to decouple email addresses
from the DNS, or at least loosen the coupling.
[....]
I'll attempt to express this in terms of a user want.
- In a next generation mail system, users may want to address each other
in
ways that are not possible in the existing system. The possibilities are
limited only by imagination (and implementability), but one obvious
example
is a self-configuring ad hoc LAN (wireless, perhaps), in which the users
may
want to send messages and/or files to each other without the presence of
traditional domain-based MTAs advertised by DNS.
Hi Brett,
Good point, let me illustrate this issue in a real product. I'm summarize
it as follows:
1) Original 1980's pre-internet design focused on Local User communications.
User accounts were indexed by user name and unique serialized number (user
id). User can login providing any of the 2 lookup indexes.
user to user mail communications were online (or automated offline) text
based dialup.
2) Early internet integration offered domains and "email addresses" so user
accounts with emailing privilege automatically were assigned an email
address of:
firstname(_dot_)lastname(_at_)hostdomain(_dot_)com
Translation tables offer aliases addressing if necessary.
Before users had it easy to connect to the internet, online user to user
mail communications was still dominant. However, he now had an "email
account". This was your early ISP. Companies like eSoft, Murkworks and
others began to make it easy for ISP to being hosting.
However, the main point here is that the system admin may not WANT to offer
email to a GROUP of users, maybe because of subscription or expired
policies. This is how they were making some money. But users with no
email access were still able to create local user mail only using whatever
direct connection offered. No external mail.
3) As users began to connect more directly to the internet and begin to use
internet based MUA software (POP3/SMTP). The system required users to use
their user account name for POP3 login and direct user mail indexed by user
id was quickly looked up and downloaded by the user. For sending, same
idea. Use their user name for login and setup their email address for mail
creation and replies.
No problem right?
Now, for users who didn't have EMAIL access, and for admins were also
beginning to use internet based MUA software wants to be able to
create/reply to local users with no email access.
So the obvious problem is that if you created a message for a local user,
SMTP would reject it because the target user does not have EMAIL access.
Of course, this is required to protect against spammers trying to injection
mail to local users with no email access.
For example:
"hector santos" has email access
"brett watson" has no email access
Brett logs in directly and creates mail to hector.
Hector using POP3 picks up his mail:
From: brett(_dot_)watson(_at_)winserver(_dot_)com
To: hector(_dot_)santos(_at_)winserver(_dot_)com
If I wanted to reply:
From: hector(_dot_)santos(_at_)winserver(_dot_)com
To: brett(_dot_)watson(_at_)winserver(_dot_)com
Our smtp server would reject it because the local domain undotted lookup for
"brett watson" returns a security access profile that says "NO EMAIL
ACCESS."
So related to your comment, a "decoupling" is required because the "goal"
here is that an new "client" method needs to be consistent with the other
current local connect clients method used to create local user mail.
The solution was to follow the same design concept used for other
non-internet local access clients, hence the new logic was to only allow
this local mail transaction to be accepted if the MAIL FROM: address also
translated to a local user and the session was authenticated by the same
MAIL FROM user.
In other words, the translated lookup user id for the MAIL FROM address must
match the authenticated user's account user id. This prevents any
possible return path spoofing loophole.
Make sense?
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com