Re: Reviewing philosophies and assumptions

[kankkune@xxxxxxxxxxxxxx (Risto Kankkunen)]

>  (b) An extended SMTP client MAY announce an intention to send mail
> containing any other character set from the 8859-n family.  An extended
> SMTP server MAY accept that assertion of intention, in which case, it
> assumes the same obligations for accurate and undistorted delivery as
> it does when it responds "250" to a RCPT TO.
>  (c) An extended SMTP server MAY, alternately, reject anything but
> 8859-1.

I don't like the mailer making decisions of what character sets I can
handle. I might be able to read a message using an obscure character set
noone other on the site uses (I have my own filters or I transfer that
mail to another machine). Even if I couldn't view it like the sender,
I'd still like to get the message. At least I would see that something
is wrong. I also would get the sender's mail-address. Maybe I could read
all or enough of the important parts of the message to understand it. I
really don't like that the message isn't sent when the mailer thinks the
receiver probably might not be able to read it, like X.400 does. It's
really frustrating to try to send an ASCII message and get it bounced,
because the mailers were configured for different character sets (maybe
ASCII and some national ASCII modification). There is no benefit of such
a stupid behaviour.

> The specific character set to be used (...) does not need to be
> designated in the envelope unless
>   (a) Something besides the extended SMTP lingua franca is to appear in
> the header (...).
>  (b) The header does not have an internal mechanism for designating
> alternate character sets.
>    But I'd argue for the envelope anyway.  I think that MTAs do get
> into the business of figuring out what is good for their UAs--our
> layering is not that clean.

There probably is need for other character sets than Latin-1 for some of
the headers, but I'd like to have these designated in the headers in some
way. And I don't like MTAs to make assumptions of what I can read as I
said above. On systems, where MTAs and UAs are very tied together, I
think inspecting the headers would still be a better way than to
complicate the protocol.

I think we could manage with only the 8-bit negotiation. It could be
done after HELO in some way, or maybe better with an alternative keyword
for DATA, like D8TA. You would lose a round-trip only when the MTA
doesn't understand this keyword.

Risto


-- 
 Risto Kankkunen                   kankkune@cs.Helsinki.FI (Internet)
 Department of Computer Science    kankkunen@finuh          (Bitnet)
 University of Helsinki, Finland   ..!mcsun!uhecs!kankkune   (UUCP)