[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Less is more


On Tue, 27 Apr 2004 23:30:47 +1000, Brett Watson <famous-mail-ng2@xxxxxxxxxxx> wrote:

On Tue, 27 Apr 2004 22:10, Frode Gill wrote: 
One of my hopes for mail-ng is that it will be easy
to implement, and not be forgiving about bad implementations.

The usual principle is "Postel's Robustness Principle", which states that an endpoint should be strict in what it sends, but liberal in what it accepts.

Exactly. And it seems like you understand my point in why this is not a good idea for mail-ng... Personally, I would be glad if the mail-ng server would be instructed to send non-conforming messages to /dev/null!


* Use an easily parsed timestamp (my advise: 64-bit number representing
timestamp and offset from UTC)

I applaud the general principle of "easily parsed timestamp", but there's an enormous can of worms waiting to be opened if you want to discuss this in any detail.

Of course. This is why I give advices, not final sollutions :-)
If we need an explisit timestamp or not is another question, but please don't let us settle for anything like the RFC822 Date-format, and all the interesting representations it has gotten in various mail clients, if we really do need one.


* Use one and only one charset (my advise: utf-8)

Does anyone see any major drawback in using UTF-8 only?
[snip]
This need not preclude other charsets from being carried in mail, but they would be treated as opaque binary data by the mail protocol.

I don't see any drawbacks in why it couldn't be the one and only charset. [Full stop].


* 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)

Discussion of XML is premature until we have some idea what data we need to transfer at particular moments. XML is good for certain types of structured data, but there may be better approaches for very lightweight messages or heavily binary-oriented messages.

...which is why I added xml-lookalike. My point is that it will be much easier to implement an xml kind of format rather than a MIME one, and I want to make sure implementing mail-ng according to spec will be as trivial as possible, without putting in too many restrictions.


I would like to have a header specifying the jurisdiction the
email is sent by.

Can you propose a means whereby the veracity of that header can be checked? What's to stop a sender from lying?

I expect mail-ng to be digitally signed and encrypted, and not as easily forged as RFC822-messages. I also expect mail-ng messages to be legally binding. But even if the sender lies, he would have to choose one jurisdiction and would be hold liable according to that one. If sender choses a very liberal jurisdiction, the recipient will most likely block this message as it exceedes the local one. Basically, all I want is some way for people to don't risk receiving messages that would be illegal in their local domain, and right now blocking all non-whitelisted messages sent from America is a quite daunting task. The sollution could be something very different than my suggestion, but we have a problem with the current protocol, and it should be resolved in the next.


How useful will it really be, relative to an independent third party opinion, like "blackholes.us"?

A local backholes.us-list would need to be updated very often, and with no local list we would need to have a lookup - in which we would get all the problems we have with DNS-servers nowadays (TLDs, anyone?). It might be one sollution, but I still think it will be more efficient, and easier to make legally binding, if this info is embedded into the protocol.

--
Frode Gill