james wrote: > On 8/21/20 4:10 PM, Grant Taylor wrote: >> On 8/21/20 11:01 AM, Caveman Al Toraboran wrote: >>> yes, i do consider re-inventing octagonal wheels. >> >> I think that it's occasionally a good thing to have a thought >> experiment about how $THING might be made better. >> >> It's probably good to have discussions around green feel types of >> replacements. >> >> But it's important to eventually assess the pros and cons of the old >> (as it exists), the new (as from green field), and the transition >> between the two. >> >> Sometimes the new doesn't warrant the transition, but it does provide >> an option that might be worth augmenting into the old. >> >> If nothing else, it's good to have the discussions and be able to >> answer why something was done or chosen to remain the same. >> >>> here, i'm just "asking" to see what makes the "safely stored" >>> guarantee. >> >> MTAs are supposed to be written such that they commit the message to >> persistent storage medium (disk) before returning an OK message to >> the sending server. >> >> 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. >> >> Is there room for error?� Probably. >> >> Had the server made (more than) reasonable effort to commit the >> message to disk?� Yes. >> >> The point being, don't acknowledge receipt of the message while the >> message is only in the MTA's memory buffer.� Take some steps to >> commit it to persistent storage. >> >> That being said, there are some questionable servers / configurations >> that will bypass this safety step in the name of performance.� And >> they /do/ /loose/ /email/ as a negative side effect if (when) they do >> crash. This is a non-default behavior that has been explicitly chosen >> by the administrators to violate the SMTP specification.� Some MTAs >> will log a warning that they are configured to violate RFCs. >> >>> got any specific definition of what makes a storage "guaranteed"? >>> e.g. what kind of tests does the mail server do in order to say >>> "yup, i can now guarantee this is stored safely!"? >> >> It's more that they do something safe (write the message to disk) >> instead of risky (only store it in memory). >> >> Everything can fail at some point.� It's a matter of what and how >> many reasonable steps did you take to be safe.� Read: Don't cut >> corners and do something risky. >> >>> i guess you think that i meant that a relay should be mandatory? >> >> Sending / outbound SMTP servers /are/ a relay for any messages not >> destined to the local server. >> >> There is almost always at least two SMTP servers involved in any >> given email delivery.� All but the final receiving system is a relay. >> >>> (yes, a relay doesn't have to be used.� i'm just describing some >>> uses of relays that i think make sense.� (1) indicate trust >>> hierarchy, (2) offload mail delivery so that i can close my laptop >>> and let the relay have fun with the retries.� not sure there is >>> any other use.� anyone?) >> >> There are many uses for email relays.� A common one, and best >> practice, is to have an /inbound/ relay, commonly known as a backup >> email server. The idea being it can receive inbound messages while >> the primary email server is down (presumably for maintenance). >> >> Many SaaS Email Service Providers (ESPs) /are/ relay servers.� They >> receive email from someone and send it to someone else. >> >> A number of email hygiene appliances function as an email relay >> between the world and your ultimate internal email server.� >> Services that filter inbound email qualify here too. >> >> It is common, and I think it's best practice, to have web >> applications send email via localhost, which is usually a relay to a >> more capable hub email server which sends outbound email.� Both of >> these layers are relays. >> >> A relay is the same thing for email that a router is for a network. > > WOW do I love these discussions, but let me 'cut to the chase'. > > I'm proposing, via a small corp I own, to purchase up to (3) dual > Rasp.pi 4 setups of (2) R.Pi.4 8gig ram setups > and send them to the devs WE all decide on. Let's us start compiling > up the codes, keep it simple (for now) and implement them with > gentoo-users as the testers of the email services. > > > These discussions should be continued to everyone's benefit. However > there are way more than (3) folks on these threads who are most > capable to do this community prototyping. If WE do not act and get > hundreds of these deployed, email, as we know it via RFCS and other > standards may just disappeaar, or be relegated to the far reaches of > the Internet. What I have read, is standards based email services, > particularly by small organizations, are under extreme pressure by > large corporations to be marginalized out of existence. > > So any of the folks in these treads can announce publically, or send > me private email as to your concerns. Public is best, but, I > understand the needs for private communications sometimes. So yea, > I'll personally finaces, at least 6 months of (3) projects. > I'll take all input, but will make my (funding) decision, in a focus, > quick strategy. > > James Horton, pe
I wouldn't be able to right now, just bought a new mattress set, mattress topper and other bed type stuff, but once I get that behind me, I'd be happy to buy at least one myself and compile stuff on it for testing. I'm not a coder by any stretch of the imagination. Heck, my scripts are not likely considered that by most here. I'm just not sure what else to call them. If I ever got bored, ran out of time or whatever, I could send the thing to a dev that is in the USA and easy to ship to, and let them play with it for a while. Only downside, my internet isn't dial-up but it's only a couple steps above it. Data transfer, especially going upstream, would be slow. Still, download, compile and send results shouldn't be to bad. This reminds me of that group that detects lightening. You buy this box, hook it to the internet and it detects lightening and sends the data back to their server. Then people can visit the website to see where the lightening is, globally at that. Thing is, getting the box was difficult. I wanted to buy the kit and assemble it myself since I've done that sort of thing before. They cost about $300 I think. Somewhere around there. I never did get a email that I was up on the list to buy one. It was pricey but at the time there was no box even close to me. There was sort of a hole in my area. Once hooked up, just keep it powered up and it requires nothing but making sure the green light is on every once in a while. I would like to have been able to do that. The data part would work even on dial-up. Data amounts were tiny. Thing about this deal, it could lead to a lot of things and benefit Gentoo. Who knows what someone may come up with. From what I've read, those little things have some get up and go to them especially for their size. Whether running email type software or something else, I'm sure any help would be accepted. Didn't someone have a guitar running Gentoo once?? I never did quite figure that one out. Why does a guitar need a computer?? :/ I suspect that there would be a few devs willing to accept the help, whether donating a Pi thingy or just getting testing from someone who has one. I can't imagine them saying no. o_O Dale :-) :-) P. S. My mattress is having issues. A couple springs are trying to escape. I put it off as long as I could. :-(
