Re: Why are we here? What are our goals?

On Jan 30, 2004, at 10:00 AM, J C Lawrence wrote:
> Slightly tangentially, the current approach defines a strict division 
> of
> responsibilities among the MTS, MTA, LDA and MUA, to a point where,
> effective, none of them talk to each other.  This doesn't make sense.

Not so tangentally, if you ask me. And I don't really agree.

Each piece is a significant piece of code with interconnections outside 
into other areas of the space (MLM's increasingly have web services 
attached, MUAs have a serious user interface to manage, MDA has a big 
issue in storage requirements and I/O optimization, etc). Try to merge 
this into one big thing, and you end up with, well, ADA.

I would argue that these divisions are far from arbitrary and very 
necessary, to allow groups of users to focus on each set of special 
requirements and needs, and we need to maintain those divisions and 
enhance them with new functionality to get us the required functions we 
need. For instance:

> Currently MXes accept mail for their users with no way of
> knowing if that mail is desired or not (and thereby operate with
> horrible inefficiency), or of communicating that information back over
> the transport layer.

So the LDA sprouts an LDAP interface, which the MTA can query. they 
don't need to merge, they need to cooperate. and there are ways to 
build that cooperation in, even over a widely distributed e-mail 
network (even one as big as AOL's) using tools that exist today. Just 
build APIs and interfaces to handle these needs instead of 
inter-marrying.

> The definition of spam is subjective to the end user.  One man's spam 
> is
> another man's ham.  As a very simple example, frequently that 
> definition
> of "spam" includes mailing lists which that end user explicitly
> subscribed to.

Going back this morning to my thoughts on white/grey/blackhatting 
servers, if you built this kind of intelligence into the iMap server 
and it had access to a user's white and blacklists and filter setup 
(think sieve on steroids, MUA defined, server implemented), then 
to-the-account white and blacklists can be rolled out to the boundary 
machines fairly easily.

And if you have a server doing analysis of incoming mail to determing 
white/black/grey and how much to trust the connections in that grey 
area, analytics of which connections are whitelisted by its users would 
be a core component. the more its users have whitelisted a host, the 
most the server will accept that mail for users that haven't....