System Requirements Document for smtp

1. Introduction

smtp is a Gmail-powered mass mail sender. A user composes one message, supplies a consent-based recipient list, and launches a mass send that is dispatched in paced batches through the Gmail API on the user's own Gmail account. The product exists to make bulk sending through Gmail honest and observable: Google enforces sending limits and anti-spam rules, so "unlimited" sending is not possible, and smtp is built around that reality — batching, quota awareness, consent handling, and per-recipient delivery results.

The audience is people who run consent-based bulk mail through their own Gmail account: campaign senders who compose and launch sends, and Gmail account owners who connect and authorize the account, monitor quota and consent status, and keep sending inside Google's enforced limits.

The product is delivered as a first-party web application with application-owned identity (self-service enrollment and returning verification), a shared backend that owns campaigns, recipient lists, connected Gmail accounts, and per-recipient results, and a background dispatch process that paces batches through the Gmail API.

2. System Overview

2a. Product Interpretation and Delivery Boundary

smtp is a first-party web application. The application owns user identity (self-service sign-up and returning login), the connected Gmail account records and their authorization state, campaigns and their consent-based recipient lists, and the per-recipient delivery results of each mass send. The application's shared backend exposes the feature APIs and runs the paced batch dispatcher; Redis holds the dispatch queue and live batch progress; MariaDB holds durable application data.

Gmail is the delivery channel and an external provider. The user authorizes their own Gmail account through Google's OAuth consent flow, and every message is sent through the Gmail API on that account. Google owns and enforces sending limits, quota, and anti-spam rules; smtp does not bypass them and does not claim unlimited sending. Recipients are external parties who receive mail through their own mail providers; they do not use smtp.

Current scope covers the full lifecycle: public entry, enrollment and login, connecting and authorizing a Gmail account, composing a campaign with a consent-based recipient list, launching a paced batch send, and reviewing per-recipient results. Nothing beyond this lifecycle — no template libraries, no contact-CRM features, no analytics suites, no additional sending providers — is part of the current product.

2b. Source Content Inventory

Not applicable — no reference directive with content_source was supplied.

2c. Page Content and Component Coverage

Landing

• Information/state: Public entry explaining the Gmail-powered mass mail sender, its audience, and its batching/consent approach before sign-in. States: default; no loading or error states beyond static content.
• Primary actions: Go to Sign Up; go to Login.
• Supporting actions: Read the pacing/consent explanation; view the state legend.
• Domain entities: None persisted; presents the sending-state vocabulary (Queued, Paced, Delivered, Failed).
• Components:

  • Hero block

    • Oversized ink-on-paper display headline across columns 1–8, single 12px uppercase eyebrow, one tomato-accent CTA button with 4px hard offset shadow.

  • State legend panel

    • Bordered panel in the right third: four rows of 16×16 pictogram + label (Queued / Paced / Delivered / Failed) in their state colours, hard offset shadow.

  • Mailroom conveyor strip

    • Full-bleed pixel-art strip of envelopes stamped with state marks, bleeding off both edges; static arrangement under reduced motion.

  • Pictogram tile band

    • Full-width band of three pictogram tiles (envelope, hourglass, gauge) with short captions.

  • Pacing and consent section

    • Ruled, table-like section explaining Gmail quotas, batching, and consent-based recipient handling, with numbered margin labels (01 / 02 / 03) and 1px ink rules.
• States: Loading — not applicable (static). Empty — not applicable. Success — navigation to Sign Up or Login. Error — not applicable. Recovery — not applicable.

Sign Up

• Information/state: Self-service first-use enrollment form. States: default; submitting; field validation errors; duplicate-email error; success.
• Primary actions: Create an account with name, email, and password.
• Supporting actions: Navigate to Login if already enrolled.
• Domain entities: User account (name, email, password credential).
• Components:

  • Enrollment form

    • Name, email, password fields with inline validation; submit button with chunky-outline treatment.

  • Error summary

    • Inline messages for invalid fields and for an email already enrolled, with a link to Login.
• States: Loading — submit button shows in-progress state. Empty — blank form. Success — account created and the user proceeds to connect a Gmail account. Error — validation or duplicate-email message with recovery by correcting fields or going to Login. Recovery — form retains entered values except password.

Login

