Subject: :binary in draft-degener-sieve-body-02.txt

From: Ken Murchison <[email-masked]>
Date: Wed, 23 Jun 2004 14:46:48 -0400

What is the intended use of :binary?  If its for checking virus 
signatures, isn't this better suited to virustest?  The reason I ask is 
that I've spent the last few days adding body support to Cyrus Sieve
and implementing :binary as its currently documented is non-trivial and 
potentially expensive in both memory and CPU (especially if coupled with 
:regex).

So, is :binary really necessary, and if so, can it be moved to a 
separate extension (e.g. 'binary' or 'body-binary') so that it isn't a 
requirement for implementing text-based body tests?

-- 
Kenneth Murchison     Oceana Matrix Ltd.
Software Engineer     21 Princeton Place
716-662-8973 x26      Orchard Park, NY 14127
--PGP Public Key--    http://www.oceana.com/~ken/ksm.pgp

---

From: Jutta Degener <[email-masked]>
Date: Wed, 23 Jun 2004 13:20:34 -0700

> signatures, isn't this better suited to virustest?

The "virustest" predicate operates on a much higher level
of abstraction than :binary.  Obviously, if all you want to do
is test against viruses, and you have a working, well-maintained
virustest support from your ISP, you won't need :binary.

But apart from making up for insufficient or outdated virus-
and spam-shielding, :binary also has value as a catch-all tool
that works even in the presence of bad or unkown charsets or
badly used or specified MIME types.

For example, it can look into a WAV file and distinguish
WAV-encoded GSM from WAV-encoded PCM, and feed to a telephony
gateway only those formats the gateway is known to be able
to decode.  It can read version numbers of software formats,
or become an ad-hoc way of looking into "wrapper" formats.

> The reason I ask is 

I've implemented :binary, too, and it didn't seem like a big
overhead compared to, say, a charset conversion via iconv that
the other options ask you to do to arrive at UTF-8.  Do you
remember what specifically got in your way?

> requirement for implementing text-based body tests?

Sure, we can do that.  This is just a draft.  But I'd like to
gather a little more experience with the implementations before 
aking a decision; maybe nobody ever uses it (I mean, it's not
like the format really comes naturally to users...), and we can
just drop it entirely.  Or maybe it'll be so overwhelmingly 
useful that farming it out doesn't make sense after all.

Jutta <[email-masked]>

---

From: Ken Murchison <[email-masked]>
Date: Wed, 23 Jun 2004 16:29:27 -0400

> remember what specifically got in your way?

Nothing earth shattering, but the [decoded] body part needs to be 
expanded into space-separated hex (a 3x increase in size) in order to do 
the match.  This *might* be avoidable by doing the "hex dump" on the fly 
for :contains and possibly :matches, but is necessary for :regex unless 
using a home-grown regex function/library.

I thought about "decoding" the ascii-hex pattern and then comparing 
against the content, but that prohibits patterns such as "3c 4?"  Or are 
patterns such as this prohibited (special pattern-matches chars can't be 
used as a placeholder for a nibble)?

Date: Wed, 23 Jun 2004 16:29:27 -0400
From: Ken Murchison <[email-masked]>
Organization: Oceana Matrix Ltd.
To: Jutta Degener <[email-masked]>
CC: IETF MTA Filters List <[email-masked]>
Subject: Re: :binary in draft-degener-sieve-body-02.txt
Sender: [email-masked]

> remember what specifically got in your way?

Nothing earth shattering, but the [decoded] body part needs to be 
expanded into space-separated hex (a 3x increase in size) in order to do 
the match.  This *might* be avoidable by doing the "hex dump" on the fly 
for :contains and possibly :matches, but is necessary for :regex unless 
using a home-grown regex function/library.

I thought about "decoding" the ascii-hex pattern and then comparing 
against the content, but that prohibits patterns such as "3c 4?"  Or are 
patterns such as this prohibited (special pattern-matches chars can't be 
used as a placeholder for a nibble)?

Date: Wed, 23 Jun 2004 13:20:34 -0700
From: Jutta Degener <[email-masked]>
To: Ken Murchison <[email-masked]>
Cc: IETF MTA Filters List <[email-masked]>
Subject: Re: :binary in draft-degener-sieve-body-02.txt
Sender: [email-masked]

