Re: [gentoo-user] tips on running a mail server in a cheap vps provider run but not-so-trusty admins?
‐‐‐ Original Message ‐‐‐ On Saturday, August 22, 2020 12:10 AM, Grant Taylor wrote: > There is some nebulous area around what that actually means. But the > idea is that the receiving server believes, in good faith, that it has > committed the message to persistent storage. Usually this involves > writing the message to disk, probably via a buffered channel, and then > issued system calls to ask the OS to flush the buffer to disk. just to double check i got you right. due to flushing the buffer to disk, this would mean that mail's throughput is limited by disk i/o? or did i misunderstand? i sort of feel it may suffice to only save to disk, and close fd. then let the kernel choose when to actually store it in disk.
Re: [gentoo-user] tips on running a mail server in a cheap vps provider run but not-so-trusty admins?
‐‐‐ Original Message ‐‐‐ On Saturday, August 22, 2020 12:19 AM, Grant Taylor wrote: > > i was thinking (and still) if such relay-by-relay delivery increases > > probability of error by a factor of n (n = number of relays in the > > middle). e.g. probability of accidental silent mail loss is if one, > > or more, accidentally said "yes got it!" but actually didn't. i.e.: > > It definitely won't be a factor of n, where n is the number of relays. why? since relays are in series, and since each relay trusts next relay's "yup got it!", then error rate should add up for every extra step. no?
[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?)
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 rgrds, cm.
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] tips on running a mail server in a cheap vps provider run but not-so-trusty admins?
‐‐‐ Original Message ‐‐‐ On Thursday, August 27, 2020 12:21 AM, Grant Taylor wrote: > email emailemail > SMTP SMTP POP3S/IMAPS > A) [1]---(TCP)---[2]---(TCP)---[3]---(TCP)---[4] > > Now what you are proposing: > > email email email > TBD TBD TBD > HTTPS HTTPS HTTPS > A) [1]---(TCP)---[2]---(TCP)---[3]---(TCP)---[4] > > The number of layers has increased from three to four. that's true if "SMTP" is a single layer. which is also how networking engineers including those highly skilled ones in standard bodies commonly commonly talk about protocols (e.g. based on layers of that sort). so i see why it makes sense that you did it this way. but i this way of looking at protocols (despite being common) is wrong. i also disagree with the network layering proposed by osi or the other ones commonly published in books. i specially disagree with using such layering for studying the complexity of protocols. so i suggest that if we want to study the complexity of messaging systems, we better not count SMTP as a single thing (like how it is normally done in books and talks), but instead talk about it based on the fundamental tasks that it actually does. this way, SMTP becomes at least 2 layers: 1. "resource exchange" layer where binaries are made into a single giant text file by base64 encoding and then partitioned by rfc822. this part overlaps with http* and is much less efficient (rightfully, since email had to be backwards compatible as it is critical). 2. "resource use" where the mail server parses such exchanged resources (e.g. email bodies, attachments, etc) and then acts upon them (e.g. forward them, discard them, etc). and so will pop* and imap. this way, if we ignore the problem of maintaining backwards compatibility, then having http* in the "resource exchange" layer would be more efficient and simpler as there will be less protocols doing the "resource exchange" task (instead of having each do its own). i also think that the kind of resource that email exchanges is fundamentally identical to a subset of resources that are natively exchanged in the web. so i think the only reason that smtp/pop/imap have different resource exchange protocols is purely due to backwards compatibility due to how things evolved historically. - i suspect that we actually agree on everything, but speak different languages (possibly due to how books commonly talk about protocols and layering), or assume things beyond what's written. e.g. we agree that: 1. smtp/pop*/imap make the best messaging system today, and is not going away any time soon, thanks to its wide spread. most likely i'll be dead and still have multiple active smtp/imap/pop account. 2. smtp/imap/pop are imperfect and have many shortcomings that are "rightfully" not solved "cleanly" due to historical reasons and its critical nature which imposed on us the constraint of having to maintaining its backwards compatibility. 3. trying new protocols is fine. and is also fine to have sub-communities that use different messaging protocols if they find it more fitting. e.g. i'll probably end up using smtp/imap for talking to people in general, and use hillarymail [1] for talking to a closer nerdy community. [1] https://github.com/al-caveman/hillarymail
Re: [gentoo-user] tips on running a mail server in a cheap vps provider run but not-so-trusty admins?
‐‐‐ Original Message ‐‐‐ On Thursday, August 27, 2020 8:15 PM, Grant Taylor wrote: > On 8/27/20 7:00 AM, Caveman Al Toraboran wrote: > > > but i this way of looking at protocols (despite being common) is wrong. > > Why do you think that it is wrong? > > What is not factually correct about it? it depends on how you use it: - if you use it for what it is made for (making speech about protocols easier), then that's fine. not perfect, but not wrong either. - but if you use it to do some complexity analysis as you did earlier by counting such layers, then, you're wrong. because even though smtp appears as a single layer in such common diagrams, it is functionally 2 layers (one being a resource exchange layer overlapping with http). > > i also disagree with the network layering proposed by osi or the > > other ones commonly published in books. i specially disagree with > > using such layering for studying the complexity of protocols. > > If you're going to make such a statement, which is fine to do, you must > provide information ~> evidence as to why you are doing so and why you > think what you think. see above or previous emails. you're basically abusing such diagrams to perform protocol complexity analysis. i was trying to be indirect by blaming the common protocol layering for leading you to this mistake. what's happening is that you're simply abusing them to do what they are not made for. for details you can re-read my previous email(s) on how smtp is functionally at least 2 layers. > > so i suggest that if we want to study the complexity of messaging > > systems, we better not count SMTP as a single thing (like how it is > > normally done in books and talks), but instead talk about it based on > > the fundamental tasks that it actually does. this way, SMTP becomes > > at least 2 layers: > > I think that I see part of a problem. > > RFC 822 - Standard for the format of ARPA Internet Text Message - is > what defines what I was referring to as the opaque blob sent between > systems. > > I will argue that the content of the opaque blob that SMTP transfers is > independent of SMTP itself. > > > 1. "resource exchange" layer where binaries are made into a single > > giant text file by base64 encoding and then partitioned by rfc822. > > this part overlaps with http* and is much less efficient (rightfully, > > since email had to be backwards compatible as it is critical). > > > > SMTP* does not support binary in any (original) capacity. As such, > email service, which /rides/ /on/ /top/ /of/ SMTP, is where the encoding > ""hack was placed. This /encoding/ and / or /formatting/ is completely > independent of the SMTP protocol used to exchange opaque blobs between > mail servers. i'm amazed how you skipped the real point that i'm making about your incorrect layer-based protocol complexity analysis, and —instead— moved to talk about how email's inefficient binary encoding is due to rfc822 and not rfc821. it's irrelevant at several levels: - doesn't justify your layer-based complexity analysis earlier, either way. - no one discussed which rfc is the reason why smtp is being used for inefficient binary transfer. - the fact that attachments are inefficiently sent over smtp as per rfc822 is by itself due to bad historical design decisions in smtp that lead people to commonly use rfc822 with smtp. the several next paragraphs that you wrote are simply talking about whether smtp (rfc821) was born with a horrible binary encoding, or was it born retarded enough to push people to end up adding rfc822 to it in order to minimise suffering. which is irrelevant at many levels, so i'm skipping over them to save space/time. > > this way, if we ignore the problem of maintaining backwards > > compatibility, > > That is a HUGE if. One that I do not accept at all. You absolutely > MUST have backwards compatibility in some way. Even if that > compatibility is something that acts as an edge gateway between SMTP and > your new method. You MUST have backward compatibility in some way. also irrelevant. yes, that hypothetical "if" statement is indeed "huge". so? it's a hypothetical if statement to show another point: that your complexity analysis by counting layers is wrong. i'm once again amazed how you skipped the main point, and went on to write about how HUGE that hypothetical "if" statement is. (for the record i'm not suggesting to drop smtp's backwards compatibility, nor suggesting it would be easy.) > > then having http* in the "resource ex
Re: [gentoo-user] tips on running a mail server in a cheap vps provider run but not-so-trusty admins?
‐‐‐ Original Message ‐‐‐ On Friday, August 28, 2020 2:35 AM, Ashley Dixon wrote: > On Thu, Aug 27, 2020 at 09:07:03PM +0000, Caveman Al Toraboran wrote: > > > anyway i'm out of this. massive waste of time. i > > could've finished server-side hillarymail by it. > > Oh, come on. People on this list have decades of experience managing and > implementing e-mail protocols, and you call their (free) help a "massive waste > of time"? Stop being silly and realise that no initial proposal is completely > flawless. it's not against "people on the list". it's rather for them. because continuing talking to grant (and soon you) is fueling a useless conversation that is effectively vandalising the mailboxes of 100s of people on this list. now you're posting this yet another useless drama message trying to make it sound as if it's against "people on the list" or as if i'm too defensive of hillarymail. so now i'll also stop talking to you in this sub-thread (in addition to grant taylor). nothing personal. we may talk in other sub-threads. it's just that talking to you 2 in these late threads became a fuel to vandalise others' mailboxes. > As I keep urging you, define some goals (and as Grant said, start with > defining > the current problem), finish an initial standards document, and begin writing > a > reference implementation. Or just define some of the core algorithms with > pseudocode. I can almost-guarantee that you will start realising things that > need changing almost immediately upon doing so. nothing new. we already discussed this in the other sub-thread and, as i said there, i am already planning to write an implementation. and i'm already refining the draft. i don't know why you keep repeating non-new things over and over (zero information content). that sub-thread has also became very useless thanks to you and grant for talking about margaret thatcher, LaTeX and other unrelated things. zero actual comments about technical aspects. > Perhaps it is just me with my English sense of over-politeness, but I find > your > conduct to be remarkably audacious (and frankly rude) considering all the time > people are spending to help you. ... And if you don't want this sort of > on-line > discourse, why did you post on the list at all? is your "English" sense of "over-politeness" capable of sensing vandalism caused by having you post texts with low information content, or irrelevant info, to people's inboxes? (rhetorical)
Re: [gentoo-user] tips on running a mail server in a cheap vps provider run but not-so-trusty admins?
‐‐‐ Original Message ‐‐‐ On Friday, August 28, 2020 11:27 PM, antlists wrote: > On 26/08/2020 21:21, Grant Taylor wrote: > > > > so basically total expected number of protocols/layers used in the > > > universe, per second, will be much less if we, on planet earth, use a > > > mail system that uses HTTP* instead of RESXCH_*. > > > > I obviously disagree. > > Exactly. You now need a protocol/layer that says you're running "mail > over http" as opposed to "web". HTTP is tcp/80 that means web. As soon > as you start using it for something (anything) else you've just added > another protocol/layer. you know there is this almost neat concept called url? rumours say that urls can identify various web applications, ranging from websites, rss, games, video, and, guess what? mails. all over http/https/h2 over same tcp 80/443. hard to believe, but this magic is known since early 1990s. are you saying [1] won't work unless we have a new tcp port for it? [1] https://github.com/al-caveman/hillarymail (work in progress, incomplete) i don't want to repeat. re-read this sub-tread, and search for "resource exchange layer". you really don't know what's http*. also not going to respond to you in this sub-thread any more (ignore list is growing...). side note: i seriously suspect that we got GPT-4 bots in the list.
Re: [gentoo-user] tuning desktop appearance for legibility
‐‐‐ Original Message ‐‐‐ On Thursday, September 3, 2020 6:50 PM, John Blinka wrote: > Hi, Everyone, hello big dawg! quick point: imo the problem of gray texts on white backgrounds, or scrollbars or whatever, that you have, is not related to aging. imo it's rather related to stupid web developers. not even a mutant with infrared vision can use these websites. > 1) How do you cope with this problem? i cope by these: - use pixel-based fonts for everything as much as possible, specially for key apps like: terminal, window manager and browser. they become so much readable. i use "terminus-font" (and previously used "dina") in my urxvt as well as my other apps as much as i can. i notice one of the major problems with fonts is actually not our eyes, but in many cases how fancy fonts blur. i was personally amazed by how i could use much smaller fonts, while maintaining readability, by simply switching to pixel-based fonts, such as terminus. - for my browser, i use custom user css for different modes. i also configured shortcuts for my browser, so that i change these user css files based on which ones work best with the site. generally, i have "night.css" and "wiki.css" that i change by keyboard shortcuts. the "night.css" is very generic and changes background/foreground texts for pretty much 90% of sites properly. this way, i am no longer bound by bad colors chosen by web designers. - i use i3 as window manager, with lots of shortcuts. i also use qutebrowser (a browser with good vim shortcuts). this way, throughout the day, i rarely end up needing to use the mouse to do things. i only use the mouse for ultra quirky websites with fancy javascript links that are not clickable by qutebrowser's shortcuts. so thanks to using keyboard shortcuts, a website can have thin gray scrollbar on a gray background and i don't care. because i scroll by shortcuts, not by bars. in fact, my qutebrowser's interface has scrollbars disabled altogether to use pixels, which i paid dear money for, for real use. > 2) Is there an xfce theme and icon package you > recommend? Or maybe something other than xfce? > I like xfce, and have never been attracted to > integrated desktops like kde and gnome, but if > they’ve got a credible solution, I’m willing to > try. i would suggest try keyboard-based window managers. my 1st suggestion is i3. it's actually perfectly usable for all applications. it's tiling-based, but also has floating functionality, and does a fine job eliminating need of clicking around on tiny things. > 3) Are there lower level ways of tweaking my > current desktop? For example, changing colors > in the 2 examples I gave above from black on > dark gray to black on white? Could that be done > with a little judicious editing of color > settings somewhere, or adjusting colors on an > icon? I don’t know how desktop appearances are > programmed, so I don’t know where on the > spectrum of trivial->apocalyptic this lies. user style sheets. maybe have a look here (i also talked about it above): https://userstyles.org/styles/browse/css or, if you dislike fiddling with these, maybe some use some browser add-ons that offer things like "night mode", or "contrast mode", by which they apply their own custom styling to fix mistakes of web designers. - optional/offtopic: extra text if you have coffee - i think this problem that we have could've been avoided if the web was originally designed to only deliver content, without any power to dictate appearance, so that appearance is 100% a task that a local client should choose. imo this could've been done easily, because websites in the internet follow a finite number of "document classes" (if we call them so). the vast unique changes that web designers make are just pointless. if the web was designed this way, then today we would've had a much happier time of achieving 100% consistent look for all websites optimized for our readability. but too bad, that is not done, so we have to use custom user style sheets which works for most of the time. for people who really want js and fancy rendering, they could use a separate app for their "instant js games". there is absolutely no reason why the entirety of the web has to be so turing-complete just because someone wants to play games.
Re: [gentoo-user] tuning desktop appearance for legibility
‐‐‐ Original Message ‐‐‐ On Thursday, September 3, 2020 11:19 PM, John Blinka wrote: > Could you elaborate on this? Don’t know css, but could pick it up. I’m > assuming that web pages already contain css code to direct their > appearance. yes. > So you apparently have some alternate appearance you prefer, > with your own alternate coding, and you somehow tell the browser to use > yours instead. Am I anywhere close to getting the broad outlines of the > process correct? correct. we basically create a custom css file, with colors defined for various html tags/elements as per our preference. we then hand the browser that css file, and tell it "after you load the site, add our custom css, and overwrite whatever the site originally wanted". the way to do this, we add "!important" in our new css. "!important" will make the overwrite. here is an example of such css with "!important": https://github.com/alphapapa/solarized-everything-css/blob/master/css/solarized-dark/solarized-dark-all-sites.css this is how i look at it. maybe some gurus can further elaborate on this with better technical correctness. > If so, how does this intercept and substitute process > work? (I see you provide a link below, but it doesn’t work here...) with firefox/chrome there is "stylish" plugin/add-on. i don't know how it is today, of if there is any better ones. i used to use them several years in the past. you basically select the css you want to use to overwrite site's css. with qutebrowser, i added these in my config.py file: c.aliases['style-none'] = 'config-unset -t content.user_stylesheets' c.aliases['style-night'] = 'set -t content.user_stylesheets night.css' c.aliases['style-wiki'] = 'set -t content.user_stylesheets wiki.css' where "night.css" and "wiki.css" are names of user style sheets that i downloaded from the web here "style-none", "style-night", ..., are nothing but commands in qutebrowser, that you execute by typing ":COMMAND". so if i want to activate night mode, i type ":style-night" without double quotes, then the whole thing becomes dark bg with white fg. of course qutebrowser has tab completion, so i don't need to type full thing. e.g. usually i just type ":sty..." until i pick one i want. of course you can add as many as you want. since different ones work better for different sites. there, i added "style-wiki" that's specifically made for wikipedia. i got it from userstyles.org years ago before it was so slow. > Not promising. The page doesn’t load except for a rotating colorwheel in > the center followed by a 504 gateway timeout. Will try again later. yes. sadly https://userstyles.org/ is now too slow and doomed with excess javascript. it was not like this some years ago. either way, you can obtain those css files by other means (not limited to userstyles.org). e.g. google for them around, or even make your own.
Re: [gentoo-user] tuning desktop appearance for legibility
‐‐‐ Original Message ‐‐‐ On Friday, September 4, 2020 12:06 AM, Caveman Al Toraboran wrote: > with qutebrowser, i added these in my config.py > file: > > c.aliases['style-none'] = 'config-unset -t content.user_stylesheets' > c.aliases['style-night'] = 'set -t content.user_stylesheets night.css' > c.aliases['style-wiki'] = 'set -t content.user_stylesheets wiki.css' just to add a note against my suggestion: - qutebrowser is based on qt libraries, such as qt-webengine, and hence requires a big compile time. so unless you really like the vim user interface of qutebrowser, you may not like experience of waiting for long compile time of big qt libraries. i'm sure there are people in this list who know good plugins for chrome/firefox that does the same thing (or better). but generally, the idea of using user style sheets for websites, is a neat idea that —imo— worth trying regardless of which browser you use.
Re: [gentoo-user] tuning desktop appearance for legibility
‐‐‐ Original Message ‐‐‐ On Saturday, September 5, 2020 1:09 PM, Wols Lists wrote: > Isn't that how the web originally WAS designed? That the web-site sent > content and the browser determined how it was displayed? sort of. it was not very clear and they could've gone either direction. so they had to answer the question: where to go? they thought a bit and concluded: "let's go turing-complete with built-in drm and enough fluff to make viewing a 2D page (e.g. cnn.com) take almost twice as much RAM as that of a 3D game (e.g. quake-iii) [1]. but remove marquee!" even though i dislike how the web ended up being, there is one side effect that i like: - making the web turing-complete served as an experiment to explore what humans want. if web devs didn't have the power to freely do things, we wouldn't have known what do they want, and which idea is good/bad. of course, the web also morphed into other messy things that didn't have any good side effects. such as the drm, and the many information leakages that are so ridiculous they effectively render "authentication" sort of redundant; google may identify us by our browsers' fingerprints and call it a day. as if not enough, goog also graciously give us x-client-data for free [2]. that said, i think the decades old experiment is over, and i think we've seen enough to conclude a few things from this experiment. i suggest that we must deprecate http/js/css/etc, and split the web into two components: (1) page content definition format (PCDF): an efficient binary format that only defines content, with no presentation information. imo this is very doable because, while the content in the web varies drastically, their _type_ is pretty finite (e.g. nav bar, copyright notice, related topics, body, etc). i think if we survey websites, it is easy to see that there is only a small number of content types. the client obtains PCDF documents via https then presents them based on user's viewing preference which is purely defined locally in his computer (the server has no business in knowing any of it). this way navigation bars, copy right notices, etc are placed in a standardized manner for every user based on what he cares most about. this way, we won't need to mess up with user style sheet hacks per website. plus page size will become extremely small, and ridiculously efficient to render thanks to the binary format, and much ore responsive. it would be so fast you'd feel that the page has loaded even before you clicked on the link. (2) application containers: this is the part why the web has javascript support, and this is still a part where is not clear to me if we actually need it. i think this is also very redundant with many alternatives doing basically the same thing, such as docker. maybe this is just "package manager in a glorified chroot"? this side is still unclear to me, and i don't know where it is going. --- [1] https://www.networkworld.com/article/3175605 [2] https://www.theregister.com/2020/03/11/google_personally_identifiable_info/
