| 1 |
On 8/28/20 1:55 PM, james wrote: |
| 2 |
> I'm proposing, via a small corp I own, to purchase up to (3) dual |
| 3 |
> Rasp.pi 4 setups of (2) R.Pi.4 8gig ram setups and send them to the |
| 4 |
> devs WE all decide on. |
| 5 |
|
| 6 |
A few points. |
| 7 |
|
| 8 |
1) I don't think that 8 GB of RAM is required. -- My email server is |
| 9 |
a VPS with 2 GB of RAM and is running just fine. So, maybe smaller |
| 10 |
systems would work. And maybe that would mean that more of them could |
| 11 |
be acquired for the same funding. |
| 12 |
|
| 13 |
2) I don't know that a Raspberry Pi is strictly required for the |
| 14 |
testing. I think that anything that will run Gentoo can be used to |
| 15 |
prove out the software stack. -- Sure, there will /eventually/ need to |
| 16 |
be /some/ testing on Raspberry Pis. But I think that testing will be |
| 17 |
later in the game and more of a confirmation after the fact. |
| 18 |
|
| 19 |
3) I'm not sure what you mean by "dual ... setups". What are the two |
| 20 |
systems (be it Raspberry Pis or VPSs or VMs or something else) supposed |
| 21 |
to do? - Are you wanting primary and backup (as in MX) or some sort of |
| 22 |
cluster with shared file system or something else? |
| 23 |
|
| 24 |
> Let's us start compiling up the codes, keep it simple (for now) and |
| 25 |
> implement them with gentoo-users as the testers of the email services. |
| 26 |
> |
| 27 |
> These discussions should be continued to everyone's benefit. However |
| 28 |
> there are way more than (3) folks on these threads who are most capable |
| 29 |
> to do this community prototyping. |
| 30 |
|
| 31 |
I think the idea of using VPSs or VMs means that a lot more people can |
| 32 |
participate using the same funding. |
| 33 |
|
| 34 |
> If WE do not act and get hundreds of these deployed, email, as we know |
| 35 |
> it via RFCS and other standards may just disappeaar, or be relegated to |
| 36 |
> the far reaches of the Internet. What I have read, is standards based |
| 37 |
> email services, particularly by small organizations, are under extreme |
| 38 |
> pressure by large corporations to be marginalized out of existence. |
| 39 |
|
| 40 |
I think I disagree with that. |
| 41 |
|
| 42 |
Many of the big email operators are enforcing higher and higher |
| 43 |
standards. But the standards /are/ /open/ and /can/ /be/ /implemented/ |
| 44 |
/by/ /anyone/ who wants to do so. |
| 45 |
|
| 46 |
The /only/ thing that I've seen that is somewhat of a closed system that |
| 47 |
small players -- like myself -- have no real hop of is getting people |
| 48 |
like Google to trust our ARC (not DMARC) signatures. Though this is |
| 49 |
probably more a shortcoming in the ARC specification as it doesn't |
| 50 |
tackle how to get providers to trust your signature as a small operator. |
| 51 |
|
| 52 |
> So any of the folks in these treads can announce publically, or send me |
| 53 |
> private email as to your concerns. Public is best, but, I understand the |
| 54 |
> needs for private communications sometimes. So yea, I'll personally |
| 55 |
> finaces, at least 6 months of (3) projects. |
| 56 |
> I'll take all input, but will make my (funding) decision, in a focus, |
| 57 |
> quick strategy. |
| 58 |
|
| 59 |
I'm happy to participate. My preference would be to use a VPS / VM |
| 60 |
(which I can provide) and allow others to take advantage of the Pis that |
| 61 |
are on offer. |
| 62 |
|
| 63 |
|
| 64 |
|
| 65 |
|
| 66 |
-- |
| 67 |
Grant. . . . |
| 68 |
unix || die |
Archives