• Information/state: Returning verification form. States: default; submitting; invalid-credentials error; success.
• Primary actions: Sign in with email and password.
• Supporting actions: Navigate to Sign Up.
• Domain entities: User account credential.
• Components:

  • Sign-in form

    • Email and password fields; submit button.

  • Error message

    • Generic invalid-credentials message with retry.
• States: Loading — submit in progress. Empty — blank form. Success — session established and the user lands on Campaigns. Error — invalid credentials with retry. Recovery — re-enter credentials; link to Sign Up.

Gmail Accounts

• Information/state: Connected Gmail accounts with authorization state, sending/quota status, and consent status. States: loading; empty (no account connected); connected and authorized; authorization pending; authorization revoked/expired; error.
• Primary actions: Connect and authorize a Gmail account via Google's OAuth consent flow.
• Supporting actions: Re-authorize an expired or revoked account; view quota and consent status per account.
• Domain entities: Connected Gmail account (address, authorization state, quota status, consent status).
• Components:

  • Account list

    • Ruled rows with tabular numerals and a state chip per account (authorized / pending / revoked).

  • Connect action

    • Button that starts the Google OAuth consent flow and returns to this page with the result.

  • Quota and consent rail

    • Right metadata rail showing quota status and consent status for the selected account.

  • Pixel Gmail-connection badge

    • Small crisp-edge badge reflecting connection state.
• States: Loading — skeleton rows. Empty — prompt to connect the first Gmail account. Success — account listed as authorized. Error — authorization failed or revoked, with a re-authorize action. Recovery — retry the OAuth flow.

Campaigns

• Information/state: Revisitable overview of the user's mass sends with status per campaign (draft, queued, sending, completed, failed) and launch action. States: loading; empty (no campaigns); populated; launching; launch blocked (no authorized Gmail account or no consent-based recipient list); error.
• Primary actions: Launch a campaign, dispatching it in paced batches through the Gmail API.
• Supporting actions: Open New Campaign; open Campaign Results for a campaign; view live batch progress.
• Domain entities: Campaign (subject, body, recipient list, status, batch progress, connected Gmail account).
• Components:

  • Campaign table

    • Ruled rows with tabular numerals, a state chip per row, and a launch control.

  • Launch control

    • Disabled with an explanatory message when no authorized Gmail account exists or the recipient list is not consent-based.

  • Live batch counter

    • Digit-by-digit mechanical counter showing dispatched batches against total.

  • Quota and consent rail

    • Right metadata rail showing the active account's quota and consent status.
• States: Loading — skeleton rows. Empty — prompt to create the first campaign. Success — campaign status advances to queued/sending and the counter ticks. Error — launch rejected or dispatch failure surfaced per campaign with retry. Recovery — fix the blocking condition (authorize account, correct recipient list) and relaunch.

New Campaign

• Information/state: Composition form for a mass send: message subject and body, recipient list, and selection of the sending Gmail account. States: default; validating; invalid recipient entries; consent confirmation missing; saving; saved.
• Primary actions: Save the campaign and supply a consent-based recipient list.
• Supporting actions: Confirm the consent basis for recipients; select the connected Gmail account; return to Campaigns.
• Domain entities: Campaign draft; recipient entries (address, consent confirmation).
• Components:

  • Message composer

    • Subject field and body editor.

  • Recipient list input

    • Paste or enter recipient addresses; per-entry validation; count of valid recipients.

  • Consent confirmation

    • Required confirmation that recipients are handled on a consent basis per Google anti-spam rules; blocks saving until confirmed.

  • Account selector

    • Choose among authorized Gmail accounts; links to Gmail Accounts when none is authorized.
• States: Loading — account list loading. Empty — blank composer. Success — campaign saved and visible on Campaigns. Error — invalid addresses or missing consent confirmation with inline recovery. Recovery — correct entries and resubmit.

Campaign Results

• Information/state: Per-recipient delivery results of a mass send, with overall batch progress. States: loading; in progress; completed; partially failed; error.
• Primary actions: Review per-recipient outcomes (delivered, failed, throttled).
• Supporting actions: Return to Campaigns; inspect failure reasons per recipient.
• Domain entities: Per-recipient result (address, state, failure reason); campaign batch progress.
• Components:

  • Mechanical batch counter

    • Digit-by-digit counter of dispatched batches; static text under reduced motion ("batch 12 of 40 dispatched").

  • Results table

    • Ruled rows, tabular numerals, state chip per recipient (delivered / failed / throttled).

  • Failure detail

    • Reason shown per failed or throttled recipient.
