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