Re: I-D ACTION:draft-elvey-refuse-sieve-01.txt

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.

Re: I-D ACTION:draft-elvey-refuse-sieve-01.txt

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.

Re: I-D ACTION:draft-elvey-refuse-sieve-01.txt

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."

"refuse" ; Re: Registration of new Sieve extensions, and changes. (sieve-extensions)

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.
    sieve3 <at> matthew.elvey.com

AND

Capability name: regex
Capability keyword: regex
Capability arguments: N/A

Question on separators in localpart

State of notify draft...

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

Re: State of notify draft...

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 * rjs3 <at> andrew.cmu.edu * 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+ <at>  5+++ X- R <at>  tv-- b+ DI+++ D++ G e++ h+ r- y?
------END GEEK CODE BLOCK-----

Re: Question on separators in localpart

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

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

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

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

> What is the intended use of :binary?  If its for checking virus 
> 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 
> 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).

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?

> 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?

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 <jutta <at> sendmail.com>