• States: Loading — skeleton rows. Empty — not applicable (results exist once a send starts). Success — all recipients delivered. Error — per-recipient failures and throttling shown with reasons. Recovery — return to Campaigns to relaunch or correct.

3. Functional Requirements

FR-1 — Mass send to many recipients (explicit) As a Campaign Sender I should send one message to many recipients from the app, so that I can reach my audience in a single campaign.

• Trigger/input: a saved campaign with subject, body, and recipient list.
• Observable result: the campaign is dispatched to all valid recipients and its status advances.
• Access: authenticated.
• Failure/recovery: invalid or empty recipient list blocks launch with an explanatory message; the sender corrects the list and relaunches.
• Continuation: the campaign remains visible on Campaigns with its status.

FR-2 — Gmail-powered sending (explicit) As a Campaign Sender I should have my mass send delivered through my own Gmail account via the Gmail API, so that mail comes from my real address.

• Trigger/input: a launched campaign bound to an authorized Gmail account.
• Observable result: each message is submitted through the Gmail API on that account.
• Access: authenticated; requires an authorized Gmail account.
• Failure/recovery: a missing or revoked authorization blocks launch and directs the sender to Gmail Accounts.
• Continuation: after re-authorization the campaign can be launched.

FR-3 — Connect and authorize a Gmail account (explicit) As a Gmail Account Owner I should connect and authorize my Gmail account for sending, so that the app can send on my behalf.

• Trigger/input: the Connect action on Gmail Accounts.
• Observable result: Google's OAuth consent flow completes and the account is listed as authorized.
• Access: authenticated.
• Failure/recovery: a declined or failed authorization leaves the account unconnected with a retry action.
• Continuation: the authorized account becomes selectable in New Campaign.

FR-4 — Compose a message and supply a recipient list (explicit) As a Campaign Sender I should compose a message and supply a recipient list for a mass send, so that the campaign is ready to launch.

• Trigger/input: subject, body, recipient entries, and account selection on New Campaign.
• Observable result: the campaign is saved with its recipient list and appears on Campaigns.
• Access: authenticated.
• Failure/recovery: invalid addresses or a missing consent confirmation block saving with inline messages; the sender corrects and resubmits.
• Continuation: the saved campaign can be launched from Campaigns.

FR-5 — Batched, paced sending within Gmail limits (explicit) As a Campaign Sender I should have sending batched and paced to respect Gmail API quotas and Google's sending limits, so that my account is not blocked.

• Trigger/input: a launched campaign.
• Observable result: recipients are dispatched in batches at a paced rate; batch progress is visible.
• Access: authenticated.
• Failure/recovery: when Google throttles or rejects a batch, the affected recipients are marked throttled/failed with reasons and the send continues within limits.
• Continuation: remaining batches proceed; results are available on Campaign Results.

FR-6 — Consent-based recipient handling (explicit) As a Campaign Sender I should handle recipients on a consent basis to comply with Google anti-spam rules, so that my sending stays compliant.

• Trigger/input: the consent confirmation on New Campaign.
• Observable result: a campaign cannot be saved or launched without confirmed consent basis.
• Access: authenticated.
• Failure/recovery: missing confirmation blocks saving with an explanatory message.
• Continuation: once confirmed, the campaign proceeds normally.

FR-7 — Per-recipient delivery outcomes (explicit) As a Campaign Sender I should see the outcome of a mass send including per-recipient delivery results, so that I know who received the message.

• Trigger/input: opening Campaign Results for a campaign.
• Observable result: each recipient is listed with delivered, failed, or throttled state and failure reasons where applicable.
• Access: authenticated.
• Failure/recovery: a results-loading error offers retry.
• Continuation: the sender returns to Campaigns to relaunch or correct.

FR-8 — Self-service enrollment (required_inference) As a Campaign Sender I should enroll myself before first use, so that my campaigns and connected accounts are privately mine.

• Trigger/input: the Sign Up form.
• Observable result: an account is created and the user proceeds to connect a Gmail account.
• Access: anonymous entry.
• Failure/recovery: validation or duplicate-email errors with correction or a link to Login.
• Continuation: the user signs in and continues.

FR-9 — Returning verification (required_inference) As a Campaign Sender I should verify my identity on return, so that I can access my campaigns and connected Gmail accounts.

• Trigger/input: the Login form.
• Observable result: a session is established and the user lands on Campaigns.
• Access: anonymous entry.
• Failure/recovery: invalid credentials show a retry message.
• Continuation: the user resumes their campaigns.

