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

[Ashley Dixon]

On Wed, Aug 26, 2020 at 08:33:58PM +0000, Caveman Al Toraboran wrote:
> On Wednesday, August 26, 2020 9:57 PM, Ashley Dixon <ash@××××××××××.uk> wrote:
>
> > Why the name "HillaryMail", and why does the logo contain a picture of
> > Margaret Thatcher? ;-)
>
> very true (re: thatcher).  now i cannot unsee the
> thatcher in the pixel art.  i have 2 options:
>
>     (1) rename protocol into thatchermail.
>     (2) find another pixel art that's actually for
>         hillary.

Nothing wrong with Thatcher.  Although, British politics are less  amusing  than
their American counterparts, but there are exceptions.
https://www.youtube.com/watch?v=HDVwidaHwSc

More seriously, as Grant said, it's  probably  best  to  stray  away  from  this
politically charged area entirely.  Mentioning leaked  e-mails  of  an  American
presidential candidate in the title of an e-mail solution is akin to  naming  an
SSL  implementation  something  like  Heartbleedin'.   It  just  gives  off  the
completely wrong "vibe".

> i got the thatcher pixel art from a site that
> claimed it's hillary [1].
>
> as for the name "hillarymail", nothing against
> her.  it's just that i heard so much about
> hillary's mails up to a point all mails started to
> feel as if they belong to her.

Yes, but (I assume) there were not many positive reports.  It does seem  an  odd
thing after which to name an e-mail solution!

> i intend to eventually write a reference
> implementation either way (hopefully).  specially
> that this seems to me very easy to implement, yet
> it seems also powerful.
>
> not sure what "formal r.f.c." means.
>
>   (a) if it means a less ambiguous description,
>       then "yes, but at a natural pace based on
>       demand" (in the spirit of occam's razor).

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...

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.

> but if it is possible to make it easier while
> still satisfying the constraints
> (goals/non-goals), then that's a good step forward
> (perhaps draft one?).

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.

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.

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 am interested, but gravely skeptical.

-- 

Ashley Dixon
suugaku.co.uk

2A9A 4117
DA96 D18A
8A7B B0D2
A30E BF25
F290 A8AA