The Internet’s Forgotten Protocols: Why SMTP, FTP, and Telnet Are Still Insecure (and What to Use Instead)

If the internet had a junk drawer, it would be full of old protocols we still use because “they just work.” SMTP delivers email. FTP moves files. Telnet lets you manage systems. They’re simple, familiar—and dangerously outdated.

Here’s the problem: these protocols were never designed for hostile networks. No encryption. Weak or no authentication. Zero integrity protections. Yet, decades later, they still run in countless companies, homes, and cloud environments. Attackers know it. They hunt for them every day.

In this guide, you’ll learn what SMTP, FTP, and Telnet do, why they remain insecure by design, how attackers abuse them, and the exact steps to replace or harden them. You’ll also see safer alternatives and practical migration tips that keep your business moving without exposing your data.

Let’s open that drawer—and close some doors.

What These Legacy Protocols Do (and Where They Still Linger)

Before we talk risk, let’s align on what each protocol does.

SMTP (Simple Mail Transfer Protocol)

Purpose: Send email between servers.
How it works: MTAs (mail transfer agents) hand off messages server-to-server.
Default port: 25 (also 587/465 for submission).
Problem: SMTP was created without encryption or strong sender authentication. It assumes a friendly network. It rarely gets one.
Reference: RFC 5321.

FTP (File Transfer Protocol)

Purpose: Transfer files between clients and servers.
Default ports: 21 (control), random high ports (data).
Features: Anonymous access, directory listing, resume.
Problem: Credentials and data are sent in cleartext. Active/passive modes complicate firewalls. The protocol leaks filesystem details.
Reference: RFC 959, FTP Security Considerations (RFC 2577).

Telnet

Purpose: Remote terminal access to devices and servers.
Default port: 23.
Problem: Sends everything in plain text, including usernames and passwords. Offers no integrity or confidentiality.
Reference: RFC 854.

These aren’t the only culprits. Other “forgotten” protocols include POP3 and IMAP without TLS, SNMPv1/v2c, TFTP, rlogin/rsh, SMBv1, LDAP without signing, and even plain HTTP for admin interfaces. They crop up in: – Legacy apps that “haven’t been touched in years” – Network devices and OT/ICS gear – Build pipelines and batch jobs – IoT cameras, DVRs, printers, and routers – Cloud instances spun up from old AMIs or images

If you’ve ever said “we’ll replace that later,” you probably still have some of these running.

Why SMTP, FTP, and Telnet Are Insecure by Design

The short answer: they were designed for a friendly internet. The long answer explains how attackers win.

SMTP: Opportunistic Encryption with Weak Guarantees

SMTP originally had no encryption at all. STARTTLS (an upgrade mechanism) improved things, but it’s still “opportunistic” in many cases—servers try TLS if both sides agree. That sounds fine, but: – Downgrade attacks can force a fall back to cleartext if security isn’t enforced. – TLS doesn’t authenticate the sender’s identity by itself. – Email can be relayed through multiple servers; you inherit the weakest link. – End-to-end encryption is not built in. Your message can be read on servers along the path unless you use PGP/S/MIME.

Why that matters: sensitive emails can be intercepted, altered, or spoofed. Tools like SPF, DKIM, and DMARC help validate sending domains and reduce spoofing but don’t encrypt content. See: SPF (RFC 7208), DKIM (RFC 6376), DMARC.

Helpful resources: – SMTP over TLS (RFC 3207) – MTA-STS and DANE for SMTP – Google’s email encryption transparency

FTP: Credentials and Data in the Clear

Classic FTP sends your username and password in plain text. So do many commands, directory listings, and files. Anyone on the path—on the same Wi‑Fi, in your ISP, or positioned as a man-in-the-middle—can read or alter your transfer.

Other issues: – Anonymous FTP often exposes sensitive directories by accident. – FTP bounce and passive/active mode quirks create firewall holes. – Misconfigurations leak internal paths and OS details.

FTP is not salvageable on the open internet without encapsulation or encryption. Use SFTP or FTPS instead (we’ll cover the difference).

Telnet: A Free Pass for Credential Theft

Telnet offers terminal access with zero confidentiality. Packet captures reveal everything. Attackers love Telnet because: – IoT devices often ship with Telnet enabled and default creds. – Static passwords are common. – It’s easy to brute force and pivot from.

The Mirai botnet famously abused Telnet on internet-connected devices to assemble massive DDoS networks. See: CISA on Mirai and DDoS botnets.