Date: Wed, 23 Jun 2004 14:46:48 -0400
From: Ken Murchison <[email-masked]>
Organization: Oceana Matrix Ltd.
To: IETF MTA Filters List <[email-masked]>
Subject: :binary in draft-degener-sieve-body-02.txt
Sender: [email-masked]

From: Arnt Gulbrandsen <[email-masked]>
To: "Rolf E. Sonneveld" <[email-masked]>
Subject: Re: Question on separators in localpart
Cc: [email-masked]
Date: Tue, 22 Jun 2004 10:35:13 +0200
Sender: [email-masked]

Rolf E. Sonneveld writes:
> I believe the 'underscore' will possibly cause other problems (e.g. 
> when gatewayed into the X.400 world), so the question is mainly 
> whether the use of either format 1 (dot) or format 2 (hyphen) will 
> cause any possible problems for SIEVE scripts?

No.

Btw, the underscore may cause some problems when e-mail addresses are 
read over the phone. People are less used to underscores in email 
addresses than to hyphens or dots.

Arnt

Date: Mon, 21 Jun 2004 16:14:57 -0400 (EDT)
From: Rob Siemborski <[email-masked]>
To: Rob Mueller <[email-masked]>
cc: [email-masked]
Subject: Re: State of notify draft...
Sender: [email-masked]

On Mon, 21 Jun 2004, Rob Mueller wrote:

> So it seems we have an original draft, comments  about problems, and even 
> agreement by the original author, but no followup as yet :(

I'll note that MANAGESIEVE is in much the same state.

I guess this is a disadvanteage of proceeding without an official Working 
Group...

-Rob

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Rob Siemborski | Andrew Systems Group * Research Systems Programmer
PGP:0x5CE32FCC | Cyert Hall 207 * [email-masked] * 412.268.7456
-----BEGIN GEEK CODE BLOCK----
Version: 3.12
GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++ E W+ N(-) o? K- w-- O-
M-- V-- PS+ PE+ Y+ PGP+ t+@ 5+++ X- R@ tv-- b+ DI+++ D++ G e++ h+ r- y?
------END GEEK CODE BLOCK-----

From: "Rob Mueller" <[email-masked]>
To: <[email-masked]>
Cc: "Wolfgang Segmuller" <[email-masked]>, "Simon Josefsson" <[email-masked]>, "\"Nigel Swinson\"" <[email-masked]>, <[email-masked]>, <[email-masked]>, "Jutta Degener" <[email-masked]>, "Jeremy Howard" <[email-masked]>
Subject: State of notify draft...
Date: Mon, 21 Jun 2004 13:04:42 -0700
Sender: [email-masked]

Hi

I'm just trying to find out if anyone knows anything more about the current 
state of the notify extension. Looking from the list archive I can see this 
was first announced on 03 Jul 2001:

http://www.imc.org/ietf-mta-filters/mail-archive/msg00972.html

A couple of good points re $from$ vs $from-address$ vs $from-name$ and QP 
and charset decoding were raised here:

http://www.imc.org/ietf-mta-filters/mail-archive/msg00973.html

And there was tentative agreement on many of these issues from the original 
draft author stating that he'd create a new one.

http://www.imc.org/ietf-mta-filters/mail-archive/msg00980.html

Though there didn't appear to have been another draft forth coming, and
searching the list, almost no discussion on the "notify" extension since
then, apart from a similar "what's up" email here:

http://www.imc.org/ietf-mta-filters/mail-archive/msg01007.html

So it seems we have an original draft, comments  about problems, and even 
agreement by the original author, but no followup as yet :(

I'm wondering what the general process for going forward and creating 
another draft with some of these issues addressed? I think that having a 
non-decoded text/* part in an arbitrary character set will be somewhere 
between annoying and useless, and the separated $from-address$ and 
$from-name$ variables would be very useful.

Is there anyone interested in/able to create a new draft? If not, I'd be 
willing to do it, but I'm not entirely sure of the process of taking over 
and going forward with this.

Rob

Date: Mon, 21 Jun 2004 15:35:27 +0200
From: "Rolf E. Sonneveld" <[email-masked]>
Subject: Question on separators in localpart
To: [email-masked]
Cc: [email-masked]
Reply-to: [email-masked]
Organization: Sonnection B.V.
Importance: Normal
Sender: [email-masked]

This is a multi-part message in MIME format.

--Boundary_(ID_yek982cZ6kTg9wdkJWX7hA)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT

Hi,

some time ago a discussion took place on this list about 'detail
separators'. I can't recall the details of the discussion. But on the
subject of 'detail separators' I have a question.

For a new to-be-created e-mail address naming convention, user addresses
will get the notation [email-masked]. AFAIK this is in general
use at many organizations worldwide.

For functional mailboxes there are multiple choices. My question is: is
it better to use (e.g.):

[email-masked] (dot in localpart)

[email-masked] (hyphen in localpart)

[email-masked] (underscore in localpart)

I believe the 'underscore' will possibly cause other problems (e.g. when
gatewayed into the X.400 world), so the question is mainly whether the
use of either format 1 (dot) or format 2 (hyphen) will cause any
possible problems for SIEVE scripts?

Regards,

/rolf

--Boundary_(ID_yek982cZ6kTg9wdkJWX7hA)
Content-type: text/html; charset=us-ascii
Content-transfer-encoding: QUOTED-PRINTABLE

<html>=0D=0A=0D=0A<head>=0D=0A<META HTTP-EQUIV=3D"Content-Type" CONTE=
NT=3D"text/html; charset=3Dus-ascii">=0D=0A=0D=0A=0D=0A<meta name=
=3DGenerator content=3D"Microsoft Word 10 (filtered)">=0D=0A=0D=0A<st=
yle>=0D=0A<!--=0D=0A /* Font Definitions */=0D=0A @font-face=0D=0A=
=09{font-family:MetaCorrespondence;=0D=0A=09panose-1:2 11 5 2 3 0 0 2=
 0 4;}=0D=0A /* Style Definitions */=0D=0A p.MsoNormal, li.MsoNormal,=
 div.MsoNormal=0D=0A=09{margin:0in;=0D=0A=09margin-bottom:.0001pt;=
=0D=0A=09font-size:11.0pt;=0D=0A=09font-family:MetaCorrespondence;}=
=0D=0Aa:link, span.MsoHyperlink=0D=0A=09{color:blue;=0D=0A=09text-dec=
oration:underline;}=0D=0Aa:visited, span.MsoHyperlinkFollowed=0D=0A=
=09{color:purple;=0D=0A=09text-decoration:underline;}=0D=0Aspan.Email=
Style17=0D=0A=09{font-family:Arial;=0D=0A=09color:windowtext;}=0D=
=0A@page Section1=0D=0A=09{size:8.5in 11.0in;=0D=0A=09margin:1.0in 1.=
25in 1.0in 1.25in;}=0D=0Adiv.Section1=0D=0A=09{page:Section1;}=0D=
=0A-->=0D=0A</style>=0D=0A=0D=0A</head>=0D=0A=0D=0A<body lang=3DEN-US=
 link=3Dblue vlink=3Dpurple>=0D=0A=0D=0A<div class=3DSection1>=0D=
=0A=0D=0A<p class=3DMsoNormal><font size=3D2 face=3DArial><span style=
=3D'font-size:10.0pt;=0D=0Afont-family:Arial'>Hi,</span></font></p>=
=0D=0A=0D=0A<p class=3DMsoNormal><font size=3D2 face=3DArial><span st=
yle=3D'font-size:10.0pt;=0D=0Afont-family:Arial'>&nbsp;</span></font>=
</p>=0D=0A=0D=0A<p class=3DMsoNormal><font size=3D2 face=3DArial><spa=
n style=3D'font-size:10.0pt;=0D=0Afont-family:Arial'>some time ago a =
discussion took place on this list about &#8216;detail=0D=0Aseparator=
s&#8217;. I can&#8217;t recall the details of the discussion. But on=
=0D=0Athe subject of &#8216;detail separators&#8217; I have a questio=
n.</span></font></p>=0D=0A=0D=0A<p class=3DMsoNormal><font size=3D2 f=
ace=3DArial><span style=3D'font-size:10.0pt;=0D=0Afont-family:Arial'>=
&nbsp;</span></font></p>=0D=0A=0D=0A<p class=3DMsoNormal><font size=
=3D2 face=3DArial><span style=3D'font-size:10.0pt;=0D=0Afont-family:A=
rial'>For a new to-be-created e-mail address naming convention,=0D=
=0Auser addresses will get the notation <a href=3D"mailto:First.Last@=
domain.com">[email-masked]</a>.=0D=0AAFAIK this is in general =
use at many organizations worldwide.</span></font></p>=0D=0A=0D=0A<p =
class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-siz=
e:10.0pt;=0D=0Afont-family:Arial'>&nbsp;</span></font></p>=0D=0A=0D=
=0A<p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'fo=
nt-size:10.0pt;=0D=0Afont-family:Arial'>For functional mailboxes ther=
e are multiple choices. My=0D=0Aquestion is: is&nbsp; it better to us=
e (e.g.):</span></font></p>=0D=0A=0D=0A<p class=3DMsoNormal><font siz=
e=3D2 face=3DArial><span style=3D'font-size:10.0pt;=0D=0Afont-family:=
Arial'>&nbsp;</span></font></p>=0D=0A=0D=0A<p class=3DMsoNormal><font=
 size=3D2 face=3DArial><span style=3D'font-size:10.0pt;=0D=0Afont-fam=
ily:Arial'><a href=3D"mailto:[email-masked]">HelpDesk.Lon=
[email-masked]</a>=0D=0A(dot in localpart)</span></font></p>=0D=0A=
=0D=0A<p class=3DMsoNormal><font size=3D2 face=3DArial><span style=
=3D'font-size:10.0pt;=0D=0Afont-family:Arial'><a href=3D"mailto:HelpD=
[email-masked]">[email-masked]</a>=0D=0A(hyphen in=
 localpart)</span></font></p>=0D=0A=0D=0A<p class=3DMsoNormal><font s=
ize=3D2 face=3DArial><span style=3D'font-size:10.0pt;=0D=0Afont-famil=
y:Arial'><a href=3D"mailto:[email-masked]">HelpDesk_Londo=
[email-masked]</a>=0D=0A(underscore in localpart)</span></font></p>=
=0D=0A=0D=0A<p class=3DMsoNormal><font size=3D2 face=3DArial><span st=
yle=3D'font-size:10.0pt;=0D=0Afont-family:Arial'>&nbsp;</span></font>=
</p>=0D=0A=0D=0A<p class=3DMsoNormal><font size=3D2 face=3DArial><spa=
n style=3D'font-size:10.0pt;=0D=0Afont-family:Arial'>I believe the &#=
8216;underscore&#8217; will possibly cause=0D=0Aother problems (e.g. =
when gatewayed into the X.400 world), so the question is=0D=0Amainly =
whether the use of either format 1 (dot) or format 2 (hyphen) will ca=
use=0D=0Aany possible problems for SIEVE scripts?</span></font></p>=
=0D=0A=0D=0A<p class=3DMsoNormal><font size=3D2 face=3DArial><span st=
yle=3D'font-size:10.0pt;=0D=0Afont-family:Arial'>&nbsp;</span></font>=
</p>=0D=0A=0D=0A<p class=3DMsoNormal><font size=3D2 face=3DArial><spa=
n style=3D'font-size:10.0pt;=0D=0Afont-family:Arial'>Regards,</span><=
/font></p>=0D=0A=0D=0A<p class=3DMsoNormal><font size=3D2 face=3DAria=
l><span style=3D'font-size:10.0pt;=0D=0Afont-family:Arial'>/rolf</spa=
n></font></p>=0D=0A=0D=0A<p class=3DMsoNormal><font size=3D2 face=
=3DArial><span style=3D'font-size:10.0pt;=0D=0Afont-family:Arial'>&nb=
sp;</span></font></p>=0D=0A=0D=0A<p class=3DMsoNormal><font size=3D2 =
face=3DArial><span style=3D'font-size:10.0pt;=0D=0Afont-family:Arial'=
>&nbsp;</span></font></p>=0D=0A=0D=0A</div>=0D=0A=0D=0A</body>=0D=
=0A=0D=0A</html>=0D=0A=

