[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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....