Can the drop folder process RFC 822 compliant EML files?


Article ID: 159939


Updated On:


Data Loss Prevention Enforce


Can you use RFC  822 compliant EML files in the drop folder for testing?


All EML files are RFC 822 compliant.

RFC 822 EML files can be used for testing within the drop folder. However, since we use the drop folder as a test bed there is no written guarantee that this is 100% compliant. So, if test cases are manually generated outside of Outlook Express, there might be corner cases that do not work as expected.

Testing via actual email is not affected and should work as expected.


When creating EML files for testing, make sure that both sender and recipients fields are filled in. Otherwise, the message will fail the L7 filtering test and get discarded.  If you use Outlook Express to create the EML files, it's a good idea to hit the "resolve recipients" button (or alt+k) before saving the file. This will guarantee that the To: field is filled correctly.

For reference, see

The basic format of Internet e-mail is defined in RFC 2822, which is an updated version of RFC 822. These standards specify the familiar formats for text e-mail headers and body and rules pertaining to commonly used header fields such as "To:", "Subject:", "From:", and "Date:". MIME defines a collection of e-mail headers for specifying additional attributes of a message including content type, and defines a set of transfer encodings which can be used to represent 8-bit binary data using characters from the 7-bit ASCII character set. MIME also specifies rules for encoding non-ASCII characters in e-mail message headers, such as "Subject:", allowing these header fields to contain non-English characters.

MIME is extensible. Its definition includes a method to register new content types and other MIME attribute values.

The goals of the MIME definition included requiring no changes to pre-existing e-mail servers, and allowing plain text e-mail to function in both directions with pre-existing clients. These goals are achieved by using additional RFC 822-style headers for all MIME message attributes and by making the MIME headers optional with default values ensuring a non-MIME message is interpreted correctly by a MIME-capable client. In addition, a simple MIME text message is likely to be interpreted correctly by a non-MIME client although it has e-mail headers the non-MIME client won't know how to interpret. Similarly, if the quoted printable transfer encoding . . . is used, the ASCII part of the message will be intelligible to users with non-MIME clients.