--Boundary_(ID_yek982cZ6kTg9wdkJWX7hA)--

Date: Sun, 13 Jun 2004 21:24:35 +0000
From: Jehorton <[email-masked]>
Subject: IndispensableSoftWare on cd... needy? seeBody
To: Ietf-mta-filters <[email-masked]>
Sender: [email-masked]

Ietf-mta-filters
http://FJGCNA.info/OE017/?affiliate_id=233642&campaign_id=601
http://BENBCE.info/OE017/?affiliate_id=233642&campaign_id=601
Bye-bye

Date: Tue, 08 Jun 2004 19:46:40 -0700
From: Matthew Elvey <[email-masked]>
To: [email-masked]
Subject: "refuse" ;  Re: Registration of new Sieve extensions, and changes. (sieve-extensions)
Sender: [email-masked]

An FYI, and a new post.
-----------
FYI, per an earlier post, I contacted IANA and heard back a month later:

On 6/8/2004 12:47 PM, IANA sent forth electrons to convey:

Matthew,

We have corrected the reference in the sieve-extensions
registry and registered the 2 sieve-extensions mentioned below.

Capability name: refuse
Capability keyword: refuse
Capability arguments: N/A
Standards Track/IESG-approved experimental RFC number:
     [draft-elvey-refuse-sieve-01.txt]
