Quizzic: Spam equivalent to EICAR test virus proposal.

Preamble:
=======
Sending this to this list, as it relates directly to the charter 
(filtering), though it's not Sieve related, which has been the focus of 
the list for a while.  I haven't posted this anywhere else yet, and 
figure this smallish group could provide some initial feedback to see if 
this idea has legs and should become an internet-draft, if I'm 
reinventing the wheel, or what.  To start off with, a few I do/don't 
think this is needed (because ___) comments would be appreciated.  I've 
wanted something like this to exist several times, myself.

Rationale:
=======

I think a standard equivalent to the EICAR test virus for spam is 
needed, and would make a useful RFC/'net standard. (The EICAR test 
provides a safe, easy way to test whether your anti-virus software is 
doing its job.   If the antivirus software on your computer is working, 
it should detect it as the EICAR Test Virus.  Of course, it's not a 
virus but instead a harmless 70 byte file that most or all antivirus 
software programs are supposed to detect for testing purposes only. See 
http://www.its.uiowa.edu/cs/helpdesk/virus/virusfaq/eicar.htm)
For example, if I want to test that some kind of anti-spam system is 
working, it would be useful to be able to send a message and expect it 
to be treated as spam without sending something that a human would think 
was spam.
It would be useful for testing and debugging spam-reporting and 
abuse-incident-handling systems.
It could be used to detect the presence of a challenge-response system 
(unless the system didn't want to be detected) if a prescribed response 
was specified for such systems.  List managers and list management 
software could use this info productively.
It could be useful for populating a whitelist (just send a Quizzic email 
to everyone in your address book using a specified SMTP server that 
intercepts the email.  If the users messes up, Quizzic will limit the 
damage.)
Or I want to test a system in a way that hopefully won't bother anyone 
even if it malfunctions.
Proposal:
======

I think a specific string in the subject would to the trick best, such 
as the first 9 characters of the subject must be "ADV:QZWK:"
Subject: ADV:QZWK:followed by any text. N'importe quoi.

Requiring a specific sender (e.g. spamtest(_at_)example(_dot_)com) or sending 
domain anything(_at_)ADVQZWK(_dot_)com would be alternatives.
These would be useful for systems that don't look at the body of a 
message, such as domain-based or address-based blocklists.
Or perhaps a single line in the (plain text)body with prescribed text :
ADV:QZWK:Body This is a test email. Blah blah.

All compliant antispam systems MUST consider it as spam. 

Perhaps more specific instructions could be given.

Perhaps challenge-response systems would get more specific instructions:
"ADV:QZWK:Challenge:" indicates that the message SHOULD/MUST be 
challenged by a RFC-compliant challenge-response system, even if the 
mail would normally be let through, if the body is compliant+.
"ADV:QZWK:Grey:" indicates a system MUST file it in a [held mail/grey 
mail/probable spam/uncertain] category if the system supports such a 
category and the body is compliant+.
"ADV:QZWK:NoChallenge:" indicates a challenge-response system MUST NOT 
challenge it and should/must file it in /dev/null.
Compliant systems MUST send the strings captialized as specified, MUST 
recognize the strings if captialized as specified, and MAY perform 
case-insensitive matches.
Abuse response systems SHOULD/MUST NOT treat abuse reports of messages 
reported that are in compliance with this document as abuse (unless they 
come in such volume that they are a DoS attack).
All test spam messages sent must be at least minimally compliant with 
this spec.
+There should  to be limits to help avert abuse of these options.  
Perhaps the subject and body of the message should be limited to, say,  
80 characters of (plain) text each, for these two options.
Notes:
====
I chose ADV:QZWK: as a short sequence unlikely to be seen at random, 
ever.  ADV: to take advantage of the existing convention that this 
indicates spam, and QZWK (pronounced Quizzic ?) as some of the least 
common letters in language.  Hopefully they aren't common or missing 
from any commonly used foreign keyboards.  As a domain, it isn't taken 
(don't be a jerk!).
Anyway, this formatted more as a stream of consciousness, but please 
provide feedback.
This RFC should be generalized to apply to any applicable system (SMS, 
IM, etc.)