Re: [gentoo-user] new mail protocol rfc (was Re: tips on running a mail server in a cheap vps provider run but not-so-trusty admins?)

[Grant Taylor]

On 8/26/20 7:07 PM, Ashley Dixon wrote:
> I meant (a), in the sense that you  should  probably  write  it  up
> in  a  more presentable fashion than a GitHub README page.  You might
> want to nicely typeset it in TeX or something to make it seem more
> serious. Just a suggestion...

I'm sure there are those that will disagree with me.  But I don't think 
it's as important how professional things look as long as they are sound 
ideas.  Lest it be an ad hominem attack.  Which, as previously indicated 
is not a good thing.

Good ideas should be able to stand on their own.  If Caveman's idea 
turns out to be deemed better on it's technical merits, then the text vs 
HTML vs TeX/LaTeX formatting shouldn't matter.

> In which language are you intending to write the reference
> implementation?   I'd suggest writing it in a relatively low-level
> language, so it's  easier  to  read and port without making too
> many assumptions.

I would probably argue that using a mid to higher level language or even 
a pseudo code for documentation / explanation might be advisable.  I 
think that it's more important to get the idea out, in a way that it's 
easily understandable and re-implementable by others.

Is it better to have the first implementation be crem de la crem and the 
overall idea not be adopted?  Or would it be better for the original 
implementation to fade into history while the concept takes over and 
surpasses current email solutions?

> You really need to define more goals and non-goals; two non-specific
> goals,  and one non-goal really isn't enough to form an entire
> specification.

I would suggest starting with a problem statement.  Clearly document and 
articulate what you think is wrong with the current email solutions. 
After all, I believe that's the root of the motivation for this.

Once you have a clear problem statement, start developing possible 
solutions.  I encourage multiple -> many if not an order of magnitude 
more than the problems.

Once you have multiple possibilities, then you can objectively compare 
and contrast the possibilities to see which one is the best.

> Additionally, I noticed that you have written that the "actual
> message" will  be restricted to UTF-8 with no HTML/JS/CSS,  which  you
> collectively  describe  as "self-hating formats" (?).  While I (and
> most on this list) despise the  use  of the aforementioned formats
> in e-mails to the appropriate extent, I  struggle  to see how you
> are going to prevent them being transmitted using HillaryMail.

If there is anything that the industry is good at, it's encoding things 
such that they can be transported by something that can't natively 
support the unencoded thing.

> All of the control codes of HTML are fully representable in ASCII,
> which  is  a strict subset of Unicode.  How are you going to prevent
> people transmitting HTML over the protocol?  It is up to the client
> to parse the HTML into  its  intended aesthetic form; the server
> has nothing to do with it.  The only solution I could imagine is
> rejecting all messages containing attachments with MIME  types  other
> than plain-utf8, but is that really a good idea?

I think trying to restrict things will do more harm to the idea than the 
idea itself would do good.  It's likely to cause people to reject it out 
of hand as why would they want to choose something that fights them?

> I am interested, but gravely skeptical.

Well said.

I am not overtly opposed to the concept of replacing SMTP and enhancing 
email.  I just want to make sure that whatever eventually does replace 
SMTP does so because it can stand up to technical scrutiny far worse 
than anything I can throw at it.  It should succeed because it really is 
better, not because someone wants it to be better.

Historians will judge us and the decisions we make harshly, just like we 
judge our previous technical brethren harshly for their decisions.



-- 
Grant. . . .
unix || die