1 files changed, 85 insertions, 0 deletions
diff --git a/tests/emails/legacy/COPYING b/tests/emails/legacy/COPYING
new file mode 100644
index 0000000..c9ad7e3
--- /dev/null
+++ b/tests/emails/legacy/COPYING
@@ -0,0 +1,85 @@
+These test files are Copyright © 2010 Hunny Software, Inc. 
+Samples obtained from http://www.hunnysoft.com/mime/samples/samples.zip
+Details at https://www.hunnysoft.com/mime/samples/index.html
+
+readme.txt
+-----
+
+The files in this directory that match the pattern m*.txt are sample
+messages in MIME format from common email Mail User Agents (MUAs).
+
+I created these samples mainly for the purpose of testing my own MIME
+implementation, particularly for testing the decoding of encoded text
+in the headers (RFC 2047) and for the extraction of attachments (not
+covered by any standard).
+
+I used four different MUAs to create the messages.  You can determine which
+MUA was used by looking at the file name.  The breakdown is:
+
+   m0*.txt  -- Microsoft Outlook 00
+   m1*.txt  -- Netscape Communicator 4.7
+   m2*.txt  -- Qualcomm Eudora 4.2
+   m3*.txt  -- PINE (Linux)
+
+Of course, you can also look at the headers of the message to determine the
+MUA.
+
+If you want to contribute to this collection of samples, please do send
+your contributions.  I will evaluate the contributions for inclusion in
+this collection.  The evaluation criteria will include:
+
+  * Is the MUA a mainstream MUA (not some obscure, rare MUA)?
+
+  * Are the messages short?
+
+  * Are the messages useful for testing?
+
+  * Are the messages genuine?  Messages that have been through a relaying
+    SMTP server might have been modified.  This might not disqualify a
+    sample message, as it probably still has value for interoperability
+    testing.
+
+When you send messages, please zip them or tar them, so that they won't be
+changed as they pass through the mail system.  If I include your messages,
+I will put your name on a list of contributors, unless you prefer otherwise.
+
+I am also considering creating a separate collection of messages designed
+to stress test MIME implementations.  So, if you have any good examples of
+bad messages (but not bad examples of good messages :-), feel free to send
+them.
+
+Not all the messages are correct to the MIME standard.  However, since
+these messages are from popular MUAs, they can be useful for
+interoperability testing.  Please, if you are creating messages, read and
+understand the standards documents, rather than imitate what you see in
+these messages!
+
+I have included the files that were used for creating the attachments,
+so you can test that you have successfully decoded the attachments.
+
+I have also included a simple Java program that I used for creating these
+samples.  This program, SmtpServer.java, is a simple SMTP server that will
+receive the message directly from you MUA.  This is important, because if
+you just route the message through your normal SMTP server, the server
+might make changes to the message.  For example, it seems to be common for
+some servers to convert quoted-printable encoded text to 8-bit text.[1]
+This SMTP server program records the entire SMTP client/server dialog,
+which is great if you are trying to debug your mail system, but it also
+means that you will have to edit the output of the program to get just
+the email message.
+
+The URL for this collection of messages is
+<http://hunnysoft.com/mime/samples.zip>
+
+
+
+
+
+----------------------------------------------------
+
+[1] I don't like the fact that this happens, but that's life.  I guess the
+MTA thinks that since it can handle 8-bit text, that quoted-printable
+encoding is not necessary.  However, quoted-printable also makes long lines
+into short lines, which is something other than converting to 8-bit
+characters.  In general, I think end-to-end transparency is a good thing;
+anything that interferes with transparency should be avoided.