mail-ng
[Top] [All Lists]

Re: a few short notes

2004-02-01 12:13:42

On 1-feb-04, at 18:49, Chuq Von Rospach wrote:

I'm not convinced that using non-ASCII characters in headers is a good idea either.

You have no choice. This is a global service, so it has to support global usage.

Sure. But global usage also means that people who don't know how to type each of 20k+ unicode characters can administer the system.

Headers must be simple and unambiguous. Having text in them that your computer can't even display and if it can, 99% of the world population can't spell, isn't a good idea.

well, go count how many native Mandarin speakers there are in the world, and then realize your argument just outlawed English, too. It's a very english-centric view, and it won't work in designing this new protocol.

Dan doen we het toch in het Nederlands?

The way I see it we have three choices:

1. Screw things up beyond repair by allowing non-latin characters in fields that are relevant to mail delivery (some headers are only for human consumption, I don't care about those)
2. Use latin characters only as this is the most widely used script
3. Use numbers exclusively as every literate person on the planet can handle those

recipient only, so they can be in any format, and others that must be more general so they must be in ASCII.

Why? what *technical* reason is there for this limitation?

Simple: not all computers support non-latin scripts. If I'm going to administer a mail system I must be able to set up filters and such which makes it necessary to have support for the scripts that I may need to filter. But I myself don't support any non-latin scripts (not counting half the greek alphabet) even with a computer that does (such as my Mac) this won't work well.

Mandatory authentication is also a bad idea IMO. Obviously authentication is very important and must be supported so that people who only want to receive mail from verifyable sources get to implement this policy, but that doesn't mean that we should force *everyone* to use such a policy.

If we can't authenticate, we can't authorize. If we can't authorize, we have the status quo. So we might as well go home. there has to be some kind of provable identity here, or we solve nothing. Exactly what that identity is can be flexible, as long as it exists.

This stuff exists today in PGP and S/MIME. However, it seems most people can live without it. If we can limit spam by 90% or so without something like this then I don't think we need to force everyone to adopt strong authentication.

Chris Bonatti had something to say about multicast. Obviously this is something that applies to mailinglist rather than one-to-one messages.

and mailing lists are increasingly going to individualized messages. I think designing for bulk delivery is the wrong direction here, and actually enables the kind of e-mail I think we're trying to discourage or stop.

Why??? Bulk delivery has many advantages and allows some anti-spam strategies that aren't applicable to one-to-one messages.

Important point: as long as email is a store and forward mechanism, encrypting the transport makes little sense: encryption should be end-to-end.

to me, if there's any opportunity to cross a network in plain-text, the proposal is dead.

So what exactly does encryption do for you if you don't even know who you're talking to?


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