This is a static archive of our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

check RFC compliance with Wireshark / tcpdump ?

0

hi guys,

is Wireshark / tcpdump able to detect / mark non RFC compliant mails ??

I'm asking because the following document is stating that:

To verify if the mail is corrupted it is advised to contact Technical support to enable RAW mail logging and create a network capture with tcpdump.

https://support.symantec.com/en_US/article.TECH184271.html

Thank you in advance !

BR ADAM

asked 05 Jan '16, 06:15

adasko's gravatar image

adasko
86343842
accept rate: 0%


One Answer:

1

No: Wireshark does not check RFC compliance for emails (altho a dissection of same might fail).

(I expect that tcpdump (a completely different program than wireshark) also does not check for RFC compliance, but I don't actually know that.

answered 05 Jan '16, 08:11

Bill%20Meier's gravatar image

Bill Meier ♦♦
3.2k1850
accept rate: 17%

1

I would understand that requirement in such a way that Symantec just wants to have a bit-verbatim capture of the complete SMTP protocol exchange related to reception of the e-mail message in question, not that they would themselves use Wireshark to automatically verify the RFC compliance.

For that purpose, Wireshark (actually, dumpcap) is equally good as the tcpdump, as both capture network traffic and store it into a pcap or pcapng organised file.

If I read the article properly, Symantec wants both the pcap and their internal application log of the same transaction, and to switch the logging mode to "raw", you have to contact their support staff.

As @Bill Meier has stated, if Wireshark dissection of an e-mail message from the SMTP capture fails, it is quite likely that the message breaks some RFC in some way (assuming there is no packet loss); however, the fact that the dissection succeeds does not imply that there is no breach of some of the related RFCs.

As with recent hardware, capturing of TCP sessions may be affected by TCP offloading, I'd recommend to search this site for "tcp chimney" and "tcp offloading" keywords before attempting the capture.

(05 Jan '16, 14:45) sindy

@Sindy I see your points.

So I would have to capture on their server on the receiving interface, correct ?

I'm partially aware of tcp chimney / offloading (e.g. checksum errors ) but other than that would it be a general rule to switch off this features for the time when doing the capture or is it "enough" to keep in the back of the head that it can cause errors but in fact this are not real errors ?

thank you

BR Adam

(06 Jan '16, 03:36) adasko
1

Adam,

from the description the role of "your" and "their" is not really clear.

I've understood it in such a way that you are running a Symantec software product at your own hardware (which may be a virtual one). If so, it seems that to get support from Symantec, you have to capture on your server running their product using tcpdump (not available at Windows) or Wireshark (available almost at all OSes) and ask their support to activate/tell you how to activate the RAW logging, whatever it means, before starting the capture and sending a test e-mail message whose processing should fail the way you've encountered.

As for the offloading: its purpose is to save the CPU power for better purposes, and there is a significant difference between "checksum offloading" and other types of offloading:

  • you don't need to bother about checksum offloading if you keep in back of your head that you can ignore incorrect checksums of sent packets because they haven't been calculated yet at the moment when Wireshark has got the packet, while incorrect checksums of packets not sent by the card on which you run the capture indicate a trouble.

  • full tcp offloading prevents Wireshark from seeing the TCP session at all, except its establishment phase, so if your network adapter supports this feature and you want to capture TCP, you must deactivate the feature in order to be able to make a useful capture. The price you pay is the CPU power assigned to TCP handling, so it is up to you whether you'll keep the feature disabled systematically or only deactivate it while troubleshooting.

To eventually troubleshoot the TCP offloading itself (which could theoretically also be related to your trouble) you must capture somewhere else (search this site for capturing using hubs, taps, monitoring ports of switches...). I mean, if you deactivate TCP offloading so that you could capture, and your original issue disappears, then there likely is an issue with the TCP offloading.

(06 Jan '16, 03:57) sindy

Hi Sindy,

sorry for the confusion. Yes, we have their product (Symantec Encryption Management Server) installed on a virtual machine (VMware).

As for the offloading: its purpose is to save the CPU power for better purposes, and there is a significant difference between "checksum offloading"

So in general, the idea behind offloading is to save hosts CPU, correct?

Please tell only, if it's a VM do i have to check the NIC settings of the VM itself or the VMware host's physical interface or both ?

BR

Adam

(06 Jan '16, 04:59) adasko

if it's a VM do i have to check the NIC settings of the VM itself or the VMware host's physical interface or both?

Only of one of them - the one at which you capture using Wireshark. I'd suppose no offload feature on a virtual machine as it is not much logical but better check.

Off topic: the "thumbs up" icon next to the Answer marks the answer as "nice" or "useful" and is available to any user, but it doesn't change the Question status. To mark the Answer as "accepted" so that the Question appears as "usefully answered" (i.e. green) in the list, you have to use the checkmark icon, and you (the issuer of the question) are the only one who can do it. I have no idea why it is made so complex but it is.

(06 Jan '16, 05:40) sindy