FR-10 — Gmail authorization prerequisite (required_inference) As a Gmail Account Owner I should authorize a Gmail account before any mass send, so that sending has a valid channel.

• Trigger/input: launch attempt without an authorized account.
• Observable result: launch is blocked with a message directing to Gmail Accounts.
• Access: authenticated.
• Failure/recovery: the owner authorizes an account and returns to launch.
• Continuation: the campaign launches.

FR-11 — Consent-based recipient list prerequisite (required_inference) As a Campaign Sender I should confirm a consent-based recipient list before launching a send, so that no non-consensual send is dispatched.

• Trigger/input: launch attempt on a campaign without confirmed consent.
• Observable result: launch is blocked with an explanatory message.
• Access: authenticated.
• Failure/recovery: the sender confirms consent on New Campaign and relaunches.
• Continuation: the campaign launches.

4. User Personas

Campaign Sender

• Product context: Runs consent-based bulk mail through their own Gmail account and needs to trust pacing, quota, and per-recipient outcomes.
• Primary goal: Compose a message, supply a recipient list, and launch a mass send that is dispatched through Gmail with per-recipient results visible.
• Distinct responsibilities: Composing campaigns, supplying and validating recipient lists, confirming the consent basis, selecting the sending account, launching sends, and reviewing per-recipient results.
• Inputs/decisions: Subject and body; recipient addresses; consent confirmation; which authorized Gmail account to send from; whether to relaunch after failures.
• Interactions: Depends on the Gmail Account Owner's authorized account as the sending channel; receives delivery outcomes from the paced dispatcher.
• Observable success: The batch is dispatched through Gmail within limits and every recipient's outcome is visible.

Gmail Account Owner

• Product context: Owns the Gmail account used as the delivery channel and must keep it authorized and within Google's enforced limits.
• Primary goal: A connected, authorized account that keeps sending within Google's limits without being blocked.
• Distinct responsibilities: Connecting and authorizing the Gmail account via Google's OAuth consent flow, re-authorizing when revoked or expired, and monitoring quota and consent status.
• Inputs/decisions: Whether to grant authorization; whether to re-authorize after revocation; reading quota and consent status.
• Interactions: Provides the sending channel the Campaign Sender launches campaigns through; sees quota and consent status that constrain sending.
• Observable success: The account remains authorized and sending proceeds within limits without being blocked.

5. Core User Flows

Flow A — First-time enrollment and Gmail connection (Campaign Sender / Gmail Account Owner)

1. The visitor opens Landing and reads the batching and consent explanation.
2. The visitor selects the CTA and lands on Sign Up.
3. The visitor enters name, email, and password and submits; on validation or duplicate-email error, they correct the fields or follow the link to Login.
4. On success, the user lands on Gmail Accounts with an empty state prompting connection.
5. The user selects Connect; Google's OAuth consent flow opens.
6. The user grants authorization; on decline or failure, the account remains unconnected with a retry action.
7. On success, the account is listed as authorized with quota and consent status visible.
8. Next step: the user proceeds to Campaigns.

Flow B — Returning login (Campaign Sender)

1. The user opens Login.
2. The user enters email and password and submits; invalid credentials show a retry message.
3. On success, a session is established and the user lands on Campaigns with their campaigns listed.

Flow C — Compose and save a campaign (Campaign Sender)

1. From Campaigns, the user opens New Campaign.
2. The user enters subject and body in the composer.
3. The user supplies recipient addresses; invalid entries are flagged and the valid count updates.
4. The user selects an authorized Gmail account; if none exists, the account selector links to Gmail Accounts.
5. The user confirms the consent basis; without confirmation, saving is blocked with an explanatory message.
6. The user saves; the campaign appears on Campaigns as a draft.

Flow D — Launch a paced mass send (Campaign Sender)

1. On Campaigns, the user selects Launch on a saved campaign.
2. If no authorized Gmail account exists or consent is unconfirmed, launch is blocked with an explanatory message; the user resolves the condition and relaunches.
3. On launch, the campaign status advances to queued/sending and the live batch counter begins ticking digit-by-digit.
4. The dispatcher submits batches through the Gmail API at a paced rate within Google's limits.
5. When Google throttles or rejects a batch, affected recipients are marked throttled/failed with reasons and remaining batches continue.
6. The user opens Campaign Results to review outcomes.

