Re: a few short notes

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?