Subject: Re: Please review ; Sieve Statistics and Sieve remove attachments

From: Madan Ganesh Velayudham <[email-masked]>
Date: Tue, 03 Feb 2004 00:05:52 +0530

Hi Lyndon,

	Thank you for your review comments.

	Please find my comments in line :
> 
> Some comments based on a quick scan of the document ...
> 
> Section 4:
> 
> * "action" needs to be more clearly defined

	Sure. Shall refine it.
> 
> Section 5:
> 
> * Why two capabilities? Both commands are required, so there's     no 
> point in advertising two capability strings. The capability should be 
> changed to something like "STATISTICS".

	Thats great. Yes, Both are required capability strings. I will
	update the Capability string to STATISTICS.

> 
> Section 6:
> 
> * What does a "zero valued action counter" mean? Surely '0' is a valid 
> counter value, meaning the action has never been triggered. I think what 
> you're implying here is that a '0' value means the counter for the 
> action isn't implemented. If that's the case, just don't return a 
> response for that action.

	My initial assumption was if the discarded mail count is 0, the 
implementation may return discard 0 or dont return discard action itself.

	But as you said, the client is no way differentiating whether the 
action is supported or not.

> 
> * Presumably GETSTAT is only valid in authenticated state? (Section 7 
> explicitly calls this out, so section 6 should as well.)

	I think it is already there. "This command MUST be given after the 
client is authenticated". Pls clarify if i'm wrong.

> 
> Section 8:
> 
> * The grammar (and semantic description) for the command responses is 
> missing.

	Thanks for pointing out. I shall include it some thing like

	command-getstat-resp  =  getstat-resp-list

	getstat-resp-list = [ supported-action integer-value ] * getstat-resp-list

	supported-action  = "discard" / "divert" / "reject"

	command-resetstat=res = "OK" | "NO"
	
> 
> Section 9:
> 
> * Since there's no way (that I can see) to access another users counter 
> data (through the protocol), this text doesn't seem relevant.

	Yes, I agree. But to be expilicit.

> 
> General:
> 
> * How useful is the returned data? The fact that an action took place 
> doesn't really tell me anything. I would be much more interested in 
> seeing how often each rule fired, as that would allow me to optimize my 
> rulesets.
> 

	That is a interesting thought. I shall think of it and document it.

	Please let me know your comments.
	MG

> --lyndon

-- 
  _____________________________________________________________
      ___
     /___\      Madan ganesh Velayudham
    |/. .\|     STSD, India
    (   ) )     +91 80 (2) 205 3108
     \ = /
     _)_(_   There are no limitation in what you can do
             except the limitations of your own mind.
_____________________________________________________________

---

From: "Nigel Swinson" <[email-masked]>
Date: Wed, 4 Feb 2004 14:08:32 -0000

> "SIEVE: Remove attachment(s)", Madan Velayudham, 23-Dec-03. (8185 bytes) "
>
>
http://ietf.org/internet-drafts/draft-madanganeshv-sieve-remove-attach-00.txt
>
>
> This draft introduces an action command 'fileinto-except' to [SIEVE] in
> order to move a message to a folder without certain attachments of the
> received message.

I think it might be more useful to have an action that removes an
attachment, and a test that tests for the prescence of a mime body part.  So
you'd say:

if (message contains .exe attachment) {
    remove .exe attachment
    fileinto folder;
    stop;
}

We generically want a test that allows users to examine the prescense or
absence of attachments of various kinds, so I think it would make sense to
build upon that work.  As it is, the extension you propose means that you
can only neatly remove one style of attachment.  What if you want to remove
all .exe/.bat/.pif/.vbs attachments?  You'd end up with long and nasty regex
expressions that try to match filenames that contain any of the proposed
extensions.  Much better I think would be to have four remove attachment
commands, one for each kind of extension.

Having a remove-attachment extension will end up along the lines of the
editheader extensions in the sense that they will modify the message.  So it
raises some of the issues that have already been discussed there, so I guess
we'd have to say that tests examine the current state of the message.  So if
we say:

remove .exe attachments
if (message contains .exe attachment) {
  We'd never get here.
}

Cheers

Nigel

---

From: Lyndon Nerenberg <[email-masked]>
Date: Wed, 04 Feb 2004 22:10:38 -0800

--On 2004-2-3 12:05 AM +0530 Madan Ganesh Velayudham 
<[email-masked]> wrote:

>> Section 9:
>>
>> * Since there's no way (that I can see) to access another users
>> counter  data (through the protocol), this text doesn't seem
>> relevant.
>

It is "explicit" by reason of the specification simply not specifying 
the facility. Having the security section talk about something that 
does not exist in the protocol is just going to confuse people. The 
text in question needs to be removed.

---

From: Madan Ganesh Velayudham <[email-masked]>
Date: Thu, 05 Feb 2004 14:16:32 +0530

Lyndon Nerenberg wrote:
> the facility. Having the security section talk about something that does 
> not exist in the protocol is just going to confuse people. The text in 
> question needs to be removed.
> 
> 

Yes, Lyndon. Thats a valid one. It is better not to confuse the people.
The updated draft will not have this text.

Thank You,
MG