Subject: Quizzic: Spam equivalent to EICAR test virus proposal.

From: "Matthew Elvey (FM)" <[email-masked]>
Date: Mon, 30 Jun 2003 15:08:13 -0700

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. [email-masked]) or sending 
domain [email-masked] 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.)

Date: Mon, 30 Jun 2003 15:08:13 -0700
From: "Matthew Elvey (FM)" <[email-masked]>
To: [email-masked]
Subject: Quizzic: Spam equivalent to EICAR test virus proposal.
Sender: [email-masked]

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. [email-masked]) or sending 
domain [email-masked] 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.)

Date: Sun, 29 Jun 2003 16:53:08 -0400 (EDT)
From: Ted Garrett <[email-masked]>
Subject: Sieve suddenly missinterprets X-Spam-Status
To: Sieve Mailing List <[email-masked]>
Importance: Normal
Sender: [email-masked]

For the longest time, the first rule in my active sieve script was -

if anyof (header :contains "X-Spam-Status" "Yes") {
    fileinto  INBOX.Spam.Assassin;
    stop;
}

And this worked just fine.  Suddenly about a week ago, sieve started
pouring ALL of my mail into the spam assassin mailbox.  In order to get it
to work properly again, I had to delete the rule, save a new script,
delete the original script, add rules to the new script, then add the old
rule back into the new script (not as the first rule) and move it up from
the bottom of the script to the top.

I guess I'm looking for whether anyone else has seen anything this strange
or not.

Thanks!

From: "hm" <[email-masked]>
To: <[email-masked]>
Subject: changing the address from a redirect of sieve
Date: Sat, 21 Jun 2003 21:26:13 +0200
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_01E7_01C3383B.BDACCBF0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hello,

I like to know howto change the address when I redirect an email, of =
course the
sender email address is like cyrus@host; but I want to have =
myname@specialhost

Thanx ahead...

------=_NextPart_000_01E7_01C3383B.BDACCBF0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2600.0" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>
<DIV><FONT face=3DArial size=3D2>Hello,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>I like to know howto change the address =
when I=20
redirect an email, of course the</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>sender email address is like <A=20
href=3D"mailto:cyrus@host">cyrus@host</A>; but I want to have <A=20
href=3D"mailto:myname@specialhost">myname@specialhost</A></FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Thanx=20
ahead...</FONT></DIV></FONT></DIV></BODY></HTML>

------=_NextPart_000_01E7_01C3383B.BDACCBF0--

Date: Thu, 12 Jun 2003 09:04:40 -0700 (PDT)
From: [email-masked]
Subject: Re: vacation extension: Needs to say something about message generation.
To: Marc Mutz <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

> IMO, the vacation draft needs to say that the vacation response
> generation mechanism MUST take charsets and content-types into account
> even if the :mime parameter is not given.

> Implementations SHOULD choose a fitting charset and recode the text
> given in the script (in UTF-8) into the chosen charset and apply a
> suitable CTE.

I have no problem with suggesting this, but I don't think it rises to the level
of a SHOULD. I think we need to stop short of any sort of requirement (and
SHOULD is a form of requirement) that stuff be recoded from UTF-8 into other
charsets. Sending UTF-8 without any hint  of recoding needs to be an acceptable
option.

> At the very minimum, implementations should add
>  Content-Type: text/plain; charset=utf-8
>  Content-Transfer-Encoding: 8bit
>  MIME-version: 1.0
> to the header of the generated message.

Reminding people that appropriate MIME labelling MUST be used for
whatever charset is generated is a reasonable thing to do, of course.

> This might sound obvious, but we just encountered a vacation response
> message that had no MIME headers whatsoever, but contained 8bit-encoded
> UTF-8 text.

Sure. But we already have rules that say such messages are illegal,
regardless of whether or not they are a vacation response. It is far from
clear that anything we say will prevent this.

				Ned

From: Marc Mutz <[email-masked]>
Organization: KDE
To: [email-masked]
Subject: vacation extension: Needs to say something about message generation.
Date: Thu, 12 Jun 2003 15:31:08 +0200
Sender: [email-masked]

--Boundary-02=_cCI6+76gU4UQGyW
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Hi!

IMO, the vacation draft needs to say that the vacation response=20
generation mechanism MUST take charsets and content-types into account=20
even if the :mime parameter is not given.

Implementations SHOULD choose a fitting charset and recode the text=20
given in the script (in UTF-8) into the chosen charset and apply a=20
suitable CTE. At the very minimum, implementations should add
 Content-Type: text/plain; charset=3Dutf-8
 Content-Transfer-Encoding: 8bit
 MIME-version: 1.0
to the header of the generated message.

This might sound obvious, but we just encountered a vacation response=20
message that had no MIME headers whatsoever, but contained 8bit-encoded=20
UTF-8 text.

Marc

=2D-=20
Mutig warf sich die kleine =DCberwachungskamera zwischen T=E4ter und Opfer!
                                        --Rena Tangens / FoeBuD e.V.

--Boundary-02=_cCI6+76gU4UQGyW
Content-Type: application/pgp-signature
Content-Description: signature

--Boundary-02=_cCI6+76gU4UQGyW--

Date: Wed, 28 May 2003 17:39:23 -0400
From: The IESG <[email-masked]>
Subject: Protocol Action: Sieve -- Subaddress Extension to Proposed 	   Standard
To: IETF-Announce: ;
Cc: RFC Editor <[email-masked]>, Internet Architecture Board <[email-masked]>
Spam-test: False ; 1.1 / 4.5
Sender: [email-masked]

The IESG has approved the Internet-Draft 'Sieve -- Subaddress 
Extension' <draft-murchison-sieve-subaddress-06.txt> as a Proposed 
Standard. This has been reviewed in the IETF but is not the product of 
an IETF Working Group. The IESG contact persons are Ned Freed and Ted 
Hardie.

 Technical Summary
   
 On email systems that allow for "subaddressing" or "detailed
 addressing" (eg, "[email-masked]"), it is sometimes desirable
 to make comparisons against these sub-parts of addresses. This draft
 defines an extension to the Sieve mail filtering language that 
 allows users to compare against the user and detail parts of an 
 address.
   
 Working Group Summary
   
 This document is an extension to the sieve mail filtering language
 defined in RFC 3028. There are already several implementations of
 this extension.
   
 Protocol Quality
   
 Ned Freed reviewed the specification for the IESG.

 RFC Editor note

 Please change the title of this document to "Sieve Email 
 Filtering -- Subaddress Extension" to avoid confusion with other 
 uses of the term "subaddressing"

 In the first paragraph of the introduction, the phrase "set of 
 messages" needs to be changed to "set of mailboxes".