Person and email address to contact for further information:
    Matthew Elvey
    The Elvey Partnership, LLC
    3042 Sacramento-ietf St Ste 04
    San Francisco, CA
    U.S.A.
    [email-masked]

AND

Capability name: regex
Capability keyword: regex
Capability arguments: N/A
Standards Track/IESG-approved experimental RFC number:
    [draft-murchison-sieve-regex-07.txt]
Person and email address to contact for further information:
   Kenneth Murchison
   [email-masked]

Please see: <http://www.iana.org/assignments/sieve-extensions>

Please note:  Extensions designed for interoperable use
SHOULD be defined as standards track or IESG approved
experimental RFCs.

Best regards,

Michelle Cotton
IANA

-----Original Message-----
From: Matthew Elvey [mailto:[email-masked]]
Sent: Saturday, May 08, 2004 2:49 PM
To: [email-masked]
Subject: Registration of new Sieve extensions, and changes.

Hello, and thanks for your public service.

I think
http://www.iana.org/assignments/sieve-extensions needs some updates.

An RFC # (3685) has been associated with spamtest and virustest.
-see http://www.faqs.org/rfcs/rfc3685.html

Please add the RFC #, and add the following entries:

Per
http://www.ietf.org/internet-drafts/draft-elvey-refuse-sieve-01.txt :

   Capability name: refuse
   Capability keyword: refuse
   Capability arguments: N/A
   Standards Track/IESG-approved experimental RFC number:
[RFC-elvey-refuse-sieve-01.txt]
   Person and email address to contact for further information:

       Matthew Elvey
       The Elvey Partnership, LLC
       3042 Sacramento-ietf St Ste 04
       San Francisco, CA
       U.S.A.

       [email-masked]

Per
http://www.ietf.org/internet-drafts/draft-murchison-sieve-regex-07.txt :

    Capability name: regex
    Capability keyword: regex
    Capability arguments: N/A
    Standards Track/IESG-approved experimental RFC number:
[RFC-murchison-sieve-regex-07.txt]
 Person and email address to contact for further information:

    Kenneth Murchison
    [email-masked]

Thanks,
Matthew

---------------
Also, here's an email I sent to Mark M and [email-masked] instead of [email-masked]:

On 6/7/2004 11:19 AM, Matthew Elvey sent forth electrons to convey:

>> I'm suggesting that the spec should be adjusted to allow a best-effort
>> "refuse" with a fallback to another action...
>
>
>
> Please suggest the specific other action you would like it to fallback 
> to; if you don't it's difficult to make progress.
> Is the specific other action bitbucketing?  That is what you were 
> suggesting earlier.
>
>
>> Imagine a
>> change to an SMTP server that makes "refuse" not work- either for
>> a short while, or for the long term.  Neither is hard to imagine.
>>
> Please assume I have no imagination, and provide a specific example, of
>
> "situationally unavailable" which would result in a problem
>
> so we can discuss a specific situation.
> I can't think of such a situation where there would be a resulting 
> problem.
>
> I will respond further to your email, but want to deal with these 
> points first.
>

From: "Mark E. Mallett" <[email-masked]>
Date: Mon, 7 Jun 2004 01:14:25 -0400
To: Matthew Elvey <[email-masked]>
Cc: "Mark E. Mallett" <[email-masked]>, [email-masked]
Subject: Re: I-D ACTION:draft-elvey-refuse-sieve-01.txt
Sender: [email-masked]

