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?)
On Friday, 28 August 2020 01:30:58 BST Ashley Dixon wrote: > I can't really comment on LaTeX, because I've never really used it; from > the small snippets I've seen, I just assume it's TeX with a hell of a lot > of useful macros. I've always just stuck to TeX, with a copy of the > TeXBook handy. I used LaTeX for a time in the mid-80s. From what I remember, you're right about the macros, but they're a big enough addition to lift the language from assembler to a 'proper' symbolic language - Coral, say, or Fortran. Speaking metaphorically, that is. -- Regards, Peter.
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?)
On Thu, Aug 27, 2020 at 06:02:43PM -0600, Grant Taylor wrote: > On 8/27/20 11:55 AM, Ashley Dixon wrote: > > Nevertheless, as xkcd so brilliantly explains, TeX inspires a level of blind > > trust in the content of a document [2]. As long as you avoid proposing > > standards in the form of an animated GIF, you're probably going to be OK. > > ;-) > > I wonder if this is a side effect of the fact that TeX / LaTeX is a > difficult markup language to work in and takes considerably more time and > effort than simple text. As such, there is a good chance that the idea that > someone takes the time to express in (La)TeX is probably more completely > thought out than simple text. After all, why would someone spend the time > and exert the effort to finely polish a half baked idea in (La)TeX? I might have worded it ambiguously in my initial response, but I only suggested TeX be used once his idea had surpassed the "half-baked" stage. I can't really comment on LaTeX, because I've never really used it; from the small snippets I've seen, I just assume it's TeX with a hell of a lot of useful macros. I've always just stuck to TeX, with a copy of the TeXBook handy. The only significant issue I have with plain TeX are the difficulties regarding CJK (Chinese, Japanese, and Korean), considering I write many documents in Trad. Chinese and Japanese. I heard XeTeX fixed this, although I've never tried it. > Given that things grow and evolve, I think it means that the reference > implementation needs to be used /somewhere/ for the people maintaining it to > gain experience and knowledge germane to said reference implementation. > Granted, this can be a small subset and does not need to be on the front > lines. Yes, my comment was regarding production deployments of HillaryMail. > I also think that it's important to keep in mind that sometimes there are > external limitations that dictate what can and can not be done. Like the > fact that communications circuits were not guaranteed to be 8-bit clean when > email (RFC 822 and what predates it) and SMTP (RFC 821 and what predates > it). It's not any more fair to blame the authors of RFC 821 for not > supporting 8-bit than it is to blame Sir Tim Burners-Lee for not including > encryption when he developed HTML and HTTP. Absolutely, but we are not talking about the absence of features here: rather the addition of "features" to arbitrarily limit the flexibility of a transportation protocol. Sir Burners-Lee would certainly be on my list-of- undesirables if he took steps to _prevent_ encryption from ever appearing in future versions of the protocol! ;-) -- Ashley Dixon suugaku.co.uk 2A9A 4117 DA96 D18A 8A7B B0D2 A30E BF25 F290 A8AA signature.asc Description: PGP signature
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?)
On 8/27/20 11:55 AM, Ashley Dixon wrote:
Well said; thanks for the correction.
Of course. My intention is to positively contribute to and learn from
the community.
Mathematical notation can be seen as a tightly coupled analogue
to this sort of typesetting: the same book that introduced
Algebraic expressions (Cossike numbers) and the equals sign ('=')
into the English-speaking world also suggested the use of
the word "zenzizenizenike" to represent `x^8` [1]. Solid ideas
will stick due to, as you said, their own merits; the form of the
representation is generally redundant.
Nevertheless, as xkcd so brilliantly explains, TeX inspires a level
of blind trust in the content of a document [2]. As long as you avoid
proposing standards in the form of an animated GIF, you're probably
going to be OK. ;-)
I wonder if this is a side effect of the fact that TeX / LaTeX is a
difficult markup language to work in and takes considerably more time
and effort than simple text. As such, there is a good chance that the
idea that someone takes the time to express in (La)TeX is probably more
completely thought out than simple text. After all, why would someone
spend the time and exert the effort to finely polish a half baked idea
in (La)TeX?
Disclaimer: I'm speaking in general and do not mean to imply anything
towards Caveman's efforts. It takes gumption to go against the status quo.
I concur, but this was about the reference implementation.
Do you mean reference as opposed to initial. Meaning that the reference
implementation has had some time to grow and evolve and be optimized.
Fair enough.
It would be impossible to make the initial implementation the crème
de la crème of all implementations, unless the protocol was never
intended to expand.
With what little I know about statistics, I think that there is a very
small but still greater than zero percent chance of it happening. It's
just *EXTREMELY* unlikely. ;-)
We do see some reference implementations being used as the de
facto choice for supporting many standards, such as Apache Tomcat
as the ref. imp. for Java Servlets, but as the name would
suggest, reference implementations are only intended to be used
as a reference to developers of future implementations.
I don't think anything precludes the use of the reference implementation.
Given that things grow and evolve, I think it means that the reference
implementation needs to be used /somewhere/ for the people maintaining
it to gain experience and knowledge germane to said reference
implementation. Granted, this can be a small subset and does not need
to be on the front lines.
Moreover, these ridiculous restrictions only encourage various
implementations to deviate from the standard, adding their
own non-standard extensions like "HillaryMail HTML support".
Implementation developers are always going to add stupid things to
their software (just look at the GNU `typeof` introspection mess),
but the standard text itself should certainly not encourage
such behaviour.
Indeed.
I also think that it's important to keep in mind that sometimes there
are external limitations that dictate what can and can not be done.
Like the fact that communications circuits were not guaranteed to be
8-bit clean when email (RFC 822 and what predates it) and SMTP (RFC 821
and what predates it). It's not any more fair to blame the authors of
RFC 821 for not supporting 8-bit than it is to blame Sir Tim Burners-Lee
for not including encryption when he developed HTML and HTTP.
--
Grant. . . .
unix || die
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?)
On Wed, Aug 26, 2020 at 10:26:59PM -0600, Grant Taylor wrote:
> 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.
Well said; thanks for the correction. Mathematical notation can be seen as a
tightly coupled analogue to this sort of typesetting: the same book that
introduced Algebraic expressions (Cossike numbers) and the equals sign ('=')
into the English-speaking world also suggested the use of the word
"zenzizenizenike" to represent `x^8` [1]. Solid ideas will stick due to, as you
said, their own merits; the form of the representation is generally redundant.
Nevertheless, as xkcd so brilliantly explains, TeX inspires a level of blind
trust in the content of a document [2]. As long as you avoid proposing standards
in the form of an animated GIF, you're probably going to be OK. ;-)
> 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.
I concur, but this was about the reference implementation.
> 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?
It would be impossible to make the initial implementation the crème de la crème
of all implementations, unless the protocol was never intended to expand. We do
see some reference implementations being used as the de facto choice for
supporting many standards, such as Apache Tomcat as the ref. imp. for Java
Servlets, but as the name would suggest, reference implementations are only
intended to be used as a reference to developers of future implementations.
> 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?
Moreover, these ridiculous restrictions only encourage various implementations
to deviate from the standard, adding their own non-standard extensions like
"HillaryMail HTML support". Implementation developers are always going to add
stupid things to their software (just look at the GNU `typeof` introspection
mess), but the standard text itself should certainly not encourage such
behaviour.
Ashley.
[1] https://en.wikipedia.org/wiki/Zenzizenzizenzic
(My favourite thing about this mad notation is the words used to describe it in
the original manuscript: "represent the square of squares squaredly".)
[2] https://xkcd.com/1301/
--
Ashley Dixon
suugaku.co.uk
2A9A 4117
DA96 D18A
8A7B B0D2
A30E BF25
F290 A8AA
signature.asc
Description: PGP signature
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?)
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
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?)
On Wed, Aug 26, 2020 at 08:33:58PM +, Caveman Al Toraboran wrote: > On Wednesday, August 26, 2020 9:57 PM, Ashley Dixon > 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 signature.asc Description: PGP signature
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?)
On Wednesday, August 26, 2020 9:57 PM, Ashley Dixon 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. 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. i also named my passwords manager after nsa [2] for a similar reason (even though i find nsa to be much more trustworthy than my neighbours). > More seriously, do you intend to write a reference implementation, or submit > this as a more formal R.F.C. in the event of it attracting more attention? 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). (b) if it means an r.f.c. submitted to isoc/ietf, then "no". i think we should ignore standard bodies for awhile since they seem to be ignoring us. > Furthermore, accusing every SMTP/POP/IMAP user to be an "idiot" may not be the > best way of attaining support; I must admit, I have never seen that in an > initial protocol proposal. imo that's a parsing error on your side. to me "idiot" didn't refer to smtp/pop/imap users. it rather referred to those those who can't use address books or bitcoin. either way i've just replaced "idiots" by "people". "idiot" wasn't justified either way. > I'm also slightly confused regarding the "goals" section. By "easy to > install/use", do you mean "easy" for the people implementing the protocol, or > the people making use of said implementations? "Traditional" SMTP mail clients > have always been pretty straight-forward for me, although the difficulty > involved in implementing an M.T.A. is another story. I find this point rather > equivocal. i mean easy for both, but subject to the constraints specified under "goals" and "non-goals". e.g. if becoming easier would cause the protocol to end up needing to trust a sys admin, then that's not acceptable. 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?). -- [1] http://pixelartmaker.com/art/dffec5c6b08b94e [2] https://github.com/al-caveman/nsapass note: trying to remove pexpect dependency as it sometimes causes indefinite waiting. so it is not ready for those who want a solid app yet. that said, i really like it so far. imo after removing "pexpect" it will be perfect.
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?)
On 8/26/20 3:33 PM, Grant Taylor wrote: I would suggest using any reference to Hillary Clinton. Typo: I would suggest *NOT* using any reference to Hillary Clinton. -- Grant. . . . unix || die
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?)
On 8/26/20 2:33 PM, Caveman Al Toraboran wrote: as for the name "hillarymail", nothing against her. I would suggest using any reference to Hillary Clinton. I believe her name is too politically charged to use it in good faith. 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. Almost everything I heard about it seemed to be negative. What little I heard that wasn't negative was simply neutral. My opinion is that the name (independent of H.C.) and H.C.'s association would cause me to choose a different name. I'd suggest something that describes what it does. Note: I've not ready your proposal yet. I've earmarked to do so when I have more time. 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. "seems" is the operative word. I think you will find that there is MUCH more to it than what I think you think there is. 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). How does Occam's Razor or Parsimony apply to this? (b) if it means an r.f.c. submitted to isoc/ietf, then "no". RFCs are decidedly outside of ISOC / IETF. i think we should ignore standard bodies for awhile since they seem to be ignoring us. Those sentiment / attitude is concerning to me. Just because you don't like something or disagree with it is not in and of itself a reason to ignore or avoid it. Especially when it is (RFCs are) the well established process to do something in the Internet community. imo that's a parsing error on your side. to me "idiot" didn't refer to smtp/pop/imap users. I would strongly suggest anything that can be construed as an ad hominem attack. it rather referred to those those who can't use address books or bitcoin. I think those are two very different things. Address books have existed for a long time and are included in all prominent devices / email clients in one form or another. The same can't be said about bitcoin. either way i've just replaced "idiots" by "people". "idiot" wasn't justified either way. There's no place, much less need for ad hominem attacks in standards documents, be they formal, e.g. ISO, IETF, or non-standards based, e.g. RFC. i mean easy for both, I find the goal of easy for the user to use and easy for the developer to develop to be almost diametrically opposed to each other. In my experience, it's either been a pay it forward once (developer) or pay it back perpetually (user). Which are you prioritizing? The developer or the user? I would strongly suggest the developer pay it forward so that the end users don't have to perpetually pay it back. but subject to the constraints specified under "goals" and "non-goals". e.g. if becoming easier would cause the protocol to end up needing to trust a sys admin, then that's not acceptable. Elaborate on what "trusting a system administrator" means and why it's not acceptable. I think you will find that there are regimes that will not allow technology that they can't see into and observe. As such, they will dictate that the technology trust the system administrator (regime). Lest they ban the technology. 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?). The requirement to go from informational RFC to standards track RFC is multiple independent implementations. So not only do you need to get your implementation working, but you also need to get someone else to completely independently create their own implementation and it must be interoperable with yours. Anything less and you'll never achieve anything but an informational RFC status. And you will need a standards track RFC status to get the big players to even think about entertaining the notion of this. -- Grant. . . . unix || die
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?)
On 8/26/20 1:57 PM, Ashley Dixon wrote: On Wed, Aug 26, 2020 at 05:19:16PM +, Caveman Al Toraboran wrote: hi. i request comments on this new mail protocol which i plan to implement some day if things turn out well. here is its zeroth draft: https://github.com/al-caveman/hillarymail I like what I see, so far. Interesting proposal. A few non-technical questions: Why the name "HillaryMail", and why does the logo contain a picture of Margaret Thatcher? ;-) More seriously, do you intend to write a reference implementation, or submit this as a more formal R.F.C. in the event of it attracting more attention? Nice idea. I suggest the R.P.4 so it can stay up 24/365. Furthermore, accusing every SMTP/POP/IMAP user to be an "idiot" may not be the best way of attaining support; I must admit, I have never seen that in an initial protocol proposal. I'll wear that moniker, as a follower and implementor and testor. I'm also slightly confused regarding the "goals" section. By "easy to install/use", do you mean "easy" for the people implementing the protocol, or the people making use of said implementations? "Traditional" SMTP mail clients have always been pretty straight-forward for me, although the difficulty involved in _implementing_ an M.T.A. is another story. I find this point rather equivocal. Whatever grant offers, surely I'll at least attempt to implement. email services are getting hammered, from a traditional functional perspective. I do not like what the big corps are doing and just want a standards complint , reasonable secure solution. Is there something better for me to follow than this offering from grant ? From the private emails I have received, over the last month or so, there is quite and interest in running your own (secure?) DNS and email services Perhaps there is a solution for the R.P.4 for other linux distros I have not found, yet? If so, I'd still want a gentoo centric solution. hth, James
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?)
On Wed, Aug 26, 2020 at 05:19:16PM +, Caveman Al Toraboran wrote: > hi. i request comments on this new mail protocol > which i plan to implement some day if things turn > out well. here is its zeroth draft: > > https://github.com/al-caveman/hillarymail Interesting proposal. A few non-technical questions: Why the name "HillaryMail", and why does the logo contain a picture of Margaret Thatcher? ;-) More seriously, do you intend to write a reference implementation, or submit this as a more formal R.F.C. in the event of it attracting more attention? Furthermore, accusing every SMTP/POP/IMAP user to be an "idiot" may not be the best way of attaining support; I must admit, I have never seen that in an initial protocol proposal. I'm also slightly confused regarding the "goals" section. By "easy to install/use", do you mean "easy" for the people implementing the protocol, or the people making use of said implementations? "Traditional" SMTP mail clients have always been pretty straight-forward for me, although the difficulty involved in _implementing_ an M.T.A. is another story. I find this point rather equivocal. -- Ashley Dixon suugaku.co.uk 2A9A 4117 DA96 D18A 8A7B B0D2 A30E BF25 F290 A8AA signature.asc Description: PGP signature
