587
Summary
- // if you see it open
- Credential brute-forcing/password-spray is the main risk (Microsoft names SMTP and IMAP as top password-spray protocols). The cleartext window before STARTTLS is vulnerable to stripping/downgrade and command injection (e.g., CVE-2021-33515 in Dovecot's submission service). Basic-auth submission is being retired by major providers in favor of OAuth (Microsoft 365, rollout into 2026-2027).
- // common applications
- PostfixSendmailEximThunderbirdOutlook
- // analyst note
- Open 587/tcp indicates a submission agent expecting authenticated clients. Verify STARTTLS is advertised AND required before AUTH, check for cleartext AUTH exposure, and watch logs for distributed login failures (password spray).
About port 587/tcp.
Port 587/tcp is the standards-defined port for authenticated client mail submission (MUA→MSA). RFC 6409 (STD 72) reserves it specifically so that mail *submission* from end-user clients is separated from server-to-server *relay* on port 25, letting operators apply different authentication, filtering, and policy to each. A typical 587 session opens in cleartext, the client sends EHLO and then STARTTLS (RFC 3207) to upgrade the connection to TLS, and only then authenticates via SMTP AUTH (RFC 4954); a submission server is required to implement AUTH. The main security exposure is credential brute-forcing and password-spray against the submission endpoint — Microsoft's Exchange team identifies SMTP and IMAP as the two most-targeted protocols for password spray — and the brief pre-STARTTLS window is the subject of a documented command-injection/stripping class (e.g., CVE-2021-33515 in Dovecot's submission service), which is the reason RFC 8314 prefers implicit TLS on 465. Basic-auth submission is being retired by major providers in favor of OAuth; Microsoft has announced that Basic Auth for these protocols is being removed from Exchange Online (rollout into 2026–2027). For an analyst, an open 587/tcp indicates a submission agent expecting authenticated clients; verify that STARTTLS is advertised and required before AUTH, check for cleartext-AUTH exposure, and watch authentication logs for distributed login failures indicative of password spray.
- IANA assignment
submission— "Message Submission"; reference [RFC6409]; modified 2011-11-17 [IANA-assigned] — IANA Service Name and Transport Protocol Port Number Registry- Range class
- well-known (0–1023)
- Prevalence
- nmap-services open-frequency 0.019721 [Well-established] — nmap-services file
- Related ports
- 465 (submission + implicit TLS), 25 (relay)
Primary use
authenticated client mail submission (MUA→MSA) with STARTTLS upgrade; the standards-recommended submission port
Other/unofficial uses
occasionally used without STARTTLS in legacy setups (discouraged)
Security implications
credential brute-force/password-spray (SMTP among the top password-spray targets per Microsoft); pre-STARTTLS command-injection/stripping (e.g., CVE-2021-33515, Dovecot submission); basic-auth retirement in favor of OAuth (Microsoft 365, into 2026–2027)
Typically seen on
provider/host submission agents; MUAs' configured outgoing servers
- Analyst note
- Open 587/tcp indicates a submission agent expecting authenticated clients. Verify STARTTLS is advertised AND required before AUTH, check for cleartext AUTH exposure, and watch logs for distributed login failures (password spray).
About port 587/udp.
Port 587/udp is registered with IANA as submission with the description "Message Submission," a blank assignee field, reference [RFC6409], and a modification date of 2011-11-17 (the registry leaves the registration date column blank for this entry). The registration mirrors 587/tcp exactly — both transports carry the same service name, description, reference, and modification date (CSV lines 1193–1194) — which reflects the historical IANA practice of assigning a service name across both TCP and UDP at once rather than any actual UDP protocol. The substance of port 587 is RFC 6409, *Message Submission for Mail* (November 2011, obsoleting RFC 4409), the IETF standard that splits authenticated mail submission from server-to-server relay. RFC 6409 makes no provision for UDP: SMTP/ESMTP is a connection-oriented, ordered, reliable conversation that fundamentally requires TCP, and the RFC text does not mention UDP anywhere. As a result the UDP registration is a paper assignment — a vestigial mirror of the TCP entry with no implementation behind it. No mail user agent (Outlook, Apple Mail, Thunderbird) and no transactional provider (Mailgun, SendGrid, MailerSend) configures or listens on 587/udp; the entire submission ecosystem uses 587/tcp with STARTTLS. For an analyst, 587/udp has effectively no attack surface: scanning sources (SANS ISC, Shodan) record no meaningful UDP service on this port, UDP probes to it return ICMP port-unreachable or silence on essentially all hosts, and no CVE is tied to 587/udp specifically. The meaningful risk profile (credential brute-forcing, relay abuse, STARTTLS stripping) belongs to the TCP counterpart and is out of scope here. So a responsive port 587 in the wild is a TCP submission service; the UDP registration is best understood as a registry artifact rather than a live protocol.
- IANA assignment
submission— "Message Submission"; reference[RFC6409]; assignee blank; registration date blank (not published); modification date 2011-11-17; dual-registered 587/tcp + 587/udp with identical metadata [Confirmed] — IANA Service Name and Transport Protocol Port Number Registry CSV (line 1194)- Range class
- registered (1024–49151)
- Prevalence
- no meaningful open-host count for 587/udp as a distinct service; observed activity on port 587 is TCP. UDP sweeps occasionally probe it but get ICMP unreachable or silence [Likely] — SANS ISC port 587; Shodan ports index
- Related ports
- 587/tcp (the live submission service); 465/tcp (implicit-TLS submission); 25 (SMTP relay); 143/993 and 110/995 (IMAP/POP retrieval)
Primary use
none in practice — the UDP entry mirrors 587/tcp but RFC 6409 (Message Submission for Mail) defines no UDP transport; SMTP submission is TCP-only
Other/unofficial uses
none known; no mail client or server daemon opens 587/udp
Security implications
effectively nil — no service listens on 587/udp, so no attack surface; no CVE specific to 587/udp. (The TCP counterpart 587/tcp carries the real risk: credential brute-force, relay abuse, STARTTLS stripping — out of scope for the UDP entry.)
Typically seen on
nothing — there is no real deployment of 587/udp; port 587 traffic seen on a host is its TCP submission service
- Analyst note
- Treat 587/udp as a registry mirror of 587/tcp with no implementation. RFC 6409 governs submission but specifies TCP only; a host showing "port 587" activity is running TCP submission, not a UDP service.
Service assignments.
| Name | Protocol | Description | Open frequency |
|---|---|---|---|
| submission | TCP | Message Submission | 1.97% |
| submission | UDP | — | 0.07% |
Service assignments from the IANA Service Name and Transport Protocol Port Number Registry, with open-frequency data from nmap-services.