Flow E — Review per-recipient results (Campaign Sender)

1. From Campaigns, the user opens Campaign Results for a campaign.
2. The mechanical batch counter shows dispatched batches against total (static text under reduced motion).
3. The results table lists each recipient with delivered, failed, or throttled state and failure reasons.
4. On a results-loading error, the user retries.
5. The user returns to Campaigns to relaunch or correct as needed.

Flow F — Monitor and re-authorize the Gmail account (Gmail Account Owner)

1. The owner opens Gmail Accounts.
2. The owner reviews quota and consent status per account.
3. If an account shows revoked or expired authorization, the owner selects Re-authorize and completes Google's consent flow.
4. On success, the account returns to authorized and becomes selectable for sending.

6. Visuals Colors and Theme

Muse: Susan Kare. Headline: "Charming clarity: SMTP as a mailroom of pixel-perfect symbols."

Colour tokens (light mode):

• Background (warm paper): #F2EDE3 — ~70% of every screen.
• Surface (cards/panels): #FFFDF7 with 2px ink borders and hard 4px offset shadow.
• Text/ink: #1B1A17 — all type and icon strokes.
• Primary: #1B1A17.
• Accent (single hot signal — primary CTA, live batch counter, focus rings): #E4572E.
• Muted (metadata, secondary labels): #6E675C.
• State coding only: queued envelope teal #2F8F83; sending/paced mustard #E8B23A; throttled/failed tomato #E4572E; delivered leaf #4E9A51.
• No gradients; every surface flat with a visible edge.

Typography:

• Headings: Space Grotesk 700, tight -0.02em tracking, sentence case with hard breaks; small-caps uppercase micro-labels at 11–12px with 0.14em tracking.
• Body: Atkinson Hyperlegible.
• Scale (1.25 modular, 4-pt rhythm): display clamp(40px, 9vw, 104px); h1 clamp(32px, 5vw, 56px); h2 28px; h3 20px; body 17px / 1.6 leading; label 12px uppercase; mono-data 15px tabular.
• Tabular numerals everywhere counts appear; no italics, no faux weights; reading measure capped at 62ch.

Shape language: 2px ink strokes; 4px hard offset shadows (no blur); 8px radii on buttons and inputs; 12px on panels. Icons drawn on a 16×16 grid as inline SVG with crispEdges (envelope, paper plane, hourglass, gauge, checkmark, warning triangle), each with a single flat state-palette fill. Dividers are 1px ink rules; section markers are small square chips, never pills.

Layout: Strict 12-column grid with a visible 1px ink baseline rule under each section header and numbered margin labels (01 / 02 / 03) in the left gutter. App pages use a fixed left rail of icon+label nav, a content column, and a right metadata rail for quota and consent status. Tables are real ruled tables with aligned tabular numerals and a state chip per row.

Motion: Restrained and frame-based — state changes snap in 80ms steps, the live batch counter ticks digit-by-digit, a queued envelope icon hops one pixel row per dispatched batch, section headers reveal with a 120ms opacity step, hover swaps icon fill between ink and accent instantly. Under prefers-reduced-motion, hops and ticks become static state text.

Imagery: No photography, no stock people. Custom 16×16 pictogram set, a pixel-art mailroom conveyor strip on the Landing hero, schematic diagrams of the Gmail API batching flow in 2px ink lines, and a small pixel Gmail-connection badge. All flat vector, crisp-edged, legible at 16px.

