Soft bounce

Un soft bounce è un fallimento transitorio di consegna email. Il server di posta ricevente ha rifiutato il messaggio per ora, ma la causa è qualcosa che può risolversi da sola — la mailbox del destinatario è oltre quota, il server ricevente è temporaneamente down o sta facendo rate limiting, il messaggio è stato greylistato al primo tentativo, oppure c'è un singhiozzo nell'handshake TLS. Ci si aspetta che il mittente ritenti. Da confrontare con un hard bounce — un rifiuto permanente che non andrebbe mai ritentato.

Lo stesso enum BounceType che pilota la gestione degli hard bounce dispone di un secondo case:

enum BounceType: string
{
    case HARD = 'hard';
    case SOFT = 'soft';
}

Un evento webhook SOFT dal vendor di invio (SES, Mailgun, SparkPost, ecc.) viene registrato in BounceLog esattamente come un hard bounce, ma il listener RecordBounce non blacklist automaticamente l'iscritto alla prima occorrenza. L'indirizzo rimane attivo e viene incluso nelle campagne successive. Se i soft bounce continuano ad accumularsi lungo una sequenza configurabile, l'operatore può promuovere l'indirizzo a blacklist tramite le policy del bounce handler — ma un singolo soft bounce viene trattato come rumore.

Confondere soft e hard bounce è l'errore più comune di bounce handling sulle piattaforme di piccola taglia. Blacklistare automaticamente su un soft bounce assottiglia la lista ogni volta che il server di un destinatario ha un singhiozzo — un singolo outage di Gmail può far perdere migliaia di iscritti legittimi. Trattare gli hard bounce come soft (ritentando comunque) brucia la reputazione del mittente. AcelleMail impone questa separazione a livello di data model (BounceType::HARD vs BounceType::SOFT) così che i listener non possano accidentalmente trattare l'uno come l'altro.

• Risposte SMTP 4xx — l'intera classe 4xx significa "fallimento transitorio, ritentare".
• Mailbox piena — il destinatario ha raggiunto il cap di storage; di solito si libera nell'arco di giorni.
• Greylisting — tecnica anti-spam che differisce un mittente alla prima occorrenza; i retry legittimi vanno a buon fine in pochi minuti.
• Rate limiting — il receiver sta throttando il traffico da questo IP/dominio; bisogna fare back-off e ritentare.
• Problemi TLS / di connessione — problema transitorio di rete o certificato sul lato ricevente.

Il playbook operativo completo — quando i soft bounce dovrebbero escalare a blacklist, qual è una lunghezza di sequenza sensata, e come leggere le ragioni raw del vendor — vive in deliverability §8.