Usenet predates the World Wide Web by more than a decade, and its transport protocol — NNTP, defined in 1986's RFC 977 — was designed in an era when "authentication" meant "you're on a trusted host that peers with my trusted host." Servers exchanged news articles freely. There were no passwords, no accounts, no rate limits. By the late 1990s, that model was collapsing. Commercial ISPs were selling Usenet access to millions of subscribers, spammers had discovered the network's open relay-like properties, and operators desperately needed a way to say "prove who you are before I let you post." RFC 4643 is the formal, standards-track answer to that need.

The problem it solves. Before 4643, NNTP authentication existed only as an informational hack — RFC 2980's AUTHINFO USER / AUTHINFO PASS commands, lifted almost verbatim from FTP. Every implementation interpreted it slightly differently. There was no negotiation, no advertisement of mechanisms, no way to plug in modern auth like Kerberos or one-time passwords, and no clear interaction with TLS. RFC 4643 cleans all of this up and binds it properly to RFC 3977 (the modern NNTP rewrite from the same year).

Key design decisions.

• Two mechanisms, one framework. The RFC defines AUTHINFO USER/PASS (the legacy username/password flow, retained for compatibility) and AUTHINFO SASL, which delegates to the Simple Authentication and Security Layer (RFC 4422). SASL is the same plumbing used by IMAP, SMTP submission, XMPP, and LDAP — so NNTP suddenly inherited PLAIN, CRAM-MD5, DIGEST-MD5, GSSAPI, EXTERNAL, and anything else SASL gained later.
• Capability advertisement. The server lists supported mechanisms in its CAPABILITIES response under an AUTHINFO line. Clients no longer have to guess or probe.
• TLS-aware. Plaintext mechanisms must be refused unless the connection is encrypted (or the server is explicitly configured to permit them). This was a notable hardening — RFC 2980 had no such requirement, and many Usenet passwords had been crossing the wire in the clear for years.
• State reset on success. After successful authentication, the server resets to an "initial" state — any selected newsgroup is forgotten — so authorization decisions apply uniformly. A small detail, but it prevents whole classes of "I authenticated after selecting a restricted group" bugs.
• Reject-on-fail, retry permitted. Failed AUTHINFO doesn't drop the connection; the client may try again with a different mechanism. This matters for clients walking a capability list from strongest to weakest.

Why it still matters. Usenet didn't die — it shrank into a quieter, paid corner of the internet dominated by binary groups and a handful of text-discussion holdouts. Every major commercial provider (Giganews, Eweka, Newshosting) authenticates with AUTHINFO as defined by 4643, almost universally over TLS on port 563 (NNTPS). If you've ever configured a newsreader in the last fifteen years, you've used this RFC. More broadly, 4643 is a clean case study in retrofitting authentication onto a protocol designed without it — a pattern that recurred for SMTP (RFC 4954), IMAP (RFC 3501), and others, all leaning on SASL to avoid reinventing the wheel. The lesson is consistent: when you bolt auth onto a legacy protocol, advertise capabilities, defer to SASL, and require TLS for anything that sends a password in cleartext.

Quirky history. The authors, Jeffrey Vinocur and Ken Murchison, were also instrumental in the broader NNTP modernization effort — RFCs 3977, 4642 (TLS for NNTP), 4643 (this one), and 4644 (streaming feeds) all shipped together in October 2006, a coordinated cleanup of a protocol that had been frozen for two decades. It's one of the more thorough "let's bring this old workhorse into the modern era" efforts the IETF has ever produced.