You cannot select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
imap: implement parser
This introduces a parser for IMAP protocol, replacing the
detection-only implementation.
An IMAP transaction has two states driven by the 'complete' field:
- Open (complete = false): waiting for a matching tagged response.
- Complete (complete = true): tagged response received, or special
conditions met (BYE, server greeting).
Completion logic (is_complete):
- If a tagged request exists: requires a matching tagged response.
- No tagged request + BYE: complete (server closing).
- No tagged request + any response: complete (server greeting).
Transactions are created in three places:
1. Request parser: every parsed command creates a new tx.
2. Response parser (tagged, no matching request): midstream/async;
orphan tagged response gets its own tx.
3. Response parser (untagged, no incomplete tx): server greeting or
unsolicited response.
Once open, messages accumulate:
- Request side: continuation and literal data attach to the most
recent incomplete tx.
- Response side: untagged responses attach to the most recent
incomplete tx; tagged responses attach via find_request(tag).
Literals, sent by the client (e.g. APPEND) or by the server (e.g.
FETCH), are consumed incrementally and their content is not retained.
Hard limits prevent unbounded growth:
- IMAP_MAX_TX (256, configurable): total transactions. Exceeded:
all incomplete txs force-completed with TooManyTransactions event.
- IMAP_MAX_MSGS_PER_TX (512): requests per tx. Exceeded: request
dropped, DataLimitReached event.
- IMAP_MAX_LINES (512): response lines per tx. Exceeded: line
dropped, DataLimitReached event.
- IMAP_MAX_LINE_BYTES_PER_STATE (100MB): retained request and
response data per flow. Exceeded: data dropped, DataLimitReached
event.
- IMAP_MAX_LINE_SIZE (8KB): request/response line max length.
Exceeded: LineTooLong event.
- Literal size: bounded by declared size in {N} specifier.
IMAP_MAX_TX only is configurable limit via app-layer.protocols.imap.max-tx.
Ticket #8276
9 months ago
|
|
|
/* Copyright (C) 2026 Open Information Security Foundation
|
|
|
|
|
*
|
|
|
|
|
* You can copy, redistribute or modify this Program under the terms of
|
|
|
|
|
* the GNU General Public License version 2 as published by the Free
|
|
|
|
|
* Software Foundation.
|
|
|
|
|
*
|
|
|
|
|
* This program is distributed in the hope that it will be useful,
|
|
|
|
|
* but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
|
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
|
|
|
|
* GNU General Public License for more details.
|
|
|
|
|
*
|
|
|
|
|
* You should have received a copy of the GNU General Public License
|
|
|
|
|
* version 2 along with this program; if not, write to the Free Software
|
|
|
|
|
* Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
|
|
|
|
|
* 02110-1301, USA.
|
|
|
|
|
*/
|
|
|
|
|
|
imap: implement parser
This introduces a parser for IMAP protocol, replacing the
detection-only implementation.
An IMAP transaction has two states driven by the 'complete' field:
- Open (complete = false): waiting for a matching tagged response.
- Complete (complete = true): tagged response received, or special
conditions met (BYE, server greeting).
Completion logic (is_complete):
- If a tagged request exists: requires a matching tagged response.
- No tagged request + BYE: complete (server closing).
- No tagged request + any response: complete (server greeting).
Transactions are created in three places:
1. Request parser: every parsed command creates a new tx.
2. Response parser (tagged, no matching request): midstream/async;
orphan tagged response gets its own tx.
3. Response parser (untagged, no incomplete tx): server greeting or
unsolicited response.
Once open, messages accumulate:
- Request side: continuation and literal data attach to the most
recent incomplete tx.
- Response side: untagged responses attach to the most recent
incomplete tx; tagged responses attach via find_request(tag).
Literals, sent by the client (e.g. APPEND) or by the server (e.g.
FETCH), are consumed incrementally and their content is not retained.
Hard limits prevent unbounded growth:
- IMAP_MAX_TX (256, configurable): total transactions. Exceeded:
all incomplete txs force-completed with TooManyTransactions event.
- IMAP_MAX_MSGS_PER_TX (512): requests per tx. Exceeded: request
dropped, DataLimitReached event.
- IMAP_MAX_LINES (512): response lines per tx. Exceeded: line
dropped, DataLimitReached event.
- IMAP_MAX_LINE_BYTES_PER_STATE (100MB): retained request and
response data per flow. Exceeded: data dropped, DataLimitReached
event.
- IMAP_MAX_LINE_SIZE (8KB): request/response line max length.
Exceeded: LineTooLong event.
- Literal size: bounded by declared size in {N} specifier.
IMAP_MAX_TX only is configurable limit via app-layer.protocols.imap.max-tx.
Ticket #8276
9 months ago
|
|
|
// Author: Giuseppe Longo <glongo@oisf.net>
|
|
|
|
|
|
imap: implement parser
This introduces a parser for IMAP protocol, replacing the
detection-only implementation.
An IMAP transaction has two states driven by the 'complete' field:
- Open (complete = false): waiting for a matching tagged response.
- Complete (complete = true): tagged response received, or special
conditions met (BYE, server greeting).
Completion logic (is_complete):
- If a tagged request exists: requires a matching tagged response.
- No tagged request + BYE: complete (server closing).
- No tagged request + any response: complete (server greeting).
Transactions are created in three places:
1. Request parser: every parsed command creates a new tx.
2. Response parser (tagged, no matching request): midstream/async;
orphan tagged response gets its own tx.
3. Response parser (untagged, no incomplete tx): server greeting or
unsolicited response.
Once open, messages accumulate:
- Request side: continuation and literal data attach to the most
recent incomplete tx.
- Response side: untagged responses attach to the most recent
incomplete tx; tagged responses attach via find_request(tag).
Literals, sent by the client (e.g. APPEND) or by the server (e.g.
FETCH), are consumed incrementally and their content is not retained.
Hard limits prevent unbounded growth:
- IMAP_MAX_TX (256, configurable): total transactions. Exceeded:
all incomplete txs force-completed with TooManyTransactions event.
- IMAP_MAX_MSGS_PER_TX (512): requests per tx. Exceeded: request
dropped, DataLimitReached event.
- IMAP_MAX_LINES (512): response lines per tx. Exceeded: line
dropped, DataLimitReached event.
- IMAP_MAX_LINE_BYTES_PER_STATE (100MB): retained request and
response data per flow. Exceeded: data dropped, DataLimitReached
event.
- IMAP_MAX_LINE_SIZE (8KB): request/response line max length.
Exceeded: LineTooLong event.
- Literal size: bounded by declared size in {N} specifier.
IMAP_MAX_TX only is configurable limit via app-layer.protocols.imap.max-tx.
Ticket #8276
9 months ago
|
|
|
pub mod imap;
|
|
|
|
|
pub mod logger;
|
imap: implement parser
This introduces a parser for IMAP protocol, replacing the
detection-only implementation.
An IMAP transaction has two states driven by the 'complete' field:
- Open (complete = false): waiting for a matching tagged response.
- Complete (complete = true): tagged response received, or special
conditions met (BYE, server greeting).
Completion logic (is_complete):
- If a tagged request exists: requires a matching tagged response.
- No tagged request + BYE: complete (server closing).
- No tagged request + any response: complete (server greeting).
Transactions are created in three places:
1. Request parser: every parsed command creates a new tx.
2. Response parser (tagged, no matching request): midstream/async;
orphan tagged response gets its own tx.
3. Response parser (untagged, no incomplete tx): server greeting or
unsolicited response.
Once open, messages accumulate:
- Request side: continuation and literal data attach to the most
recent incomplete tx.
- Response side: untagged responses attach to the most recent
incomplete tx; tagged responses attach via find_request(tag).
Literals, sent by the client (e.g. APPEND) or by the server (e.g.
FETCH), are consumed incrementally and their content is not retained.
Hard limits prevent unbounded growth:
- IMAP_MAX_TX (256, configurable): total transactions. Exceeded:
all incomplete txs force-completed with TooManyTransactions event.
- IMAP_MAX_MSGS_PER_TX (512): requests per tx. Exceeded: request
dropped, DataLimitReached event.
- IMAP_MAX_LINES (512): response lines per tx. Exceeded: line
dropped, DataLimitReached event.
- IMAP_MAX_LINE_BYTES_PER_STATE (100MB): retained request and
response data per flow. Exceeded: data dropped, DataLimitReached
event.
- IMAP_MAX_LINE_SIZE (8KB): request/response line max length.
Exceeded: LineTooLong event.
- Literal size: bounded by declared size in {N} specifier.
IMAP_MAX_TX only is configurable limit via app-layer.protocols.imap.max-tx.
Ticket #8276
9 months ago
|
|
|
pub mod parser;
|
