Enum ProtocolError 

#[non_exhaustive]
pub enum ProtocolError {
    UnexpectedCode {
        during: SmtpOp,
        expected_class: u8,
        actual: u16,
        enhanced: Option<EnhancedStatus>,
        message: String,
    },
    Malformed(String),
    UnexpectedClose,
    LineTooLong,
    InconsistentMultiline {
        first: u16,
        later: u16,
    },
    ExtensionUnavailable {
        name: &'static str,
    },
    StartTlsBufferResidue {
        byte_count: usize,
    },
}

A wire-format failure or an unexpected response from the server.

This enum is non_exhaustive so that future SMTP extensions can add new failure modes without forcing a major version bump.

Variants (Non-exhaustive)

Non-exhaustive enums could have additional variants added in future. Therefore, when matching against variants of non-exhaustive enums, an extra wildcard arm must be added to account for any future variants.

UnexpectedCode

The server returned a reply whose code class did not match what the state machine required at this point.

during records the SMTP operation that was in progress. This lets a caller surface “MAIL FROM rejected (550)” rather than the less actionable “550”.

expected_class is one of 2, 3, etc., representing the leading digit. actual is the full three-digit code as observed.

enhanced carries the parsed RFC 3463 status code if and only if the server advertised ENHANCEDSTATUSCODES and the reply began with a class.subject.detail token. It refines actual significantly — for instance, the basic code 550 covers many distinct failure modes (5.1.1 user unknown, 5.7.1 policy rejection, …) that a caller may want to distinguish programmatically.

Fields

during: SmtpOp

The SMTP operation that was in progress.

expected_class: u8

The leading reply-code digit the state machine required.

actual: u16

The full three-digit reply code actually returned.

enhanced: Option<EnhancedStatus>

Optional enhanced status code (RFC 3463), present only when the session has ENHANCEDSTATUSCODES enabled and the server attached a parseable code to its reply.

message: String

The server-supplied reply text (joined across multi-line replies with \n). When enhanced is Some, the prefix is left in the message so the wire form is preserved; presentation code can re-render the code separately if desired.

Malformed(String)

A reply line did not parse: wrong length, non-digit code, illegal continuation marker, or non-UTF-8 in a position where text was expected.

UnexpectedClose

The server closed the connection while the state machine was waiting for more data.

LineTooLong

A reply line exceeded the SMTP line-length limit (RFC 5321 §4.5.3.1.5, 1000 octets including CRLF).

InconsistentMultiline

A multi-line reply contained inconsistent reply codes across lines. RFC 5321 requires every line of a multi-line reply to share the same three-digit code.

Fields

first: u16

The code on the first line.

later: u16

The differing code observed on a later line.

ExtensionUnavailable

The client requested an SMTP extension that the server did not advertise in its EHLO response.

Today this is raised only when the caller asks for STARTTLS but the server’s EHLO capability list does not include it.

Fields

name: &'static str

The extension keyword as it would appear in EHLO (e.g. "STARTTLS").

StartTlsBufferResidue

Bytes were observed in the receive buffer between the server’s 220 reply to STARTTLS and the start of the TLS handshake.

This is the signature of a STARTTLS injection (also known as “STARTTLS command injection” or CVE-2011-1575-class) attack: an attacker pipelines additional SMTP commands on top of STARTTLS while the channel is still plaintext, hoping the client will treat them as commands sent over the secured channel after the upgrade. Robust clients detect any unread bytes at the moment of upgrade and abort the session rather than risk silently treating attacker- injected plaintext as authenticated post-TLS traffic.

byte_count is the number of bytes that were already in the receive buffer when the upgrade was about to begin. Any non-zero value is suspicious; zero is the safe case and never produces this error.

Fields

byte_count: usize

Number of unread bytes observed in the receive buffer after the 220 STARTTLS reply.

Trait Implementations

impl Debug for ProtocolError

fn fmt(&self, f: &mut Formatter<'_>) -> Result

Formats the value using the given formatter.

impl Display for ProtocolError

fn fmt(&self, f: &mut Formatter<'_>) -> Result

Formats the value using the given formatter.

impl Error for ProtocolError

fn source(&self) -> Option<&(dyn Error + 'static)>

Returns the lower-level source of this error, if any.

fn description(&self) -> &str

👎Deprecated since 1.42.0:

use the Display impl or to_string()

fn cause(&self) -> Option<&dyn Error>

👎Deprecated since 1.33.0:

replaced by Error::source, which can support downcasting

fn provide<'a>(&'a self, request: &mut Request<'a>)

🔬This is a nightly-only experimental API. (error_generic_member_access)

Provides type-based access to context intended for error reports.

impl From<ProtocolError> for SmtpError

fn from(value: ProtocolError) -> Self

Converts to this type from the input type.