mail-ng
[Top] [All Lists]

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

2004-01-30 20:30:17


On Jan 30, 2004, at 8:02 AM, Bonatti, Chris wrote:


Okay, so long as we're throwing ideas out, it always seemed to me
that we should have a multicast-friendly transport option for
push-mode messaging.

I'm not sure I'd go multicast, but some kind of "transfer of processing" isn't a bad idea, optionally.

I'm thinking in terms of some kind of architecture that allows for optional enhancements that can be advertised by a receiving server, and if they exist, sending servers could take advantage of it. There'd be a core set of required features, a configurable set of standard extensions, and some kind of plug-in capability for specialty work and future new stuff. if that sounds a lot like configuring apache, it's purely coincidental, but it's a good model.

One of those standard-but-optional modules could be a way to allow a site to accept "mail merged" e-mail. The Mailman group is discussing the tradeoffs of personalization now; if you have a mailing list that you want to individualize for each user, now, you have to send one email for each user, losing any batching capability. So if a site wanted to, they could enable a module that allows a MLM to send a template and a set of updates in a single packet, and "explode" it into individual emails on the other side. Since you're making a resource tradeoff here (CPU for network, he says, oversimplifying it for simplicity's sake), it should be up to the receiving site whether to accept that tradeoff or not.

I also like the notion of anonymity as a SECURITY service.


I argued against this earlier, but if you look at the "plug in" setup above, I wouldn't argue against it being an optional service, but what's the fallback if a receiving site refused to accept anonymous mail?

I really think privacy/anonymity is better served at a higher level, by a service that lives on a trusted host and acts as a trusted go-between. Trying to implement that in the transport layer on a global basis isn't feasible; instead, create a way for a few trustable sources to be validated as go-between that sites can choose to accept or not, similar to the current remailers.

I am very wary of anyone thinking they can build a distributed system of trusts in an environment where those we know we can't trust are full partners in the network and have full access to the data in it. I see that as similar to sending a copy of my house key to everyone in the country, and then thinking I'd somehow know whether they're friend or foe when they open the door. I just don't think that's feasible. Instead, I prefer to leave the door locked, hand keys only to those I trust, and ask the rest to use the doorbell.


<Prev in Thread] Current Thread [Next in Thread>