While working on making a mail client, an important task is to make
work-arounds for badly implemented mail clients and -servers, and fix my
own spec violations. One of my hopes for mail-ng is that it will be easy
to implement, and not be forgiving about bad implementations. For a start,
these are a few ideas:
* Use an easily parsed timestamp (my advise: 64-bit number representing
timestamp and offset from UTC)
* 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?
* Use one and only one content transfer encoding (my advise: 8-bit)
so you don't want binary transparency?
* Use an easily implemented envelope (my advise: xml or xml-lookalike,
with data-size attribute for a scheme identical to IMAP4 literals to
prevent a need for escaping)
if you aren't going to use XML (and you shouldn't) then don't make it
look at all like XML. that creates too much potential for confusion
and annoyance, and won't make anybody happy.
In addition, internet is turning into a legal battleground rather fast
these days. 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.
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, as we currently see when the American lack of anti-spam laws cause
my Norwegian mbox to be filled with American spam that would be illegal to
send from Norway.
nah, the spammers would just move to some other country.
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
--
Regime change 2004 - better late than never.