On Fri, Jun 04, 2004 at 12:20:34PM -0700, Matthew Elvey wrote:
> On 6/4/2004 5:29 AM, Mark E. Mallett sent forth electrons to convey:

> >This may not be the only fallback case.  I could envision other cases
> >where smtp-time "refuse" was generally implemented, but situationally
> >unavailable.  (You've identified one.)  As you say, existing scripts
> >should continue to run.
> >
> What do you envision? I haven't thought of any others and don't think 
> there are any.

a) All it takes is one such case for the point to apply.  The fact
that there is one at all is enough.

b) I alluded to some more broader cases and even gave a f'rinstance.
The key is "situationally unavailable."  In fact there are other
arguments that apply here that don't apply to (a).  I'll expand a
little below.

> We designed the spec consciously so that, e.g. MUAs can't implement 
> "refuse".
> In other words, if you want to <require "refuse">, tough, if your 
> implementation can't handle it.
> If it claims to, it's violating our spec.  We can't physically prevent 
> this from happening though.
> We state it strongly:
> 
> "A SIEVE implementation that cannot do so MUST NOT claim
>  to support the refuse extension."

Well that's all very self-referential as an answer :-)

I'm suggesting that the spec should be adjusted to allow a best-effort
"refuse" with a fallback to another action, and your refutation is
that the spec doesn't allow it.  That's too circular of a way to
respond to the suggestion.

> >I'd take that into account by being able to specify a fallback option
> >should "refuse" not be present.  And if you give the ability to have a
> >fallback option, you could make the default fallback action be
> >"discard" rather than "reject" -- and force the script writer to
> >specify a preference for reject if for some reason they wanted to use
> >it.
> >
> That's being much more cavalier with people's email than I'm comfortable 
> with,

Actually it's the opposite of being cavalier: it's giving more options
to the script writer.  I'm trying to see how you classify it as
cavalier- perhaps you think I'm saying that the only action be
discard, and not the default one?  Figuring out what the best default
is is a matter that's best done before people start writing scripts.
Having a default doesn't preclude other deliberate actions.  I simply
suggest a default that encompasses the usual case; defaults constructed
in that way help minimize code and enhance clarity.

> especially if one is optimistic that we will have a pretty 
> effective antispam solution in the fairly near future - effective enough 
> to drive a bunch of them out of the business.

That would be nice.  Even if that comes to pass, "refuse" and other
actions will still be useful.

> There's an RFC for unilaterally preventing joe jobs, and someone 
> reinvented the same or came up with a similar solution at the recent 
> ASRG MARID meeting.
> I could look it up if you're interested. <comments to this point, and 
> most others later are repeated from my email of 5/25 to which I haven't 
> received a response(!?).>

Sorry, maybe I wasn't clear.  I did respond- I said that any extended
back and forth discussion would be better on the list, and I promised
to restate my thoughts here.  Which I did (it took me a while, sorry).

Anyway, on to specifics about "situational unavailability" of "refuse."

Mainly I'm concerned not so much about individual scripts but about
script portability and overall system administration.  For language
growth I'd like to help ensure that scripts can be written in a way
that lets people move them from one environment to another without
having to completely rewrite them.  Unfortunately the "require" model,
while having a noble goal, tends to work against this.  With some
extensions (such as "spamtest"), there's not much that can be done
about it (other than having a way to conditionalize based on the
presence of cababilities, as I've said elsewhere).  But with something
like "refuse" I think there is- simply by allowing its best-effort use
with a fallback if it's unavailable.  Some cases:

a) Surely it would be good to encourage people to design their scripts
to use "refuse" now, even if the environment won't support it until
some time in the future.  When the environment does support it,
peoples' existing scripts would suddenly do better things.

b) On a server-wide administrative level, things change.  Imagine a
change to an SMTP server that makes "refuse" not work- either for
a short while, or for the long term.  Neither is hard to imagine.
This is what I had in mind when I said something about "refuse being
situationally unavailable."  Without a fallback capability, such
system-wide changes would be a nightmare.  

c) Similarly, one should allow for scripts to be pushed off to other
instances of mail servers which handle incoming mail for a large
environment, not all of which are architected the same.  

d) Part of designing language elements such as this is not having to
imagine every eventuality, but rather providing options that allow
flexibility in the face of currently-unknown future situations.
Planning for a best-attempt "refuse" with a fallback strikes me
as much better than an all-or-nothing "refuse" without one.

