On Tue, 27 Apr 2004 11:20:54 -0400, Keith Moore
<moore(_at_)cs(_dot_)utk(_dot_)edu> wrote:
* Use one and only one charset (my advise: utf-8)
so you don't want people to be able to send documents that happen to be
written in other charsets? or you want to force them to translate,
sacrificing transparency?
Sending documents in other charsets are fine by me (but why do we keep on
using all these charsets? Lets move on, shall we?). If the document is
going to be parsed or displayed by a mail-ng server or client I actually
DO want it forced into utf-8 (or whatever charset is best suited)
* Use one and only one content transfer encoding (my advise: 8-bit)
so you don't want binary transparency?
OK, a bitstream then. What I don't want is QP, BASE64, DQUOTES,
quoted-pair, HTML-entities and the lot.
I would like to have a header specifying the jurisdiction the email is
sent by.
absent some way to authenticate that information, I'd simply claim that
the mail was sent from the jurisdiction with the least restrictive rules.
Which is fine by me, but unless I have whitelisted you it would of course
cause me to drop the mail long before it reached my screen.
I expect spam to be a non-issue in mail-ng, but having a jurisdiction
header would make it easier to drop messages violating local laws
nah, the spammers would just move to some other country.
I already pointed out that I expect spam to be a non-issue, but with a
legally binding country code in the header, my point is that you can run
to whatever country you want. If you send me content that violates my
laws, I have two choices. If you are within your local laws, I will block
your country, and if you are outside your local laws, I will sue you.
Filtering based on the ISO Country Code List would be
much easier than keeping a list of IP ranges up to date.
the last thing we need is to encourage more stupid spam filters.
see http://www.cs.utk.edu/~moore/opinions/spam-filters.html
The spam-filtering that article discusses is seriously outdated.
--
Frode Gill