Message Submission BURL Extension
updated by
- rfc-5248 — A Registry for SMTP Enhanced Mail System Status Codes
updates
- rfc-3463 — Enhanced Mail System Status Codes
Extracted elements (23)
BURL is restricted to the submission profile (port 587) and not permitted on port 25 relay servers because it requires a trust relationship between the submit server and an IMAP server, and because relay servers lack the per-user authentication context needed to safely resolve IMAP URLs on behalf of users.
BURL clients MUST tolerate any valid SMTP response code; the response code examples in Section 6 are illustrative and the list is not exhaustive. Other response text may be used with the same codes.
Pipelining of the AUTH command is only permitted if the selected SASL mechanism can be completed in one round trip with a client initial response and no SASL security layer negotiated; this applies to PLAIN and EXTERNAL but not most other SASL mechanisms.
A submit server that advertises BURL MUST also advertise 8BITMIME and perform down conversion on the resulting complete message if 8-bit data is received with BURL and passed to a 7-bit server.
Clients MUST ignore unrecognized arguments after the BURL EHLO keyword unless defined by a subsequent IETF standards track specification.
If the IMAP URL uses the 'submit+' access identifier prefix, the submit server MUST refuse the BURL command unless the userid in the URL's access token matches the submit client's authorization identity.
The authentication identity and password used for submit credentials when connecting to the IMAP server MUST be configurable. The string 'submit' is suggested as a default authentication identity with no default password.
The BURL extension MUST NOT be advertised by a regular SMTP server on port 25 that acts as a relay for incoming mail; it is restricted to the message submission profile on port 587.
The submit server MUST implement a configuration that uses STARTTLS followed by SASL PLAIN to authenticate to the IMAP server when acting as an IMAP client.
When CHUNKING and PIPELINING are both advertised, the client may pipeline the entire transaction in one round-trip but MUST wait for the results of the 'LAST' BDAT or BURL command prior to initiating a new transaction.
When resolving a regular IMAP URL, the submit server SHOULD forward the client's credentials to the IMAP server if and only if the submit server knows the IMAP server is in the same administrative domain.
A BURL transaction consists of MAIL FROM, one or more RCPT TO commands, and a BURL command with the 'LAST' tag containing an IMAP URL pointing to a fully formed message. If no valid RCPT TO is supplied, BURL fails without resolving the URL.
The BURL extension adds a new SMTP verb 'BURL' used as a replacement for the DATA command. It is only permitted during a mail transaction after at least one successful RCPT TO, and accepts an absolute URI with an optional 'LAST' end-marker.
Two new enhanced status codes are defined: X.6.6 'Message content not available' (content could not be fetched from a remote system) and X.7.8 'Trust relationship required' (submission server lacks a configured trust relationship with a third-party server).
When 'imap' appears in the BURL EHLO keyword arguments, it indicates the server supports the URLAUTH extended form of IMAP URLs and is configured with credentials to resolve 'urlauth=submit+' IMAP URLs for its domain.
The 'BURL' SMTP extension has been registered in the SMTP extensions registry, marked for use by message submission (port 587) only, not for general SMTP relay use.
A malicious authenticated user could supply a fraudulent IMAP URL pointing to a server they control to extract submit credentials. Mitigations include restricting submit credentials to a fixed set of trusted IMAP servers, treating IMAP servers as untrusted with buffer overflow and DoS defenses, and maintaining a secure audit trail.
BURL could be exploited by clients generating unsolicited bulk email or viruses to compensate for slow links, making programmable devices significant spam/virus sources. Submit servers must implement auditing, mandatory authentication, logging, URL reuse limits, rate limits, recipient limits, and content filters.
Implementations of BURL should fetch URL content prior to applying content-based security mechanisms (virus filtering, spam filtering, size limits, server signatures) in order to preserve their function.
Trust relationships between submit and IMAP servers must not use super-user proxy credentials, as a compromised submit server should not automatically compromise all IMAP accounts. URLAUTH-based access or a trusted third-party credential model (e.g., Kerberos 5) is preferred.
URLAUTH IMAP URLs transferred in the clear expose authorization tokens to eavesdroppers. Implementations should require SMTP STARTTLS and IMAP STARTTLS in combination when such URLs are used.
When a client uses SMTP STARTTLS to send a BURL command referencing non-public information, the submission server SHOULD use STARTTLS or equivalent confidentiality when fetching the referenced URL content.
The BURL command syntax is: 'BURL' SP absolute-URI [SP end-marker] CRLF, where end-marker is the literal string 'LAST'. The burl-param EHLO argument is either 'imap' or 'imap://' followed by an authority.