2000-08-19 23:06:51 +00:00
|
|
|
/* packet-smtp.c
|
2000-08-20 02:16:23 +00:00
|
|
|
* Routines for SMTP packet disassembly
|
2000-08-19 23:06:51 +00:00
|
|
|
*
|
2004-07-18 00:24:25 +00:00
|
|
|
* $Id$
|
2000-08-19 23:06:51 +00:00
|
|
|
*
|
|
|
|
* Copyright (c) 2000 by Richard Sharpe <rsharpe@ns.aus.com>
|
|
|
|
*
|
2006-05-21 04:49:01 +00:00
|
|
|
* Wireshark - Network traffic analyzer
|
|
|
|
* By Gerald Combs <gerald@wireshark.org>
|
2000-08-19 23:06:51 +00:00
|
|
|
* Copyright 1999 Gerald Combs
|
2001-12-03 04:00:26 +00:00
|
|
|
*
|
2000-08-19 23:06:51 +00:00
|
|
|
* This program is free software; you can redistribute it and/or
|
|
|
|
* modify it under the terms of the GNU General Public License
|
|
|
|
* as published by the Free Software Foundation; either version 2
|
|
|
|
* of the License, or (at your option) any later version.
|
|
|
|
*
|
|
|
|
* 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
|
|
|
|
* along with this program; if not, write to the Free Software
|
|
|
|
* Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
|
|
|
|
*/
|
|
|
|
|
|
|
|
#ifdef HAVE_CONFIG_H
|
|
|
|
#include "config.h"
|
|
|
|
#endif
|
|
|
|
|
|
|
|
#include <stdio.h>
|
|
|
|
#include <stdlib.h>
|
|
|
|
#include <ctype.h>
|
|
|
|
#include <time.h>
|
|
|
|
#include <glib.h>
|
|
|
|
#include <string.h>
|
2002-01-21 07:37:49 +00:00
|
|
|
#include <epan/packet.h>
|
|
|
|
#include <epan/conversation.h>
|
2004-08-06 19:57:49 +00:00
|
|
|
#include <epan/addr_resolv.h>
|
2004-09-27 22:55:15 +00:00
|
|
|
#include <epan/prefs.h>
|
2002-01-21 07:37:49 +00:00
|
|
|
#include <epan/strutil.h>
|
2005-08-12 10:03:17 +00:00
|
|
|
#include <epan/emem.h>
|
2000-08-19 23:06:51 +00:00
|
|
|
|
|
|
|
#define TCP_PORT_SMTP 25
|
|
|
|
|
|
|
|
static int proto_smtp = -1;
|
|
|
|
|
|
|
|
static int hf_smtp_req = -1;
|
|
|
|
static int hf_smtp_rsp = -1;
|
2002-07-14 00:40:07 +00:00
|
|
|
static int hf_smtp_req_command = -1;
|
|
|
|
static int hf_smtp_req_parameter = -1;
|
|
|
|
static int hf_smtp_rsp_code = -1;
|
|
|
|
static int hf_smtp_rsp_parameter = -1;
|
2000-08-19 23:06:51 +00:00
|
|
|
|
|
|
|
static int ett_smtp = -1;
|
2003-06-11 18:22:12 +00:00
|
|
|
static int ett_smtp_cmdresp = -1;
|
2000-08-19 23:06:51 +00:00
|
|
|
|
2002-07-17 06:55:29 +00:00
|
|
|
/* desegmentation of SMTP command and response lines */
|
|
|
|
static gboolean smtp_desegment = TRUE;
|
|
|
|
|
2000-08-24 11:32:09 +00:00
|
|
|
/*
|
|
|
|
* A CMD is an SMTP command, MESSAGE is the message portion, and EOM is the
|
|
|
|
* last part of a message
|
|
|
|
*/
|
|
|
|
|
2002-08-28 21:04:11 +00:00
|
|
|
#define SMTP_PDU_CMD 0
|
2000-08-24 11:32:09 +00:00
|
|
|
#define SMTP_PDU_MESSAGE 1
|
|
|
|
#define SMTP_PDU_EOM 2
|
|
|
|
|
|
|
|
struct smtp_proto_data {
|
|
|
|
guint16 pdu_type;
|
|
|
|
};
|
|
|
|
|
Simplify the state machine:
you're either reading commands, or you're reading message data;
if you're reading commands, and you see a DATA command, you
start reading data;
if you're reading data, and you see an EOM, you start reading
commands.
Also, *always* fill in the per-frame data you allocate for a frame, and
*always* attach it to the packet.
The old state machine assumed it was done with the SMTP conversation
once it saw an EOM, and the dissector wouldn't fill in the per-frame
data it'd allocated and attach it to the packet if it thought it was
done with the SMTP conversation. This meant that:
1) the per-frame data allocated for frames following the EOM
(e.g., a QUIT command) would contain random junk for data
such as the packet type;
2) that per-frame data would be re-allocated every time the
frame was looked at, as it wouldn't be attached to the frame,
so you might well get *different* random junk each time the
frame was looked at.
This caused Tethereal and Ethereal to sometimes fail to recognize
commands following the EOM - but it wouldn't *always* fail to do so,
sometimes it'd work and sometimes it wouldn't.
Fix a comment; conversations are *not* removed during filter operations,
and the visited flag is *not* cleared during a filter operation - that's
only true on a *redissection* operation. In any case, given that frames
can, after the initial sequential scan through the capture, be visited
in any order, and visited repeatedly, it's irrelevant whether
conversations are removed or not - we have to associate with each frame
information telling us how to process it.
svn path=/trunk/; revision=2608
2000-11-11 07:48:30 +00:00
|
|
|
/*
|
|
|
|
* State information stored with a conversation.
|
|
|
|
*/
|
2000-08-24 11:32:09 +00:00
|
|
|
struct smtp_request_val {
|
Simplify the state machine:
you're either reading commands, or you're reading message data;
if you're reading commands, and you see a DATA command, you
start reading data;
if you're reading data, and you see an EOM, you start reading
commands.
Also, *always* fill in the per-frame data you allocate for a frame, and
*always* attach it to the packet.
The old state machine assumed it was done with the SMTP conversation
once it saw an EOM, and the dissector wouldn't fill in the per-frame
data it'd allocated and attach it to the packet if it thought it was
done with the SMTP conversation. This meant that:
1) the per-frame data allocated for frames following the EOM
(e.g., a QUIT command) would contain random junk for data
such as the packet type;
2) that per-frame data would be re-allocated every time the
frame was looked at, as it wouldn't be attached to the frame,
so you might well get *different* random junk each time the
frame was looked at.
This caused Tethereal and Ethereal to sometimes fail to recognize
commands following the EOM - but it wouldn't *always* fail to do so,
sometimes it'd work and sometimes it wouldn't.
Fix a comment; conversations are *not* removed during filter operations,
and the visited flag is *not* cleared during a filter operation - that's
only true on a *redissection* operation. In any case, given that frames
can, after the initial sequential scan through the capture, be visited
in any order, and visited repeatedly, it's irrelevant whether
conversations are removed or not - we have to associate with each frame
information telling us how to process it.
svn path=/trunk/; revision=2608
2000-11-11 07:48:30 +00:00
|
|
|
gboolean reading_data; /* Reading message data, not commands */
|
2000-08-24 11:32:09 +00:00
|
|
|
guint16 crlf_seen; /* Have we seen a CRLF on the end of a packet */
|
|
|
|
};
|
|
|
|
|
2000-08-19 23:06:51 +00:00
|
|
|
static void
|
|
|
|
dissect_smtp(tvbuff_t *tvb, packet_info *pinfo, proto_tree *tree)
|
|
|
|
{
|
2000-08-24 11:32:09 +00:00
|
|
|
struct smtp_proto_data *frame_data;
|
2000-11-12 02:29:20 +00:00
|
|
|
proto_tree *smtp_tree;
|
2003-06-11 18:22:12 +00:00
|
|
|
proto_tree *cmdresp_tree;
|
2000-11-12 02:29:20 +00:00
|
|
|
proto_item *ti;
|
|
|
|
int offset = 0;
|
2000-08-24 11:32:09 +00:00
|
|
|
int request = 0;
|
|
|
|
conversation_t *conversation;
|
|
|
|
struct smtp_request_val *request_val;
|
2002-08-02 23:36:07 +00:00
|
|
|
const guchar *line;
|
2002-07-15 09:40:20 +00:00
|
|
|
guint32 code;
|
2000-11-12 02:29:20 +00:00
|
|
|
int linelen;
|
2003-06-10 05:45:33 +00:00
|
|
|
gint length_remaining;
|
Simplify the state machine:
you're either reading commands, or you're reading message data;
if you're reading commands, and you see a DATA command, you
start reading data;
if you're reading data, and you see an EOM, you start reading
commands.
Also, *always* fill in the per-frame data you allocate for a frame, and
*always* attach it to the packet.
The old state machine assumed it was done with the SMTP conversation
once it saw an EOM, and the dissector wouldn't fill in the per-frame
data it'd allocated and attach it to the packet if it thought it was
done with the SMTP conversation. This meant that:
1) the per-frame data allocated for frames following the EOM
(e.g., a QUIT command) would contain random junk for data
such as the packet type;
2) that per-frame data would be re-allocated every time the
frame was looked at, as it wouldn't be attached to the frame,
so you might well get *different* random junk each time the
frame was looked at.
This caused Tethereal and Ethereal to sometimes fail to recognize
commands following the EOM - but it wouldn't *always* fail to do so,
sometimes it'd work and sometimes it wouldn't.
Fix a comment; conversations are *not* removed during filter operations,
and the visited flag is *not* cleared during a filter operation - that's
only true on a *redissection* operation. In any case, given that frames
can, after the initial sequential scan through the capture, be visited
in any order, and visited repeatedly, it's irrelevant whether
conversations are removed or not - we have to associate with each frame
information telling us how to process it.
svn path=/trunk/; revision=2608
2000-11-11 07:48:30 +00:00
|
|
|
gboolean eom_seen = FALSE;
|
2000-11-12 02:29:20 +00:00
|
|
|
gint next_offset;
|
|
|
|
gboolean is_continuation_line;
|
|
|
|
int cmdlen;
|
2000-08-19 23:06:51 +00:00
|
|
|
|
Simplify the state machine:
you're either reading commands, or you're reading message data;
if you're reading commands, and you see a DATA command, you
start reading data;
if you're reading data, and you see an EOM, you start reading
commands.
Also, *always* fill in the per-frame data you allocate for a frame, and
*always* attach it to the packet.
The old state machine assumed it was done with the SMTP conversation
once it saw an EOM, and the dissector wouldn't fill in the per-frame
data it'd allocated and attach it to the packet if it thought it was
done with the SMTP conversation. This meant that:
1) the per-frame data allocated for frames following the EOM
(e.g., a QUIT command) would contain random junk for data
such as the packet type;
2) that per-frame data would be re-allocated every time the
frame was looked at, as it wouldn't be attached to the frame,
so you might well get *different* random junk each time the
frame was looked at.
This caused Tethereal and Ethereal to sometimes fail to recognize
commands following the EOM - but it wouldn't *always* fail to do so,
sometimes it'd work and sometimes it wouldn't.
Fix a comment; conversations are *not* removed during filter operations,
and the visited flag is *not* cleared during a filter operation - that's
only true on a *redissection* operation. In any case, given that frames
can, after the initial sequential scan through the capture, be visited
in any order, and visited repeatedly, it's irrelevant whether
conversations are removed or not - we have to associate with each frame
information telling us how to process it.
svn path=/trunk/; revision=2608
2000-11-11 07:48:30 +00:00
|
|
|
/* As there is no guarantee that we will only see frames in the
|
|
|
|
* the SMTP conversation once, and that we will see them in
|
2006-05-21 04:49:01 +00:00
|
|
|
* order - in Wireshark, the user could randomly click on frames
|
Simplify the state machine:
you're either reading commands, or you're reading message data;
if you're reading commands, and you see a DATA command, you
start reading data;
if you're reading data, and you see an EOM, you start reading
commands.
Also, *always* fill in the per-frame data you allocate for a frame, and
*always* attach it to the packet.
The old state machine assumed it was done with the SMTP conversation
once it saw an EOM, and the dissector wouldn't fill in the per-frame
data it'd allocated and attach it to the packet if it thought it was
done with the SMTP conversation. This meant that:
1) the per-frame data allocated for frames following the EOM
(e.g., a QUIT command) would contain random junk for data
such as the packet type;
2) that per-frame data would be re-allocated every time the
frame was looked at, as it wouldn't be attached to the frame,
so you might well get *different* random junk each time the
frame was looked at.
This caused Tethereal and Ethereal to sometimes fail to recognize
commands following the EOM - but it wouldn't *always* fail to do so,
sometimes it'd work and sometimes it wouldn't.
Fix a comment; conversations are *not* removed during filter operations,
and the visited flag is *not* cleared during a filter operation - that's
only true on a *redissection* operation. In any case, given that frames
can, after the initial sequential scan through the capture, be visited
in any order, and visited repeatedly, it's irrelevant whether
conversations are removed or not - we have to associate with each frame
information telling us how to process it.
svn path=/trunk/; revision=2608
2000-11-11 07:48:30 +00:00
|
|
|
* in the conversation in any order in which they choose - we
|
|
|
|
* have to store information with each frame indicating whether
|
|
|
|
* it contains commands or data or an EOM indication.
|
|
|
|
*
|
|
|
|
* XXX - what about frames that contain *both*? TCP is a
|
|
|
|
* byte-stream protocol, and there are no guarantees that
|
|
|
|
* TCP segment boundaries will correspond to SMTP commands
|
|
|
|
* or EOM indications.
|
|
|
|
*
|
|
|
|
* We only need that for the client->server stream; responses
|
2000-08-24 11:32:09 +00:00
|
|
|
* are easy to manage.
|
Simplify the state machine:
you're either reading commands, or you're reading message data;
if you're reading commands, and you see a DATA command, you
start reading data;
if you're reading data, and you see an EOM, you start reading
commands.
Also, *always* fill in the per-frame data you allocate for a frame, and
*always* attach it to the packet.
The old state machine assumed it was done with the SMTP conversation
once it saw an EOM, and the dissector wouldn't fill in the per-frame
data it'd allocated and attach it to the packet if it thought it was
done with the SMTP conversation. This meant that:
1) the per-frame data allocated for frames following the EOM
(e.g., a QUIT command) would contain random junk for data
such as the packet type;
2) that per-frame data would be re-allocated every time the
frame was looked at, as it wouldn't be attached to the frame,
so you might well get *different* random junk each time the
frame was looked at.
This caused Tethereal and Ethereal to sometimes fail to recognize
commands following the EOM - but it wouldn't *always* fail to do so,
sometimes it'd work and sometimes it wouldn't.
Fix a comment; conversations are *not* removed during filter operations,
and the visited flag is *not* cleared during a filter operation - that's
only true on a *redissection* operation. In any case, given that frames
can, after the initial sequential scan through the capture, be visited
in any order, and visited repeatedly, it's irrelevant whether
conversations are removed or not - we have to associate with each frame
information telling us how to process it.
svn path=/trunk/; revision=2608
2000-11-11 07:48:30 +00:00
|
|
|
*
|
2002-08-28 21:04:11 +00:00
|
|
|
* If we have per frame data, use that, else, we must be on the first
|
Simplify the state machine:
you're either reading commands, or you're reading message data;
if you're reading commands, and you see a DATA command, you
start reading data;
if you're reading data, and you see an EOM, you start reading
commands.
Also, *always* fill in the per-frame data you allocate for a frame, and
*always* attach it to the packet.
The old state machine assumed it was done with the SMTP conversation
once it saw an EOM, and the dissector wouldn't fill in the per-frame
data it'd allocated and attach it to the packet if it thought it was
done with the SMTP conversation. This meant that:
1) the per-frame data allocated for frames following the EOM
(e.g., a QUIT command) would contain random junk for data
such as the packet type;
2) that per-frame data would be re-allocated every time the
frame was looked at, as it wouldn't be attached to the frame,
so you might well get *different* random junk each time the
frame was looked at.
This caused Tethereal and Ethereal to sometimes fail to recognize
commands following the EOM - but it wouldn't *always* fail to do so,
sometimes it'd work and sometimes it wouldn't.
Fix a comment; conversations are *not* removed during filter operations,
and the visited flag is *not* cleared during a filter operation - that's
only true on a *redissection* operation. In any case, given that frames
can, after the initial sequential scan through the capture, be visited
in any order, and visited repeatedly, it's irrelevant whether
conversations are removed or not - we have to associate with each frame
information telling us how to process it.
svn path=/trunk/; revision=2608
2000-11-11 07:48:30 +00:00
|
|
|
* pass, so we figure it out on the first pass.
|
2000-08-24 11:32:09 +00:00
|
|
|
*/
|
|
|
|
|
|
|
|
/* Find out what conversation this packet is part of ... but only
|
2002-08-28 21:04:11 +00:00
|
|
|
* if we have no information on this packet, so find the per-frame
|
2000-08-24 11:32:09 +00:00
|
|
|
* info first.
|
|
|
|
*/
|
|
|
|
|
|
|
|
/* SMTP messages have a simple format ... */
|
|
|
|
|
Remove more "CHECK_DISPLAY_AS_DATA()" calls and "pinfo->current_proto ="
statements.
Move the setting of the Protocol column in various dissectors before
anything is fetched from the packet, and also clear the Info column at
that point in those and some other dissectors, so that if an exception
is thrown, the columns don't reflect the previous protocol.
"Tvbuffify" the Mobile IP dissector (it took old-style arguments, and
then converted them into tvbuff arguments, so there wasn't much to do,
other than to fix references to "fd" to refer to "pinfo->fd").
In the SCTP dissector, refer to the port type and source and destination
ports through "pinfo" rather than through the global "pi", as it's a
tvbuffified dissector.
In the SMTP and Time Protocol dissectors, use "pinfo->match_port" rather
than "TCP_PORT_SMTP" when checking whether the packet is a request or
reply, just in case somebody makes a non-standard port be dissected as
SMTP or Time. (Also, remove a bogus comment from the Time dissector; it
was probably cut-and-pasted from the TFTP dissector.)
svn path=/trunk/; revision=2938
2001-01-25 06:14:14 +00:00
|
|
|
request = pinfo -> destport == pinfo -> match_port;
|
2000-11-12 02:29:20 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Get the first line from the buffer.
|
Remove more "CHECK_DISPLAY_AS_DATA()" calls and "pinfo->current_proto ="
statements.
Move the setting of the Protocol column in various dissectors before
anything is fetched from the packet, and also clear the Info column at
that point in those and some other dissectors, so that if an exception
is thrown, the columns don't reflect the previous protocol.
"Tvbuffify" the Mobile IP dissector (it took old-style arguments, and
then converted them into tvbuff arguments, so there wasn't much to do,
other than to fix references to "fd" to refer to "pinfo->fd").
In the SCTP dissector, refer to the port type and source and destination
ports through "pinfo" rather than through the global "pi", as it's a
tvbuffified dissector.
In the SMTP and Time Protocol dissectors, use "pinfo->match_port" rather
than "TCP_PORT_SMTP" when checking whether the packet is a request or
reply, just in case somebody makes a non-standard port be dissected as
SMTP or Time. (Also, remove a bogus comment from the Time dissector; it
was probably cut-and-pasted from the TFTP dissector.)
svn path=/trunk/; revision=2938
2001-01-25 06:14:14 +00:00
|
|
|
*
|
2002-07-17 06:55:29 +00:00
|
|
|
* Note that "tvb_find_line_end()" will, if it doesn't return
|
|
|
|
* -1, return a value that is not longer than what's in the buffer,
|
|
|
|
* and "tvb_find_line_end()" will always return a value that is not
|
|
|
|
* longer than what's in the buffer, so the "tvb_get_ptr()" call
|
|
|
|
* won't throw an exception.
|
2000-11-12 02:29:20 +00:00
|
|
|
*/
|
2002-07-17 06:55:29 +00:00
|
|
|
linelen = tvb_find_line_end(tvb, offset, -1, &next_offset,
|
|
|
|
smtp_desegment && pinfo->can_desegment);
|
|
|
|
if (linelen == -1) {
|
|
|
|
/*
|
|
|
|
* We didn't find a line ending, and we're doing desegmentation;
|
|
|
|
* tell the TCP dissector where the data for this message starts
|
|
|
|
* in the data it handed us, and tell it we need one more byte
|
|
|
|
* (we may need more, but we'll try again if what we get next
|
|
|
|
* isn't enough), and return.
|
|
|
|
*/
|
|
|
|
pinfo->desegment_offset = offset;
|
|
|
|
pinfo->desegment_len = 1;
|
|
|
|
return;
|
|
|
|
}
|
2000-11-12 02:29:20 +00:00
|
|
|
line = tvb_get_ptr(tvb, offset, linelen);
|
2000-08-19 23:06:51 +00:00
|
|
|
|
2000-08-20 02:16:23 +00:00
|
|
|
frame_data = p_get_proto_data(pinfo->fd, proto_smtp);
|
2000-08-19 23:06:51 +00:00
|
|
|
|
2000-08-24 11:32:09 +00:00
|
|
|
if (!frame_data) {
|
2000-08-19 23:06:51 +00:00
|
|
|
|
2005-02-02 20:07:03 +00:00
|
|
|
conversation = find_conversation(pinfo->fd->num, &pinfo->src, &pinfo->dst, pinfo->ptype,
|
2000-10-21 05:52:28 +00:00
|
|
|
pinfo->srcport, pinfo->destport, 0);
|
2000-08-24 11:32:09 +00:00
|
|
|
if (conversation == NULL) { /* No conversation, create one */
|
2005-02-02 20:07:03 +00:00
|
|
|
conversation = conversation_new(pinfo->fd->num, &pinfo->src, &pinfo->dst, pinfo->ptype,
|
2001-09-03 10:33:12 +00:00
|
|
|
pinfo->srcport, pinfo->destport, 0);
|
2000-08-19 23:06:51 +00:00
|
|
|
|
2000-08-24 11:32:09 +00:00
|
|
|
}
|
2000-08-19 23:06:51 +00:00
|
|
|
|
2001-11-13 04:34:38 +00:00
|
|
|
/*
|
|
|
|
* Is there a request structure attached to this conversation?
|
2000-08-24 11:32:09 +00:00
|
|
|
*/
|
2001-11-13 04:34:38 +00:00
|
|
|
request_val = conversation_get_proto_data(conversation, proto_smtp);
|
2000-08-24 11:32:09 +00:00
|
|
|
|
2001-11-13 04:34:38 +00:00
|
|
|
if (!request_val) {
|
2000-08-24 11:32:09 +00:00
|
|
|
|
2001-11-13 04:34:38 +00:00
|
|
|
/*
|
|
|
|
* No - create one and attach it.
|
|
|
|
*/
|
2005-08-12 10:03:17 +00:00
|
|
|
request_val = se_alloc(sizeof(struct smtp_request_val));
|
Simplify the state machine:
you're either reading commands, or you're reading message data;
if you're reading commands, and you see a DATA command, you
start reading data;
if you're reading data, and you see an EOM, you start reading
commands.
Also, *always* fill in the per-frame data you allocate for a frame, and
*always* attach it to the packet.
The old state machine assumed it was done with the SMTP conversation
once it saw an EOM, and the dissector wouldn't fill in the per-frame
data it'd allocated and attach it to the packet if it thought it was
done with the SMTP conversation. This meant that:
1) the per-frame data allocated for frames following the EOM
(e.g., a QUIT command) would contain random junk for data
such as the packet type;
2) that per-frame data would be re-allocated every time the
frame was looked at, as it wouldn't be attached to the frame,
so you might well get *different* random junk each time the
frame was looked at.
This caused Tethereal and Ethereal to sometimes fail to recognize
commands following the EOM - but it wouldn't *always* fail to do so,
sometimes it'd work and sometimes it wouldn't.
Fix a comment; conversations are *not* removed during filter operations,
and the visited flag is *not* cleared during a filter operation - that's
only true on a *redissection* operation. In any case, given that frames
can, after the initial sequential scan through the capture, be visited
in any order, and visited repeatedly, it's irrelevant whether
conversations are removed or not - we have to associate with each frame
information telling us how to process it.
svn path=/trunk/; revision=2608
2000-11-11 07:48:30 +00:00
|
|
|
request_val->reading_data = FALSE;
|
2000-08-24 11:32:09 +00:00
|
|
|
request_val->crlf_seen = 0;
|
2000-08-19 23:06:51 +00:00
|
|
|
|
2001-11-13 04:34:38 +00:00
|
|
|
conversation_add_proto_data(conversation, proto_smtp, request_val);
|
2000-08-24 11:32:09 +00:00
|
|
|
|
|
|
|
}
|
|
|
|
|
2002-08-28 21:04:11 +00:00
|
|
|
/*
|
2000-08-24 11:32:09 +00:00
|
|
|
* Check whether or not this packet is an end of message packet
|
|
|
|
* We should look for CRLF.CRLF and they may be split.
|
|
|
|
* We have to keep in mind that we may see what we want on
|
|
|
|
* two passes through here ...
|
|
|
|
*/
|
|
|
|
|
Simplify the state machine:
you're either reading commands, or you're reading message data;
if you're reading commands, and you see a DATA command, you
start reading data;
if you're reading data, and you see an EOM, you start reading
commands.
Also, *always* fill in the per-frame data you allocate for a frame, and
*always* attach it to the packet.
The old state machine assumed it was done with the SMTP conversation
once it saw an EOM, and the dissector wouldn't fill in the per-frame
data it'd allocated and attach it to the packet if it thought it was
done with the SMTP conversation. This meant that:
1) the per-frame data allocated for frames following the EOM
(e.g., a QUIT command) would contain random junk for data
such as the packet type;
2) that per-frame data would be re-allocated every time the
frame was looked at, as it wouldn't be attached to the frame,
so you might well get *different* random junk each time the
frame was looked at.
This caused Tethereal and Ethereal to sometimes fail to recognize
commands following the EOM - but it wouldn't *always* fail to do so,
sometimes it'd work and sometimes it wouldn't.
Fix a comment; conversations are *not* removed during filter operations,
and the visited flag is *not* cleared during a filter operation - that's
only true on a *redissection* operation. In any case, given that frames
can, after the initial sequential scan through the capture, be visited
in any order, and visited repeatedly, it's irrelevant whether
conversations are removed or not - we have to associate with each frame
information telling us how to process it.
svn path=/trunk/; revision=2608
2000-11-11 07:48:30 +00:00
|
|
|
if (request_val->reading_data) {
|
2000-08-24 11:32:09 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* The order of these is important ... We want to avoid
|
2002-08-28 21:04:11 +00:00
|
|
|
* cases where there is a CRLF at the end of a packet and a
|
2000-08-24 11:32:09 +00:00
|
|
|
* .CRLF at the begining of the same packet.
|
|
|
|
*/
|
|
|
|
|
2000-11-12 02:29:20 +00:00
|
|
|
if ((request_val->crlf_seen && tvb_strneql(tvb, offset, ".\r\n", 3) == 0) ||
|
|
|
|
tvb_strneql(tvb, offset, "\r\n.\r\n", 5) == 0) {
|
2000-08-24 11:32:09 +00:00
|
|
|
|
Simplify the state machine:
you're either reading commands, or you're reading message data;
if you're reading commands, and you see a DATA command, you
start reading data;
if you're reading data, and you see an EOM, you start reading
commands.
Also, *always* fill in the per-frame data you allocate for a frame, and
*always* attach it to the packet.
The old state machine assumed it was done with the SMTP conversation
once it saw an EOM, and the dissector wouldn't fill in the per-frame
data it'd allocated and attach it to the packet if it thought it was
done with the SMTP conversation. This meant that:
1) the per-frame data allocated for frames following the EOM
(e.g., a QUIT command) would contain random junk for data
such as the packet type;
2) that per-frame data would be re-allocated every time the
frame was looked at, as it wouldn't be attached to the frame,
so you might well get *different* random junk each time the
frame was looked at.
This caused Tethereal and Ethereal to sometimes fail to recognize
commands following the EOM - but it wouldn't *always* fail to do so,
sometimes it'd work and sometimes it wouldn't.
Fix a comment; conversations are *not* removed during filter operations,
and the visited flag is *not* cleared during a filter operation - that's
only true on a *redissection* operation. In any case, given that frames
can, after the initial sequential scan through the capture, be visited
in any order, and visited repeatedly, it's irrelevant whether
conversations are removed or not - we have to associate with each frame
information telling us how to process it.
svn path=/trunk/; revision=2608
2000-11-11 07:48:30 +00:00
|
|
|
eom_seen = TRUE;
|
2000-08-24 11:32:09 +00:00
|
|
|
|
|
|
|
}
|
|
|
|
|
2003-06-10 05:45:33 +00:00
|
|
|
length_remaining = tvb_length_remaining(tvb, offset);
|
|
|
|
if (length_remaining == tvb_reported_length_remaining(tvb, offset) &&
|
|
|
|
tvb_strneql(tvb, offset + length_remaining - 2, "\r\n", 2) == 0) {
|
2000-08-24 11:32:09 +00:00
|
|
|
|
|
|
|
request_val->crlf_seen = 1;
|
|
|
|
|
|
|
|
}
|
|
|
|
else {
|
|
|
|
|
|
|
|
request_val->crlf_seen = 0;
|
|
|
|
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
2002-08-28 21:04:11 +00:00
|
|
|
* OK, Check if we have seen a DATA request. We do it here for
|
2000-08-24 11:32:09 +00:00
|
|
|
* simplicity, but we have to be careful below.
|
|
|
|
*/
|
|
|
|
|
|
|
|
if (request) {
|
|
|
|
|
2005-08-12 10:03:17 +00:00
|
|
|
frame_data = se_alloc(sizeof(struct smtp_proto_data));
|
2000-08-24 11:32:09 +00:00
|
|
|
|
Simplify the state machine:
you're either reading commands, or you're reading message data;
if you're reading commands, and you see a DATA command, you
start reading data;
if you're reading data, and you see an EOM, you start reading
commands.
Also, *always* fill in the per-frame data you allocate for a frame, and
*always* attach it to the packet.
The old state machine assumed it was done with the SMTP conversation
once it saw an EOM, and the dissector wouldn't fill in the per-frame
data it'd allocated and attach it to the packet if it thought it was
done with the SMTP conversation. This meant that:
1) the per-frame data allocated for frames following the EOM
(e.g., a QUIT command) would contain random junk for data
such as the packet type;
2) that per-frame data would be re-allocated every time the
frame was looked at, as it wouldn't be attached to the frame,
so you might well get *different* random junk each time the
frame was looked at.
This caused Tethereal and Ethereal to sometimes fail to recognize
commands following the EOM - but it wouldn't *always* fail to do so,
sometimes it'd work and sometimes it wouldn't.
Fix a comment; conversations are *not* removed during filter operations,
and the visited flag is *not* cleared during a filter operation - that's
only true on a *redissection* operation. In any case, given that frames
can, after the initial sequential scan through the capture, be visited
in any order, and visited repeatedly, it's irrelevant whether
conversations are removed or not - we have to associate with each frame
information telling us how to process it.
svn path=/trunk/; revision=2608
2000-11-11 07:48:30 +00:00
|
|
|
if (request_val->reading_data) {
|
|
|
|
/*
|
|
|
|
* This is message data.
|
|
|
|
*/
|
|
|
|
if (eom_seen) { /* Seen the EOM */
|
|
|
|
/*
|
|
|
|
* EOM.
|
|
|
|
* Everything that comes after it is commands.
|
|
|
|
*
|
|
|
|
* XXX - what if the EOM isn't at the beginning of
|
|
|
|
* the TCP segment? It can occur anywhere....
|
|
|
|
*/
|
|
|
|
frame_data->pdu_type = SMTP_PDU_EOM;
|
|
|
|
request_val->reading_data = FALSE;
|
|
|
|
} else {
|
|
|
|
/*
|
|
|
|
* Message data with no EOM.
|
|
|
|
*/
|
2000-08-24 11:32:09 +00:00
|
|
|
frame_data->pdu_type = SMTP_PDU_MESSAGE;
|
Simplify the state machine:
you're either reading commands, or you're reading message data;
if you're reading commands, and you see a DATA command, you
start reading data;
if you're reading data, and you see an EOM, you start reading
commands.
Also, *always* fill in the per-frame data you allocate for a frame, and
*always* attach it to the packet.
The old state machine assumed it was done with the SMTP conversation
once it saw an EOM, and the dissector wouldn't fill in the per-frame
data it'd allocated and attach it to the packet if it thought it was
done with the SMTP conversation. This meant that:
1) the per-frame data allocated for frames following the EOM
(e.g., a QUIT command) would contain random junk for data
such as the packet type;
2) that per-frame data would be re-allocated every time the
frame was looked at, as it wouldn't be attached to the frame,
so you might well get *different* random junk each time the
frame was looked at.
This caused Tethereal and Ethereal to sometimes fail to recognize
commands following the EOM - but it wouldn't *always* fail to do so,
sometimes it'd work and sometimes it wouldn't.
Fix a comment; conversations are *not* removed during filter operations,
and the visited flag is *not* cleared during a filter operation - that's
only true on a *redissection* operation. In any case, given that frames
can, after the initial sequential scan through the capture, be visited
in any order, and visited repeatedly, it's irrelevant whether
conversations are removed or not - we have to associate with each frame
information telling us how to process it.
svn path=/trunk/; revision=2608
2000-11-11 07:48:30 +00:00
|
|
|
}
|
|
|
|
} else {
|
|
|
|
/*
|
2000-11-12 02:29:20 +00:00
|
|
|
* This is commands - unless the capture started in the
|
|
|
|
* middle of a session, and we're in the middle of data.
|
|
|
|
* To quote RFC 821, "Command codes are four alphabetic
|
|
|
|
* characters"; if we don't see four alphabetic characters
|
|
|
|
* and, if there's anything else in the line, a space, we
|
|
|
|
* assume it's not a command.
|
|
|
|
* (We treat only A-Z and a-z as alphabetic.)
|
Simplify the state machine:
you're either reading commands, or you're reading message data;
if you're reading commands, and you see a DATA command, you
start reading data;
if you're reading data, and you see an EOM, you start reading
commands.
Also, *always* fill in the per-frame data you allocate for a frame, and
*always* attach it to the packet.
The old state machine assumed it was done with the SMTP conversation
once it saw an EOM, and the dissector wouldn't fill in the per-frame
data it'd allocated and attach it to the packet if it thought it was
done with the SMTP conversation. This meant that:
1) the per-frame data allocated for frames following the EOM
(e.g., a QUIT command) would contain random junk for data
such as the packet type;
2) that per-frame data would be re-allocated every time the
frame was looked at, as it wouldn't be attached to the frame,
so you might well get *different* random junk each time the
frame was looked at.
This caused Tethereal and Ethereal to sometimes fail to recognize
commands following the EOM - but it wouldn't *always* fail to do so,
sometimes it'd work and sometimes it wouldn't.
Fix a comment; conversations are *not* removed during filter operations,
and the visited flag is *not* cleared during a filter operation - that's
only true on a *redissection* operation. In any case, given that frames
can, after the initial sequential scan through the capture, be visited
in any order, and visited repeatedly, it's irrelevant whether
conversations are removed or not - we have to associate with each frame
information telling us how to process it.
svn path=/trunk/; revision=2608
2000-11-11 07:48:30 +00:00
|
|
|
*/
|
2000-11-12 02:29:20 +00:00
|
|
|
#define ISALPHA(c) (((c) >= 'A' && (c) <= 'Z') || \
|
|
|
|
((c) >= 'a' && (c) <= 'z'))
|
|
|
|
if (linelen >= 4 && ISALPHA(line[0]) && ISALPHA(line[1]) &&
|
|
|
|
ISALPHA(line[2]) && ISALPHA(line[3]) &&
|
|
|
|
(linelen == 4 || line[4] == ' ')) {
|
2007-03-28 21:55:11 +00:00
|
|
|
if (strncasecmp(line, "DATA", 4) == 0) {
|
2000-11-12 02:29:20 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* DATA command.
|
|
|
|
* This is a command, but everything that comes after it,
|
|
|
|
* until an EOM, is data.
|
|
|
|
*/
|
|
|
|
frame_data->pdu_type = SMTP_PDU_CMD;
|
|
|
|
request_val->reading_data = TRUE;
|
|
|
|
|
|
|
|
} else {
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Regular command.
|
|
|
|
*/
|
|
|
|
frame_data->pdu_type = SMTP_PDU_CMD;
|
|
|
|
|
|
|
|
}
|
|
|
|
} else {
|
2007-03-28 21:55:11 +00:00
|
|
|
if ((linelen >= 7) && line[0] == 'X' && ( (strncasecmp(line, "X-EXPS ", 7) == 0) ||
|
|
|
|
((linelen >=13) && (strncasecmp(line, "X-LINK2STATE ", 13) == 0)) ||
|
|
|
|
((linelen >= 8) && (strncasecmp(line, "XEXCH50 ", 8) == 0)) ))
|
2004-05-16 18:50:40 +00:00
|
|
|
frame_data->pdu_type = SMTP_PDU_CMD;
|
|
|
|
else
|
Simplify the state machine:
you're either reading commands, or you're reading message data;
if you're reading commands, and you see a DATA command, you
start reading data;
if you're reading data, and you see an EOM, you start reading
commands.
Also, *always* fill in the per-frame data you allocate for a frame, and
*always* attach it to the packet.
The old state machine assumed it was done with the SMTP conversation
once it saw an EOM, and the dissector wouldn't fill in the per-frame
data it'd allocated and attach it to the packet if it thought it was
done with the SMTP conversation. This meant that:
1) the per-frame data allocated for frames following the EOM
(e.g., a QUIT command) would contain random junk for data
such as the packet type;
2) that per-frame data would be re-allocated every time the
frame was looked at, as it wouldn't be attached to the frame,
so you might well get *different* random junk each time the
frame was looked at.
This caused Tethereal and Ethereal to sometimes fail to recognize
commands following the EOM - but it wouldn't *always* fail to do so,
sometimes it'd work and sometimes it wouldn't.
Fix a comment; conversations are *not* removed during filter operations,
and the visited flag is *not* cleared during a filter operation - that's
only true on a *redissection* operation. In any case, given that frames
can, after the initial sequential scan through the capture, be visited
in any order, and visited repeatedly, it's irrelevant whether
conversations are removed or not - we have to associate with each frame
information telling us how to process it.
svn path=/trunk/; revision=2608
2000-11-11 07:48:30 +00:00
|
|
|
/*
|
2000-11-12 02:29:20 +00:00
|
|
|
* Assume it's message data.
|
Simplify the state machine:
you're either reading commands, or you're reading message data;
if you're reading commands, and you see a DATA command, you
start reading data;
if you're reading data, and you see an EOM, you start reading
commands.
Also, *always* fill in the per-frame data you allocate for a frame, and
*always* attach it to the packet.
The old state machine assumed it was done with the SMTP conversation
once it saw an EOM, and the dissector wouldn't fill in the per-frame
data it'd allocated and attach it to the packet if it thought it was
done with the SMTP conversation. This meant that:
1) the per-frame data allocated for frames following the EOM
(e.g., a QUIT command) would contain random junk for data
such as the packet type;
2) that per-frame data would be re-allocated every time the
frame was looked at, as it wouldn't be attached to the frame,
so you might well get *different* random junk each time the
frame was looked at.
This caused Tethereal and Ethereal to sometimes fail to recognize
commands following the EOM - but it wouldn't *always* fail to do so,
sometimes it'd work and sometimes it wouldn't.
Fix a comment; conversations are *not* removed during filter operations,
and the visited flag is *not* cleared during a filter operation - that's
only true on a *redissection* operation. In any case, given that frames
can, after the initial sequential scan through the capture, be visited
in any order, and visited repeatedly, it's irrelevant whether
conversations are removed or not - we have to associate with each frame
information telling us how to process it.
svn path=/trunk/; revision=2608
2000-11-11 07:48:30 +00:00
|
|
|
*/
|
2000-08-24 11:32:09 +00:00
|
|
|
|
2000-11-12 02:29:20 +00:00
|
|
|
frame_data->pdu_type = SMTP_PDU_MESSAGE;
|
2000-08-24 11:32:09 +00:00
|
|
|
|
|
|
|
}
|
Simplify the state machine:
you're either reading commands, or you're reading message data;
if you're reading commands, and you see a DATA command, you
start reading data;
if you're reading data, and you see an EOM, you start reading
commands.
Also, *always* fill in the per-frame data you allocate for a frame, and
*always* attach it to the packet.
The old state machine assumed it was done with the SMTP conversation
once it saw an EOM, and the dissector wouldn't fill in the per-frame
data it'd allocated and attach it to the packet if it thought it was
done with the SMTP conversation. This meant that:
1) the per-frame data allocated for frames following the EOM
(e.g., a QUIT command) would contain random junk for data
such as the packet type;
2) that per-frame data would be re-allocated every time the
frame was looked at, as it wouldn't be attached to the frame,
so you might well get *different* random junk each time the
frame was looked at.
This caused Tethereal and Ethereal to sometimes fail to recognize
commands following the EOM - but it wouldn't *always* fail to do so,
sometimes it'd work and sometimes it wouldn't.
Fix a comment; conversations are *not* removed during filter operations,
and the visited flag is *not* cleared during a filter operation - that's
only true on a *redissection* operation. In any case, given that frames
can, after the initial sequential scan through the capture, be visited
in any order, and visited repeatedly, it's irrelevant whether
conversations are removed or not - we have to associate with each frame
information telling us how to process it.
svn path=/trunk/; revision=2608
2000-11-11 07:48:30 +00:00
|
|
|
|
2000-08-24 11:32:09 +00:00
|
|
|
}
|
Simplify the state machine:
you're either reading commands, or you're reading message data;
if you're reading commands, and you see a DATA command, you
start reading data;
if you're reading data, and you see an EOM, you start reading
commands.
Also, *always* fill in the per-frame data you allocate for a frame, and
*always* attach it to the packet.
The old state machine assumed it was done with the SMTP conversation
once it saw an EOM, and the dissector wouldn't fill in the per-frame
data it'd allocated and attach it to the packet if it thought it was
done with the SMTP conversation. This meant that:
1) the per-frame data allocated for frames following the EOM
(e.g., a QUIT command) would contain random junk for data
such as the packet type;
2) that per-frame data would be re-allocated every time the
frame was looked at, as it wouldn't be attached to the frame,
so you might well get *different* random junk each time the
frame was looked at.
This caused Tethereal and Ethereal to sometimes fail to recognize
commands following the EOM - but it wouldn't *always* fail to do so,
sometimes it'd work and sometimes it wouldn't.
Fix a comment; conversations are *not* removed during filter operations,
and the visited flag is *not* cleared during a filter operation - that's
only true on a *redissection* operation. In any case, given that frames
can, after the initial sequential scan through the capture, be visited
in any order, and visited repeatedly, it's irrelevant whether
conversations are removed or not - we have to associate with each frame
information telling us how to process it.
svn path=/trunk/; revision=2608
2000-11-11 07:48:30 +00:00
|
|
|
|
|
|
|
p_add_proto_data(pinfo->fd, proto_smtp, frame_data);
|
|
|
|
|
2000-08-24 11:32:09 +00:00
|
|
|
}
|
2000-08-19 23:06:51 +00:00
|
|
|
}
|
|
|
|
|
2002-08-28 21:04:11 +00:00
|
|
|
/*
|
|
|
|
* From here, we simply add items to the tree and info to the info
|
2000-08-24 11:32:09 +00:00
|
|
|
* fields ...
|
|
|
|
*/
|
|
|
|
|
2001-12-10 00:26:21 +00:00
|
|
|
if (check_col(pinfo->cinfo, COL_PROTOCOL))
|
|
|
|
col_set_str(pinfo->cinfo, COL_PROTOCOL, "SMTP");
|
2000-08-19 23:06:51 +00:00
|
|
|
|
2001-12-10 00:26:21 +00:00
|
|
|
if (check_col(pinfo->cinfo, COL_INFO)) { /* Add the appropriate type here */
|
2000-08-19 23:06:51 +00:00
|
|
|
|
2000-08-24 11:32:09 +00:00
|
|
|
/*
|
|
|
|
* If it is a request, we have to look things up, otherwise, just
|
2002-08-28 21:04:11 +00:00
|
|
|
* display the right things
|
2000-08-24 11:32:09 +00:00
|
|
|
*/
|
|
|
|
|
|
|
|
if (request) {
|
|
|
|
|
|
|
|
/* We must have frame_data here ... */
|
2000-08-19 23:06:51 +00:00
|
|
|
|
2000-08-24 11:32:09 +00:00
|
|
|
switch (frame_data->pdu_type) {
|
|
|
|
case SMTP_PDU_MESSAGE:
|
|
|
|
|
2001-12-10 00:26:21 +00:00
|
|
|
col_set_str(pinfo->cinfo, COL_INFO, "Message Body");
|
2000-08-24 11:32:09 +00:00
|
|
|
break;
|
|
|
|
|
|
|
|
case SMTP_PDU_EOM:
|
|
|
|
|
2001-12-10 00:26:21 +00:00
|
|
|
col_add_fstr(pinfo->cinfo, COL_INFO, "EOM: %s",
|
2000-11-12 02:29:20 +00:00
|
|
|
format_text(line, linelen));
|
2000-08-24 11:32:09 +00:00
|
|
|
break;
|
|
|
|
|
|
|
|
case SMTP_PDU_CMD:
|
|
|
|
|
2001-12-10 00:26:21 +00:00
|
|
|
col_add_fstr(pinfo->cinfo, COL_INFO, "Command: %s",
|
2000-11-12 02:29:20 +00:00
|
|
|
format_text(line, linelen));
|
|
|
|
break;
|
2000-08-24 11:32:09 +00:00
|
|
|
|
|
|
|
}
|
|
|
|
|
|
|
|
}
|
|
|
|
else {
|
|
|
|
|
2001-12-10 00:26:21 +00:00
|
|
|
col_add_fstr(pinfo->cinfo, COL_INFO, "Response: %s",
|
2000-11-12 02:29:20 +00:00
|
|
|
format_text(line, linelen));
|
2000-08-24 11:32:09 +00:00
|
|
|
|
|
|
|
}
|
2000-08-19 23:06:51 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
if (tree) { /* Build the tree info ... */
|
|
|
|
|
2002-01-24 09:20:54 +00:00
|
|
|
ti = proto_tree_add_item(tree, proto_smtp, tvb, offset, -1, FALSE);
|
2000-08-19 23:06:51 +00:00
|
|
|
smtp_tree = proto_item_add_subtree(ti, ett_smtp);
|
|
|
|
if (request) {
|
2000-08-24 11:32:09 +00:00
|
|
|
|
2002-08-28 21:04:11 +00:00
|
|
|
/*
|
2000-08-24 11:32:09 +00:00
|
|
|
* Check out whether or not we can see a command in there ...
|
|
|
|
* What we are looking for is not data_seen and the word DATA
|
|
|
|
* and not eom_seen.
|
|
|
|
*
|
|
|
|
* We will see DATA and request_val->data_seen when we process the
|
|
|
|
* tree view after we have seen a DATA packet when processing
|
|
|
|
* the packet list pane.
|
|
|
|
*
|
|
|
|
* On the first pass, we will not have any info on the packets
|
|
|
|
* On second and subsequent passes, we will.
|
|
|
|
*/
|
|
|
|
|
|
|
|
switch (frame_data->pdu_type) {
|
|
|
|
|
|
|
|
case SMTP_PDU_MESSAGE:
|
|
|
|
|
2000-11-12 02:29:20 +00:00
|
|
|
/*
|
|
|
|
* Message body.
|
|
|
|
* Put its lines into the protocol tree, a line at a time.
|
|
|
|
*/
|
2000-11-13 08:58:17 +00:00
|
|
|
while (tvb_offset_exists(tvb, offset)) {
|
2000-11-12 02:29:20 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Find the end of the line.
|
|
|
|
*/
|
2002-07-17 06:55:29 +00:00
|
|
|
tvb_find_line_end(tvb, offset, -1, &next_offset, FALSE);
|
2000-11-12 02:29:20 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Put this line.
|
|
|
|
*/
|
|
|
|
proto_tree_add_text(smtp_tree, tvb, offset, next_offset - offset,
|
|
|
|
"Message: %s",
|
|
|
|
tvb_format_text(tvb, offset, next_offset - offset));
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Step to the next line.
|
|
|
|
*/
|
|
|
|
offset = next_offset;
|
|
|
|
|
|
|
|
}
|
2000-08-24 11:32:09 +00:00
|
|
|
|
|
|
|
break;
|
|
|
|
|
|
|
|
case SMTP_PDU_EOM:
|
|
|
|
|
2000-11-12 02:29:20 +00:00
|
|
|
/*
|
|
|
|
* End-of-message-body indicator.
|
|
|
|
*
|
|
|
|
* XXX - what about stuff after the first line?
|
|
|
|
* Unlikely, as the client should wait for a response to the
|
|
|
|
* DATA command this terminates before sending another
|
|
|
|
* request, but we should probably handle it.
|
|
|
|
*/
|
2000-11-12 03:13:44 +00:00
|
|
|
proto_tree_add_text(smtp_tree, tvb, offset, linelen,
|
|
|
|
"EOM: %s", format_text(line, linelen));
|
2000-08-24 11:32:09 +00:00
|
|
|
|
|
|
|
break;
|
|
|
|
|
|
|
|
case SMTP_PDU_CMD:
|
2000-11-12 02:29:20 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Command.
|
|
|
|
*
|
|
|
|
* XXX - what about stuff after the first line?
|
|
|
|
* Unlikely, as the client should wait for a response to the
|
|
|
|
* previous command before sending another request, but we
|
|
|
|
* should probably handle it.
|
|
|
|
*/
|
|
|
|
if (linelen >= 4)
|
|
|
|
cmdlen = 4;
|
|
|
|
else
|
|
|
|
cmdlen = linelen;
|
2002-07-14 08:27:34 +00:00
|
|
|
proto_tree_add_boolean_hidden(smtp_tree, hf_smtp_req, tvb,
|
|
|
|
0, 0, TRUE);
|
2003-06-11 18:22:12 +00:00
|
|
|
/*
|
|
|
|
* Put the command line into the protocol tree.
|
|
|
|
*/
|
|
|
|
ti = proto_tree_add_text(smtp_tree, tvb, offset, next_offset - offset,
|
|
|
|
"Command: %s",
|
|
|
|
tvb_format_text(tvb, offset, next_offset - offset));
|
|
|
|
cmdresp_tree = proto_item_add_subtree(ti, ett_smtp_cmdresp);
|
|
|
|
|
|
|
|
proto_tree_add_item(cmdresp_tree, hf_smtp_req_command, tvb,
|
2002-07-14 00:40:07 +00:00
|
|
|
offset, cmdlen, FALSE);
|
2000-11-12 02:29:20 +00:00
|
|
|
if (linelen > 5) {
|
2003-06-11 18:22:12 +00:00
|
|
|
proto_tree_add_item(cmdresp_tree, hf_smtp_req_parameter, tvb,
|
2002-07-14 00:40:07 +00:00
|
|
|
offset + 5, linelen - 5, FALSE);
|
2000-11-12 02:29:20 +00:00
|
|
|
}
|
2000-08-24 11:32:09 +00:00
|
|
|
|
|
|
|
}
|
2000-08-19 23:06:51 +00:00
|
|
|
|
|
|
|
}
|
|
|
|
else {
|
|
|
|
|
2000-11-12 02:29:20 +00:00
|
|
|
/*
|
|
|
|
* Process the response, a line at a time, until we hit a line
|
|
|
|
* that doesn't have a continuation indication on it.
|
|
|
|
*/
|
2002-07-14 08:27:34 +00:00
|
|
|
proto_tree_add_boolean_hidden(smtp_tree, hf_smtp_rsp, tvb,
|
|
|
|
0, 0, TRUE);
|
2000-11-12 02:29:20 +00:00
|
|
|
|
2000-11-13 08:58:17 +00:00
|
|
|
while (tvb_offset_exists(tvb, offset)) {
|
2000-08-19 23:06:51 +00:00
|
|
|
|
2000-11-12 02:29:20 +00:00
|
|
|
/*
|
|
|
|
* Find the end of the line.
|
|
|
|
*/
|
2002-07-17 06:55:29 +00:00
|
|
|
linelen = tvb_find_line_end(tvb, offset, -1, &next_offset, FALSE);
|
2000-08-19 23:06:51 +00:00
|
|
|
|
2003-06-11 18:22:12 +00:00
|
|
|
/*
|
|
|
|
* Put it into the protocol tree.
|
|
|
|
*/
|
|
|
|
ti = proto_tree_add_text(smtp_tree, tvb, offset,
|
|
|
|
next_offset - offset, "Response: %s",
|
|
|
|
tvb_format_text(tvb, offset,
|
|
|
|
next_offset - offset));
|
|
|
|
cmdresp_tree = proto_item_add_subtree(ti, ett_smtp_cmdresp);
|
|
|
|
|
2000-11-12 02:29:20 +00:00
|
|
|
/*
|
|
|
|
* Is it a continuation line?
|
|
|
|
*/
|
|
|
|
is_continuation_line =
|
|
|
|
(linelen >= 4 && tvb_get_guint8(tvb, offset + 3) == '-');
|
2000-08-19 23:06:51 +00:00
|
|
|
|
2000-11-12 02:29:20 +00:00
|
|
|
/*
|
2003-06-11 18:22:12 +00:00
|
|
|
* Put the response code and parameters into the protocol tree.
|
2000-11-12 02:29:20 +00:00
|
|
|
*/
|
2002-07-14 00:40:07 +00:00
|
|
|
line = tvb_get_ptr(tvb, offset, linelen);
|
|
|
|
if (linelen >= 3 && isdigit(line[0]) && isdigit(line[1])
|
|
|
|
&& isdigit(line[2])) {
|
|
|
|
/*
|
|
|
|
* We have a 3-digit response code.
|
|
|
|
*/
|
|
|
|
code = (line[0] - '0')*100 + (line[1] - '0')*10 + (line[2] - '0');
|
2003-06-11 18:22:12 +00:00
|
|
|
proto_tree_add_uint(cmdresp_tree, hf_smtp_rsp_code, tvb, offset, 3,
|
2002-07-14 00:40:07 +00:00
|
|
|
code);
|
|
|
|
|
|
|
|
if (linelen >= 4) {
|
2003-06-11 18:22:12 +00:00
|
|
|
proto_tree_add_item(cmdresp_tree, hf_smtp_rsp_parameter, tvb,
|
2002-07-14 00:40:07 +00:00
|
|
|
offset + 4, linelen - 4, FALSE);
|
|
|
|
}
|
2000-11-12 02:29:20 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Step past this line.
|
|
|
|
*/
|
|
|
|
offset = next_offset;
|
2000-08-19 23:06:51 +00:00
|
|
|
|
2000-11-12 02:29:20 +00:00
|
|
|
/*
|
|
|
|
* If it's not a continuation line, quit.
|
|
|
|
*/
|
|
|
|
if (!is_continuation_line)
|
|
|
|
break;
|
|
|
|
|
|
|
|
}
|
2002-08-28 21:04:11 +00:00
|
|
|
|
2000-08-19 23:06:51 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Register all the bits needed by the filtering engine */
|
|
|
|
|
|
|
|
void
|
|
|
|
proto_register_smtp(void)
|
|
|
|
{
|
|
|
|
static hf_register_info hf[] = {
|
|
|
|
{ &hf_smtp_req,
|
2001-06-18 02:18:27 +00:00
|
|
|
{ "Request", "smtp.req", FT_BOOLEAN, BASE_NONE, NULL, 0x0, "", HFILL }},
|
2000-08-19 23:06:51 +00:00
|
|
|
|
|
|
|
{ &hf_smtp_rsp,
|
2001-06-18 02:18:27 +00:00
|
|
|
{ "Response", "smtp.rsp", FT_BOOLEAN, BASE_NONE, NULL, 0x0, "", HFILL }},
|
2002-07-14 00:40:07 +00:00
|
|
|
|
|
|
|
{ &hf_smtp_req_command,
|
|
|
|
{ "Command", "smtp.req.command", FT_STRING, BASE_NONE, NULL, 0x0,
|
|
|
|
"", HFILL }},
|
|
|
|
|
|
|
|
{ &hf_smtp_req_parameter,
|
|
|
|
{ "Request parameter", "smtp.req.parameter", FT_STRING, BASE_NONE, NULL, 0x0,
|
|
|
|
"", HFILL }},
|
|
|
|
|
|
|
|
{ &hf_smtp_rsp_code,
|
2002-07-15 09:40:20 +00:00
|
|
|
{ "Response code", "smtp.response.code", FT_UINT32, BASE_DEC, NULL, 0x0,
|
2002-07-14 00:40:07 +00:00
|
|
|
"", HFILL }},
|
|
|
|
|
|
|
|
{ &hf_smtp_rsp_parameter,
|
|
|
|
{ "Response parameter", "smtp.rsp.parameter", FT_STRING, BASE_NONE, NULL, 0x0,
|
|
|
|
"", HFILL }}
|
2000-08-19 23:06:51 +00:00
|
|
|
};
|
|
|
|
static gint *ett[] = {
|
2003-06-11 18:22:12 +00:00
|
|
|
&ett_smtp,
|
|
|
|
&ett_smtp_cmdresp,
|
2000-08-19 23:06:51 +00:00
|
|
|
};
|
2002-07-17 06:55:29 +00:00
|
|
|
module_t *smtp_module;
|
2000-08-19 23:06:51 +00:00
|
|
|
|
|
|
|
|
2001-01-03 06:56:03 +00:00
|
|
|
proto_smtp = proto_register_protocol("Simple Mail Transfer Protocol",
|
|
|
|
"SMTP", "smtp");
|
2000-08-19 23:06:51 +00:00
|
|
|
|
|
|
|
proto_register_field_array(proto_smtp, hf, array_length(hf));
|
|
|
|
proto_register_subtree_array(ett, array_length(ett));
|
|
|
|
|
2006-10-25 16:46:27 +00:00
|
|
|
/* Allow dissector to find be found by name. */
|
|
|
|
register_dissector("smtp", dissect_smtp, proto_smtp);
|
|
|
|
|
|
|
|
/* Preferences */
|
2002-07-17 06:55:29 +00:00
|
|
|
smtp_module = prefs_register_protocol(proto_smtp, NULL);
|
|
|
|
prefs_register_bool_preference(smtp_module, "desegment_lines",
|
2004-08-21 09:02:52 +00:00
|
|
|
"Reassemble SMTP command and response lines\nspanning multiple TCP segments",
|
|
|
|
"Whether the SMTP dissector should reassemble command and response lines spanning multiple TCP segments."
|
|
|
|
" To use this option, you must also enable \"Allow subdissectors to reassemble TCP streams\" in the TCP protocol settings.",
|
2002-07-17 06:55:29 +00:00
|
|
|
&smtp_desegment);
|
2000-08-19 23:06:51 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/* The registration hand-off routine */
|
|
|
|
void
|
|
|
|
proto_reg_handoff_smtp(void)
|
|
|
|
{
|
2003-09-16 17:42:01 +00:00
|
|
|
dissector_handle_t smtp_handle;
|
2000-08-19 23:06:51 +00:00
|
|
|
|
2003-09-16 17:42:01 +00:00
|
|
|
smtp_handle = create_dissector_handle(dissect_smtp, proto_smtp);
|
|
|
|
dissector_add("tcp.port", TCP_PORT_SMTP, smtp_handle);
|
2000-08-19 23:06:51 +00:00
|
|
|
}
|