Real-World Risks of Leaving Legacy Protocols Online

Still tempted to leave them for “one more quarter”? Here’s what you’re risking.

Credential theft at scale: Cleartext protocols hand over usernames and passwords to anyone listening. Attackers then reuse them across VPNs, SaaS, and cloud consoles (credential stuffing).
Data exposure: Files transferred via FTP and content in transit via SMTP can be read or altered.
Ransomware and lateral movement: A single exposed service can give attackers a foothold. From there, they pivot via file shares, remote management, and trust relationships.
Botnets and device takeovers: Telnet on IoT or network gear becomes an instant recruiting station.
Compliance violations: Many frameworks require encryption in transit (TLS). Running cleartext can trigger audit findings and penalties. See CIS Controls v8 and NIST SP 800-52r2 for TLS guidance.
Supply chain risk: Build servers using FTP/Telnet expose credentials and artifacts that attackers can swap or poison.

Even Microsoft urges disabling SMBv1 due to its exploitability in widespread attacks like WannaCry/NotPetya. Guidance: Disable SMBv1.

How Attackers Exploit These Weaknesses Today

Attackers don’t need zero-days when old doors are still open. Their playbook is simple and effective.

Discovery at internet scale – Constant scans for ports 21 (FTP), 23 (Telnet), 25 (SMTP), and others. – Search engines like Shodan index exposed services for easy lookup.
Default creds and brute force – Many Telnet and FTP services accept factory usernames/passwords. – Common credentials are tried first, then fast brute force from distributed IPs.
Passive sniffing and MITM – On local networks or compromised routers, cleartext Telnet/FTP/SMTP traffic is captured. – Attackers harvest credentials and session data with trivial effort.
Protocol downgrades and opportunistic TLS abuse – For SMTP, they intercept and remove STARTTLS capabilities (a downgrade attack). – If you don’t enforce TLS and validate certificates, email falls back to cleartext.
Abuse of weak configurations – Anonymous FTP with write permissions becomes a malware drop site. – Directory traversal and misconfigured root paths expose sensitive files. – Open relays or lax SMTP policies enable spam and phishing.
Pivot and persistence – Stolen creds open VPNs, RDP, and SaaS. – Attackers plant backdoors, escalate privileges, and exfiltrate data slowly to avoid detection.

The kicker: many attacks show up weeks or months later in logs you never looked at. Keep an eye on CISA’s Known Exploited Vulnerabilities to understand what’s getting used in the wild.

Safer Alternatives and How to Migrate Without Breaking Everything

You can move off these protocols without grinding operations to a halt. Here’s how.

Replace Telnet with SSH (Secure Shell)

Use: SSH for remote admin and automation.
Why: Encrypted channel, strong authentication, integrity protection.
Best practices:
Disable Telnet everywhere.
Enforce SSHv2, modern ciphers, and MACs. See RFC 4251/4253.
Prefer key-based auth with passphrases and agent forwarding. Disable password auth where possible.
Use bastion hosts or a privileged access gateway.

Replace FTP with SFTP, FTPS, or HTTPS

SFTP (SSH File Transfer Protocol)
Runs over SSH (port 22), uses the same keys and controls.
Simpler firewalling, widely supported by clients and automation.
FTPS (FTP over TLS)
Uses TLS to encrypt classic FTP. Two flavors:
- Implicit TLS (usually port 990)
- Explicit TLS (starts on 21, then upgrades)
Requires careful firewall configuration for data channels.
HTTPS for file exchange
Use pre-signed URLs (e.g., S3), web portals, or APIs for uploads/downloads.
Great for partner exchanges without managing client software.

Which should you choose? – For admin-to-server and automation: SFTP. – For legacy appliances that only speak FTP variants: FTPS with TLS-only, disable cleartext. – For B2B file exchange: Managed File Transfer (MFT) platforms over HTTPS or SFTP. – Bonus: Audit and rotate credentials. Prefer short-lived tokens over static passwords and secrets.

Make SMTP Safer (And Know Its Limits)

Enforce TLS in transit:
Require TLS for server-to-server connections using MTA-STS or DANE.
Validate certificates; pin policies; monitor failures.
Lock down sender identity:
Publish SPF records, sign with DKIM, and enforce DMARC to reduce spoofing (DMARC.org).
Protect sensitive content:
Use end-to-end encryption (PGP or S/MIME RFC 8551) where practical.
For business workflows, consider secure portals or encrypted attachments with key exchange outside email.
Restrict exposure:
Don’t run open relays.
Separate submission (587/465) from relay (25) with strict auth and rate limits.
Monitor encryption rates—aim for near 100% TLS to major domains. Google’s report helps benchmark.