Avoid: Gradient-blob heroes; glassmorphism or blurred shadows; grids of identical hover-lift cards; blue–indigo primaries or accents (#0057FF, #2563EB, #6366F1 family); Inter, Roboto, Arial, Helvetica, system-ui, or Poppins; photography of people or 3D renders; pill buttons or 24px+ radii; any claim of "unlimited" sending; bounce or spring easing.

7. Signature Design Concept

The Landing first screen is not a centred SaaS hero. Left two-thirds carries an ink-on-paper display headline in Space Grotesk 700 at clamp(40px, 9vw, 104px), broken across three hard lines — "Send in batches." / "Stay inside the limit." / "See every envelope." — with a single 12px uppercase eyebrow above it and one tomato-accent CTA button with a 4px hard shadow pinned directly beneath the last line. The right third holds a bordered state legend panel: four rows of pictogram + label (Queued / Paced / Delivered / Failed) in their state colours on the paper ground with a hard offset shadow. Across the bottom, a full-bleed pixel-art conveyor strip of envelopes stamped with state marks bleeds off both edges. No gradient, no blob, no centred stack. All readable text and controls stay whole inside the viewport and their containers at 375px, 768px, and 1280px; the conveyor strip may bleed as decoration.

8. Interaction Model & Motion Direction

Interaction Model: Static Motion Tempo: restrained Hero Dimensionality: flat

Landing Hero Motion Brief

• Focal subject: The pixel-art mailroom conveyor strip of envelopes stamped Queued → Paced → Delivered → Failed, running full-bleed off both viewport edges.
• Input → transformation → outcome thesis: As a send progresses, each envelope advances one pixel row per dispatched batch and receives its state stamp — the same state vocabulary the app uses on Campaigns and Campaign Results.
• Motion vocabulary: Frame-based 80ms snaps; digit-by-digit mechanical counter ticks; 120ms opacity step for section headers; instant ink\xe2\x86\x94accent icon fill swap on hover; no easing theatrics, no bounce or spring.
• Composed first frame: Headline block left across columns 1–8, state legend panel right, conveyor strip across the bottom with envelopes at mixed states, numbered margin labels and 1px ink rules visible.
• Reduced-motion state: All hops and ticks become static state text (for example "batch 12 of 40 dispatched"); the conveyor strip becomes a static arrangement that wraps or scrolls so every envelope is fully readable.

9. Non-Functional Requirements

• Google-enforced limits (explicit): Sending limits and anti-spam rules are enforced by Google; "unlimited" sending is not possible. The system must batch through the Gmail API with proper quotas and consent, and must never present unlimited-sending claims.
• Paced dispatch (explicit): Sending must be batched and paced to respect Gmail API quotas and Google's sending limits; throttled batches must not abort the whole send.
• Consent compliance (explicit): Recipients must be handled on a consent basis to comply with Google anti-spam rules; a campaign cannot be saved or launched without confirmed consent.
• Durable state (required_inference): Campaigns, recipient lists, connected Gmail accounts, and per-recipient results must persist across sessions in MariaDB.
• Queue and live progress (required_inference): The dispatch queue and live batch progress must be held in Redis so progress survives page reloads and the dispatcher can resume.
• Credential safety (required_inference): Gmail authorization tokens must be stored securely and never exposed in client responses or logs.
• Accessibility (required_inference): Readable text and controls stay whole at 375px, 768px, and 1280px; prefers-reduced-motion yields a usable static arrangement.

10. Tech Stack

• Frontend: React application UI.
• Backend: Shared FastAPI process for application APIs and domain modules, including the paced batch dispatcher.
• Database: MariaDB for application-owned persistent data (users, connected Gmail accounts, campaigns, recipient lists, per-recipient results).
• Cache/queue: Redis for the dispatch queue and live batch progress.
• External provider: Gmail API via Google OAuth for authorization and sending.
• Deployment: docker-compose with the backend, database, frontend, and redis services.

11. Assumptions and Constraints

• A-1 (required_inference): Users enroll with name, email, and password; no third-party identity provider is used for app login.
• A-2 (required_inference): Each user may connect one or more Gmail accounts; a campaign is bound to one authorized account at launch.
• A-3 (explicit): "Unlimited" sending is not possible; the product is built around Gmail quotas and pacing.
• A-4 (required_inference): Recipients are external parties who do not use smtp; their delivery outcomes are observed through the Gmail API.
• A-5 (required_inference): The consent confirmation is a user attestation recorded on the campaign; the app does not independently verify recipient consent.
• A-6 (required_inference): Redis holds the dispatch queue and live progress; MariaDB holds durable records.

12. Glossary

• Campaign: One mass send — a message (subject, body), a consent-based recipient list, and a bound Gmail account.
• Batch: A subset of recipients dispatched together through the Gmail API within quota.
• Pacing: The rate at which batches are dispatched to respect Gmail API quotas and Google's sending limits.
• Consent basis: The user's confirmation that recipients have consented, per Google anti-spam rules.
• Gmail Account Owner: The persona who connects and authorizes the Gmail account used as the sending channel.
• Campaign Sender: The persona who composes, launches, and reviews mass sends.
• Per-recipient result: The delivery outcome (delivered, failed, throttled) recorded for each recipient.
• State legend: The Queued / Paced / Delivered / Failed vocabulary shown on Landing and used as state chips throughout.