Closes: team#41180

Those have both been implemented in their fullest.

See team#41083 and team#29974.

Closes: team#41079

The rationale here is that the proposal is not really relevant once
the original naming convention is fixed. This will be enacted on
monday unless there are any objections.

I have actually clicked the button after checking with hiro. She's
okay with the switch, and the 48h grace period is sufficient.

Closes: team#40892

... that deprecates TPA-RFC-13 as well...

Closes: team#40924

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: team#40798

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: team#40564

isa confirmed by email the budget was approved by the board, see
Message-ID: <CA+Brs21bu_1S99n=FtC3j9JnDjzbpMnau4kz-bt-bXGPK3LEzQ@mail.gmail.com>

Closes: tpo/tpa/team#40929

See tpo/web/lego#27

This RFC ended up being a bad idea, not well thought out, and hard to
implement.

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.