Upgrade Other Common Legacy Services

POP3/IMAP: Require TLS-only (POP3S 995, IMAPS 993). Disable cleartext auth.
LDAP: Require TLS and signing. See Microsoft’s guidance on LDAP signing and channel binding.
SNMP: Move to v3 with authPriv. Disable v1/v2c community strings.
SMB: Disable SMBv1. Require SMBv3 with encryption where possible (Microsoft guidance).
NFS: Prefer NFSv4 with Kerberos (AUTH_GSS). Avoid NFSv3 over untrusted networks.
TFTP: Eliminate on routed networks; use secure alternatives or isolate tightly when unavoidable.

A Practical, No-Drama Plan to Reduce Exposure

Here’s a step-by-step plan you can run this quarter. Start small, iterate fast.

Discover what’s actually running – Inventory with your EDR, vulnerability scanner, and network scans. – Look for ports: 21, 23, 25, 110, 143, 389, 445 (and variants). – Check cloud security groups and firewall rules. Don’t forget containers and OT/ICS segments.
Triage by blast radius – Internet-exposed first. – Then cross-segment gateways and high-privilege zones. – Finally, internal-only services with compensating controls.
Apply controls in layers – Quick wins: Block at the edge, disable services on hosts, enforce TLS-only. – Replace Telnet with SSH and FTP with SFTP/FTPS. – For SMTP, enforce MTA-STS/DANE, SPF/DKIM/DMARC, and TLS-only where possible.
Isolate what you can’t replace yet – Put legacy boxes behind VPNs or Zero Trust access. – Segment with ACLs and firewalls. Restrict to specific IPs. – Require MFA on any remote access path.
Harden authentication – Remove default creds. Enforce strong passwords. Prefer keys/tokens. – Centralize accounts with least privilege and short-lived access.
Monitor and alert – Log connection attempts and failures. Alert on cleartext protocols. – Track TLS rates for email and file transfers. – Watch CISA’s KEV Catalog for active threats.
Set a decommission date – Put it on a roadmap. Assign an owner. Track in your risk register. – Replace with supported alternatives. Don’t let “temporary” become “forever.”
Communicate with empathy – Explain why changes matter for the business (availability, trust, compliance). – Provide training and simple how-tos for new tools.

Pro tip: Adopt a control framework like the CIS Controls v8 and map each step to it. This turns security work into measurable progress.

Myths vs. Reality: Clearing Up Common Misconceptions

“We turned on TLS, so email is secure now.”
Reality: SMTP TLS protects server-to-server transit—sometimes. It’s not end-to-end, and it’s only as strong as policy enforcement (MTA-STS/DANE). Content can still be read at endpoints and servers along the route.
“FTPS and SFTP are the same.”
Reality: They’re different protocols. SFTP runs over SSH on port 22. FTPS is FTP wrapped in TLS and can be harder to firewall. Pick based on compatibility and manageability.
“It’s internal, so Telnet is fine.”
Reality: Internal networks aren’t trusted. Attackers love lateral movement. A single compromised laptop can sniff Telnet and steal creds. Use SSH, even inside.
“A VPN makes legacy protocols safe.”
Reality: VPNs reduce exposure but don’t fix weak authentication, outdated software, or abuse from insiders. If the endpoint is compromised, the tunnel won’t save you.
“We need FTP for partners.”
Reality: Managed portals over HTTPS, SFTP, or pre-signed URLs are easier for non-technical partners and safer for you.

What Good Looks Like: Signals You’re Winning

No cleartext protocols exposed to the internet (and none inside without strong isolation).
SSH replaced Telnet everywhere; password auth disabled for admin access.
FTP replaced with SFTP/FTPS/HTTPS; anonymous access is gone.
SMTP enforces TLS with MTA-STS/DANE; SPF/DKIM/DMARC at p=quarantine or p=reject.
Logs show near 100% encrypted email to/from major providers (benchmark).
Firewall rules and security groups block legacy ports by default.
Regular audits confirm protocol health; exceptions have owners and end dates.

Here’s why that matters: reducing legacy protocol use shrinks your attack surface, makes ransomware less likely, and builds trust with customers and partners.