If SIEVE provided conditionals based on capabilities, there'd be no
need for this, and perhaps I wouldn't be suggesting it ('tho maybe I
would).  But it doesn't, and so I am.

Bottom line: I would prefer a "refuse if you can" kind of spec, for
all the reasons stated.  It would allow for more flexibility in
script writing, better script portability, better anticipation of
SMTP-time support for scripts now, and less headaches for system
administrators.

Yours,
-mm-

Date: Fri, 04 Jun 2004 12:20:34 -0700
From: Matthew Elvey <[email-masked]>
To: "Mark E. Mallett" <[email-masked]>
Cc: [email-masked]
Subject: Re: I-D ACTION:draft-elvey-refuse-sieve-01.txt
Sender: [email-masked]

On 6/4/2004 5:29 AM, Mark E. Mallett sent forth electrons to convey:

>This is a fine draft.  I have a few musings that I sent to Matthew
>earlier that I'll twist around a little here- don't mistake these as
>objections though, there's really not a lot to object to.  Not sure I
>made that clear earlier.  But I do think there are some points to
>raise, if not ponder.
>
>In this draft there are some great justifications for script writers
>to use "refuse" rather than "reject.  However there's this:
>
>  
>
>>There is an exception when a single message has multiple SMTP 
>>recipients, and at least one but not all of them are refusing delivery 
>>(whether the refusal is caused by execution of a Sieve "refuse" or for 
>>another reason). In this case, the server MUST accept the message and 
>>generate DSNs for all recipients that are refusing it.
>>    
>>
>
>This may not be the only fallback case.  I could envision other cases
>where smtp-time "refuse" was generally implemented, but situationally
>unavailable.  (You've identified one.)  As you say, existing scripts
>should continue to run.
>  
>
What do you envision? I haven't thought of any others and don't think 
there are any.
We designed the spec consciously so that, e.g. MUAs can't implement 
"refuse".
In other words, if you want to <require "refuse">, tough, if your 
implementation can't handle it.
If it claims to, it's violating our spec.  We can't physically prevent 
this from happening though.
We state it strongly:

"A SIEVE implementation that cannot do so MUST NOT claim
  to support the refuse extension."

>I see a conundrum, in that script writers will feel assured that by
>using "refuse" they will not be generating bounces.  Without "refuse" a
>conscientious script writer would probably have used "discard" or
>"fileinto" -- anything other than "reject."  However, in the presence
>of a "refuse" option, the same conscientious script writer will likely
>use "refuse."  So under some conditions the very presence of this
>option could increase the likelihood of generating rejects.  No matter
>what percentage this represents, I'd feel better if that were taken
>into account.
>  
>
This will happen if the implementation is defective (and in the listed 
exceptional case, which I'm not worried about).
I think what we've done already will prevent this from being a real problem.

>I'd take that into account by being able to specify a fallback option
>should "refuse" not be present.  And if you give the ability to have a
>fallback option, you could make the default fallback action be
>"discard" rather than "reject" -- and force the script writer to
>specify a preference for reject if for some reason they wanted to use
>it.
>  
>
That's being much more cavalier with people's email than I'm comfortable 
with, especially if one is optimistic that we will have a pretty 
effective antispam solution in the fairly near future - effective enough 
to drive a bunch of them out of the business.
There's an RFC for unilaterally preventing joe jobs, and someone 
reinvented the same or came up with a similar solution at the recent 
ASRG MARID meeting.
I could look it up if you're interested. <comments to this point, and 
most others later are repeated from my email of 5/25 to which I haven't 
received a response(!?).>
For example, here's a problem: I admin a few mailing lists (verified 
opt-in, of course.)  One is political and has severe deliverability 
problems that I'm working to fix.  Not getting any indication that mail 
hasn't been delivered makes this task much harder.

The ideas below are good ideas for improving Sieve, but are out of scope 
for my draft.  It would be in scope for a new version of Sieve, and 
would require several extension specs be changed to work well with it.

I think we've made the best of a bad situation; don't see how we can 
improve the "refuse" spec.

>I don't even think that's the best alternative: better would be some
>more systemic-level enhancements to SIEVE that would allow certain
>conditions to be tested and operated on.  For example, being able to
>test whether "refuse" succeeded would help:
>
>    if not refuse "This looks like spam" {
>        discard;
>    }
>  
>
Yeah, this would be nice, but it's not something I'm able to take on.  
I'd support it.  IIRC, Sieve actions don't have return values.

>Less disruptive systemic changes could be devised; for example being
>able to test the status of the implicit keep flag:
>
>    refuse "This looks like spam";
>    if not ikeep { discard; }
>
>Or something like a "stop" if successful:
>
>    refuse :stop "This looks like spam";
>    discard;
>
>
>This branches into a train of thought about general script portability:
>I've mentioned in the past that it would be nice to be able to have
>conditions depending on what mode a script was running in, or what
>capabilities were supported, so that scripts could continue to run in
>the face of changing environments.  ("changing environments" was in
>fact one of the cases I had in mind above, when I mentioned that there
>could be other situations in which "refuse" is unavailable.  One has
>to think of the system administration too.)  Other than that, I'm
>obviously getting farther away from "refuse" -- but I often think that
>some broader thinking about SIEVE extensions would help keep the
>language more whole in the face of these optional capabilities.
>(That's rather brusque but I don't want to go on here too long..)
>
>At any rate, those are some thoughts.
>
>-mm-
>
>  
>

PPS I find your comments constructive and helpful, though my 
to-the-point comments and questions might make it seem otherwise.  Thanks.

From: "Mark E. Mallett" <[email-masked]>
Date: Fri, 4 Jun 2004 08:29:13 -0400
To: [email-masked]
Cc: "Mark E. Mallett" <[email-masked]>
Subject: Re: I-D ACTION:draft-elvey-refuse-sieve-01.txt
Sender: [email-masked]

This is a fine draft.  I have a few musings that I sent to Matthew
earlier that I'll twist around a little here- don't mistake these as
objections though, there's really not a lot to object to.  Not sure I
made that clear earlier.  But I do think there are some points to
raise, if not ponder.

In this draft there are some great justifications for script writers
to use "refuse" rather than "reject.  However there's this:

> There is an exception when a single message has multiple SMTP 
> recipients, and at least one but not all of them are refusing delivery 
> (whether the refusal is caused by execution of a Sieve "refuse" or for 
> another reason). In this case, the server MUST accept the message and 
> generate DSNs for all recipients that are refusing it.

This may not be the only fallback case.  I could envision other cases
where smtp-time "refuse" was generally implemented, but situationally
unavailable.  (You've identified one.)  As you say, existing scripts
should continue to run.

I see a conundrum, in that script writers will feel assured that by
using "refuse" they will not be generating bounces.  Without "refuse" a
conscientious script writer would probably have used "discard" or
"fileinto" -- anything other than "reject."  However, in the presence
of a "refuse" option, the same conscientious script writer will likely
use "refuse."  So under some conditions the very presence of this
option could increase the likelihood of generating rejects.  No matter
what percentage this represents, I'd feel better if that were taken
into account.

I'd take that into account by being able to specify a fallback option
should "refuse" not be present.  And if you give the ability to have a
fallback option, you could make the default fallback action be
"discard" rather than "reject" -- and force the script writer to
specify a preference for reject if for some reason they wanted to use
it.

I don't even think that's the best alternative: better would be some
more systemic-level enhancements to SIEVE that would allow certain
conditions to be tested and operated on.  For example, being able to
test whether "refuse" succeeded would help:

    if not refuse "This looks like spam" {
        discard;
    }

Less disruptive systemic changes could be devised; for example being
able to test the status of the implicit keep flag:

    refuse "This looks like spam";
    if not ikeep { discard; }

Or something like a "stop" if successful:

    refuse :stop "This looks like spam";
    discard;

This branches into a train of thought about general script portability:
I've mentioned in the past that it would be nice to be able to have
conditions depending on what mode a script was running in, or what
capabilities were supported, so that scripts could continue to run in
the face of changing environments.  ("changing environments" was in
fact one of the cases I had in mind above, when I mentioned that there
could be other situations in which "refuse" is unavailable.  One has
to think of the system administration too.)  Other than that, I'm
obviously getting farther away from "refuse" -- but I often think that
some broader thinking about SIEVE extensions would help keep the
language more whole in the face of these optional capabilities.
(That's rather brusque but I don't want to go on here too long..)

At any rate, those are some thoughts.

-mm-