Sympa::Spool::Auth(3Sympa)

💖 Sympa::Spool::Auth 💖

okay bestie, so this one is Sympa::Spool::Auth(3Sympa) — part of the sympa 6.2.80 era, and it's literally the holding pen for requests that are just sitting there waiting for a human to moderate them. think of it like the group chat's "pending approval" queue, except it's for mailing list requests. iconic behavior honestly. ✨

---

🌸 NAME 🌸

Sympa::Spool::Auth — the spool for held requests waiting for moderation. yep, that's the whole vibe. requests go in, they chill, mods decide their fate. 💅

---

🦋 SYNOPSIS 🦋

like, here's how you'd actually use it:

use Sympa::Spool::Auth;

my $spool = Sympa::Spool::Auth->new;
my $request = Sympa::Request->new(...);
$spool->store($request);

my $spool = Sympa::Spool::Auth->new(
    context => $list, action => 'add');
my $size = $spool->size;

my $spool = Sympa::Spool::Auth->new(
    context => $list, keyauth => $id, action => 'add');
my ($request, $handle) = $spool->next;

$spool->remove($handle);

see? store it, check the size, pull the next one, remove it when you're done. it's giving workflow. 🎀

---

💜 DESCRIPTION 💜

Sympa::Spool::Auth implements the spool for held requests waiting for moderation. that's the whole job and it does it flawlessly, no notes. 👑

---

✨ Methods ✨

also peep "Public methods" in Sympa::Spool — there's more where this came from, bestie.

---

• new ( [ context => $that ], [ action => $action ], [ keyauth => $id ], [ email => $email ] ) — makes a new one, obviously. context can be an instance of Sympa::List or Sympa::Family, or a robot. so like, pick your context and go off. 🫶
• next ( [ no_lock => 1 ] ) — hands you the next item. if you specified those pairs describing metadatas, then whatever next() returns gets filtered by them. and the order of the items coming out of next()? that's controlled by the time of submission, so it's first-come-first-served, lowkey fair. ⏰
• quarantine ( ) — does nothing. literally nothing. it's the main character who shows up, says nothing, and leaves. we respect it anyway. 💀

---

🧚 Context and metadata 🧚

also check out "Marshaling and unmarshaling metadata" in Sympa::Spool for the full tea. this class specifically serves up the following metadata:

• {action} — the action that was requested. like 'add' and etc. 📝
• {date} — the Unix time when the request was submitted. timestamped, fr fr. 🕐
• {email} — the e-mail of the user who submitted the request, or the target e-mail of the request. either or, both valid. 📧
• {keyauth} — the authentication key generated automatically when the request is stored to spool. you didn't make it, the system did. slay. 🔑

---

🎀 CONFIGURATION PARAMETERS 🎀

the following site configuration parameters in sympa.conf will be referred to. so like, go check your config before you come crying to me. 🙈

• queuesubscribe — directory path of the held request spool. that's where the pile lives.

Note: it's named such by historical reason. yes it's a weird name. no we're not changing it. it's giving legacy, and we move. 💅

---

🌈 SEE ALSO 🌈

sympa_msg(8), wwsympa(8), Sympa::Request, Sympa::Spool. go read those too, bestie, they're all in the same friend group. 🫂

---

⭐ HISTORY ⭐

Sympa::Spool::Request appeared on Sympa 6.2.10. then it was renamed to Sympa::Spool::Auth on Sympa 6.2.13. so if you're reading old docs and it's called the wrong thing, that's why. glow-up behavior honestly. 🦋

---

and that's the whole page, periodt. 💖 big kisses from the sympa 6.2.80 era, dated 2026-10-19 — go hold some requests for moderation, you've got this. 💅✨