Quick Reference: Safer Alternatives at a Glance

Telnet → SSH (keys + MFA, modern ciphers)
FTP → SFTP or FTPS (or HTTPS with pre-signed URLs/MFT)
SMTP (basic) → SMTP with enforced TLS + MTA-STS/DANE + SPF/DKIM/DMARC
POP3/IMAP → POP3S/IMAPS only
LDAP → LDAPS with signing and channel binding
SNMPv1/v2c → SNMPv3 (authPriv)
SMBv1 → SMBv3 with encryption; disable v1 everywhere

If you must keep a legacy service for a time, isolate, restrict, and log it. Then plan the exit.

FAQs: People Also Ask

Is SMTP insecure? Does STARTTLS make email safe?

SMTP by itself is insecure. STARTTLS adds encryption in transit, but it’s often opportunistic. To make it safer, enforce TLS with MTA-STS or DANE, and use SPF, DKIM, and DMARC for sender validation. For true confidentiality, use end-to-end encryption like PGP or S/MIME.

What’s the difference between SFTP and FTPS?

SFTP runs over SSH (port 22). It’s a single, firewall-friendly protocol with key-based auth.
FTPS is FTP over TLS. It can require opening extra data ports and careful firewalling. Both encrypt traffic. Choose based on client support and operational fit.

Is Telnet ever okay to use?

On untrusted networks, no. On trusted internal networks, it’s still risky because attackers pivot internally. Use SSH instead. If you must use Telnet for a legacy device, isolate it on a management network and restrict access via jump hosts.

How can I check if my network uses these protocols?

Scan your environment (e.g., nmap) for ports 21, 23, 25, 110, 143, 389, 445, 513, 514, 69.
Review firewall/security group rules.
Inspect SIEM and netflow logs for cleartext sessions.
Search external exposure via tools like Shodan.

Does using a VPN make FTP and Telnet safe enough?

A VPN reduces exposure but doesn’t address weak auth or device compromise. It also doesn’t help if credentials get reused elsewhere. Prefer upgrading the protocol (SSH/SFTP) and use VPN or Zero Trust as an additional layer.

Are POP3 and IMAP secure?

The protocols are fine when wrapped in TLS (POP3S/IMAPS). Disable cleartext versions (110, 143 without STARTTLS). Require modern TLS and strong authentication.

What is MTA-STS vs. DANE for email?

MTA-STS uses HTTPS to publish policies that require TLS for SMTP delivery.
DANE uses DNSSEC to bind SMTP TLS certificates to domains. Both stop downgrade attacks and enforce encryption. Use one or both for stronger guarantees.

We have old devices that only support Telnet/FTP. What can we do?

Short term: isolate them on a management network, restrict source IPs, and monitor. Long term: plan replacement or place them behind gateways that translate to secure protocols. Document exceptions with an end date.

What ports should I block by default?

On the internet edge, block inbound 21 (FTP), 23 (Telnet), 25 (SMTP relay unless you operate it), 110/143 (POP3/IMAP without TLS), 69 (TFTP), 513/514 (r*), and SMB (445) unless you have a specific, secured use case. Egress filtering also helps stop data exfiltration.

The Bottom Line

Old internet protocols still do important jobs, but they’re a gift to attackers. SMTP, FTP, and Telnet were never designed for today’s threat landscape. The fix isn’t to panic—it’s to plan.

Replace Telnet with SSH.
Replace FTP with SFTP/FTPS/HTTPS.
Enforce TLS for SMTP and add SPF/DKIM/DMARC, MTA-STS, or DANE.
Isolate what you can’t replace yet, and set clear deadlines to retire it.

Do that, and you’ll shut the door on a whole class of avoidable attacks while keeping your operations humming. Want more practical security guides like this? Subscribe or explore our latest posts on hardening email, SSH best practices, and secure file transfer patterns.

Discover more at InnoVirtuoso.com

I would love some feedback on my writing so if you have any, please don’t hesitate to leave a comment around here or in any platforms that is convenient for you.

For more on tech and other topics, explore InnoVirtuoso.com anytime. Subscribe to my newsletter and join our growing community—we’ll create something magical together. I promise, it’ll never be boring!

Stay updated with the latest news—subscribe to our newsletter today!

Thank you all—wishing you an amazing day ahead!

The Internet’s Forgotten Protocols: Why SMTP, FTP, and Telnet Are Still Insecure (and What to Use Instead)