|Page version||Author||Changes||Last updated|
reject TPA-RFC-31 (tpo/tpa/team#40798) I currently don't see any service provider that can serve all of our email needs at once, which is what I was hoping for in this proposal. the emergency part of TPA-RFC-44 (#40981) was adopted, but the longer part is postponed until we take into account the other requirements that popped up during the evaluation. those requirements might or might not require us to outsource email mailboxes, but given that: * we have more mail services to self-host than I was expecting (schleuder, mailman, possibly CiviCRM), and... * we're in the middle of the year end campaign and want to close project rather than start them ... I am rejecting this proposal in favor of a new RFC that will discuss, yes, again, a redesign of our mail infrastructure, taking into account the schleuder and mailman hosting, 24/7 mailboxes, mobile support, and the massive requirement of CiviCRM mass mailings. Closes: tpo/tpa/team#40798
reject TPA-RFC-41: Schleuder retirement It seems now clear to me there is just no other way of cleanly satisfying the community council's requirements than keeping a functional Schleuder around. Their requirement is, basically, that the cleartext from communications never be recorded long term, only ciphertext is allowed, while still allowing a low barrier for entry (ie. accepting cleartext email submissions, but re-encrypting it). In all the alternatives considered: 1. Schleuder 2. Mailman 3 and OpenPGP 3. Role key and home-made Schleuder 4. Shared OpenPGP alias 5. Signal Of those, only the first three satisfy *both* requirements. The shared OpenPGP alias will *not* encrypt incoming mail if isn't already encrypted, and Signal will *not* allow cleartext communications to come in. Since Mailman's OpenPGP plugin is still immature and not fully functional, the only remaining options are maintaining Schleuder or writing our own. I do not think the current limitations of Schleuder warrant us embarking in such an endeavor, so let's fix Schleuder. Closes: tpo/tpa/team#40564
adopt and obsolete TPA-RFC-40; replaced with TPA-RFC-43 After discussing this with @isabela, it became apparent I misunderstood the budget approval process and that we need an actual, accurate breakdown of all costs before going forward. So let's turn this into a "broad budget approval". isa agrees with the general plan (ie. to add servers), so this is basically approved (so standard). But because we need to approve the specifics, it's obsolete because we're working on that in TPA-RFC-43 now. Marking this as "standard" would be quite confusing, and we'd need to change its status as soon as TPA-RFC-43 is proposed anyways, so let's just move on already.