headers
Mark E. Mallett | 1 Apr 2005 03:41

Re: I-D ACTION:draft-ietf-sieve-vacation-00.txt


On Thu, Mar 31, 2005 at 10:37:12AM -0800, ned.freed <at> mrochek.com wrote:

> > An implementation might know the address being delivered to (the
> > envelope recipient).  UNIX "vacation" has a place to put additional
> > email addresses to look for, because the envelope recipient has
> > typically been been lost at this point.  I would say that that's also
> > the value of the ":addresses" here too.
> 
> > So I would think this would say that the envelope recipient, if known,
> > OR one of the addresses listed in the :addresses must appear in one of
> > the listed header fields.
> 
> I really don't think a change is in order here. Nothing in the present text
> makes an implementation that has no knowledge of its own of the recipient's
> address(es) incompliant. And OTOH I really don't think we should encourage
> implementations that are ignorant of this. (It is one thing when circumstances
> make it impossible, quite another where a standard in effect condones lazy
> implementation practices.)

I humbly beg to differ about the lazy part.  While I am probably lazier
than the next guy, I'm talking about completeness here in the absence of
knowable information.  Remember (as I'm sure you do) that we're talking
about looking into the various destination headers (To, Cc, et al) to
make sure that one of them contains one of the addresses owned in some
sense by the recipient, as an indication that the message is specifically
addressed to the recipient.

There are a number of legitimate reasons why the implementation might
not know what all of the specific recipient addresses are.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Mark E. Mallett | 1 Apr 2005 04:09

Re: another implementation issue


On Thu, Mar 31, 2005 at 10:01:14AM +0300, Sorin Suciu wrote:
>    another question that was not answered in the rfc concernes the 
> address test. If I have an address test with the :localpart or :domain tag,
> what is to apear in the seccond string list: full valid addreses, local 
> parts and domains or both?

My interpretation is that the second string list merely has strings,
to be compared against the specified address parts.  I think that's
what the RFC wording says:

   It returns true if any header contains any key in the specified part
   of the address, as modified by the comparator and the match keyword.

> what if I have the :all tag, do I have to test for valid addresses 
> in the seccond list?

Treating the second list as "keys" to match against, I would say no. 

mm
Permalink | Reply | 0 comments |
headers
ned.freed | 1 Apr 2005 03:54

Re: I-D ACTION:draft-ietf-sieve-vacation-00.txt


> On Thu, Mar 31, 2005 at 10:37:12AM -0800, ned.freed <at> mrochek.com wrote:

> > > An implementation might know the address being delivered to (the
> > > envelope recipient).  UNIX "vacation" has a place to put additional
> > > email addresses to look for, because the envelope recipient has
> > > typically been been lost at this point.  I would say that that's also
> > > the value of the ":addresses" here too.
> >
> > > So I would think this would say that the envelope recipient, if known,
> > > OR one of the addresses listed in the :addresses must appear in one of
> > > the listed header fields.
> >
> > I really don't think a change is in order here. Nothing in the present text
> > makes an implementation that has no knowledge of its own of the recipient's
> > address(es) incompliant. And OTOH I really don't think we should encourage
> > implementations that are ignorant of this. (It is one thing when circumstances
> > make it impossible, quite another where a standard in effect condones lazy
> > implementation practices.)

> I humbly beg to differ about the lazy part.

Please reread my response more carefully. At no point did I say, or even imply,
any laziness on your part. On the contrary, I fully acknowledged that there are
going to be cases where the implementation won't know what all, or even some,
of the addresses asssociated with the recipient are. And this is the primary
reason for having an :addresses argument - so specific scripts can
specify those addresses the implementation does not know about.

But this is information is available to lots of other implementations. It may
(Continue reading)

Permalink | Reply | 1 comment |
headers
Matthew Elvey | 2 Apr 2005 03:37
Picon

Re: email architecture discussion of SIEVE


On Thu, 31 Mar 2005 10:20:11 -0800, "Dave Crocker" <dhc2 <at> dcrocker.net>
said:
> 
> Folks,
> 
> I've been working on a draft to document modern Internet Mail
> Architecture.  
> The lastest draft is at 
> 
>   <http://bbiw.net/specifications/draft-crocker-email-arch-04.html>
> and
>   <http://www.ietf.org/internet-drafts/draft-crocker-email-arch-04.txt>
> 
> 
> After getting some comments on this latest draft, I am changing the
> discussion of specialized data (messages, etc).  I would appreciate any
> comments you might have on this candidate text, especially about the 
> discussion of sieve:
> 
> 
> >  Internet Mail has some special control data:
> >
> >  Delivery Status Notification (DSN):
> >
> >  A Delivery Status Notification (DSN) is a message that can be generated by
> >  the Mail Handling Service (MSA, MTA or MDA) and sent to the
> >  RFC2821.MailFrom address. The mailbox for this is shown as Bounces in
> >  Figure 5 It provides information about message transit, such as
> >  transmission errors or successful delivery. [RFC3461]
(Continue reading)

Permalink | Reply | 501 comments |
headers
Matthew Elvey | 2 Apr 2005 20:37
Picon

Re: implementation issues


On 3/31/05 12:16 AM, Sorin Suciu sent forth electrons to convey:

>
> so, if i understand this correctly we have the following receipe for a 
> perfect implementation:
> - reject can only be by itself and only once (eventualy with stop)

I disagree.  From 
http://www.elvey.com/it/sieve/draft-elvey-refuse-sieve-02.txt:

>4.2  "refuse" compatibility with other actions
>   
>   "Refuse" cancels the implicit keep, and is incompatible with
>   "reject" and "discard". "Refuse" is also incompatible with
>   "vacation" extension [VACATION]. (It should be compatible and
>   incompatible with the same actions as "reject", but [SIEVE] states
>   "Implementations SHOULD prohibit reject when used with other
>   actions." However we feel that "refuse" should be permitted when
>   used with other actions such as "fileinto" and "redirect".  This
>   could be useful for analyzing, tracking or reporting spam.  Also,
>   users can use tricks (such as multiple redirects back to their own
>   email addresses) to get around such a prohibition anyway.)
>
IIRC, there was support for such behavior.
(I wonder if the interactions of SIEVE actions would be most clearly and 
concisely described with if-then-else pseudocode (and a definition of 
when that code runs))
(Continue reading)

Permalink | Reply | 751 comments |
headers
Internet-Drafts | 4 Apr 2005 21:52
Picon
Favicon

I-D ACTION:draft-ietf-sieve-vacation-01.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Sieve Mail Filtering Language Working Group of the IETF.

	Title		: Sieve Email Filtering:  Vacation Extension
	Author(s)	: T. Showalter, N. Freed
	Filename	: draft-ietf-sieve-vacation-01.txt
	Pages		: 12
	Date		: 2005-4-4
	
This document describes an extension to the Sieve email filtering
   language for an autoresponder similar to that of the Unix "vacation"
   command for replying to messages.  Various safety features are
   included to prevent problems such as message loops.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sieve-vacation-01.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request <at> ietf.org with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-sieve-vacation-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
(Continue reading)

Permalink | Reply | 0 comments |
headers
Mark E. Mallett | 5 Apr 2005 01:38

Re: I-D ACTION:draft-ietf-sieve-vacation-00.txt


On Thu, Mar 31, 2005 at 05:54:52PM -0800, ned.freed <at> mrochek.com wrote:
> > > (It is one thing when circumstances
> > > make it impossible, quite another where a standard in effect condones lazy
> > > implementation practices.)
> 
> > I humbly beg to differ about the lazy part.
> 
> Please reread my response more carefully. At no point did I say, or even imply,
> any laziness on your part.

I didn't take it the way you think I took it, apparently; conversely I
didn't intend to imply anything back.  I am saying that it's not
laziness at issue (nor do I think "condoning laziness" is a criteria to
use in making a judgement about anything-- at least not in a negative
way.  Laziness is behind a lot of positive things; regardless, I think
it's irrelevant here.)

And I do think we all attempt to read carefully.  That doesn't seem to
always keep me from being wrong though. :-)

> On the contrary, I fully acknowledged that there are
> going to be cases where the implementation won't know what all, or even some,
> of the addresses asssociated with the recipient are. And this is the primary
> reason for having an :addresses argument - so specific scripts can
> specify those addresses the implementation does not know about.

That's beside the point too, as I attempted to describe (in what you
referred to has beating a straw man).
(Continue reading)

Permalink | Reply | 0 comments |
headers
Alexey Melnikov | 5 Apr 2005 11:10
Favicon

Re: Working Group Last Call: draft-ietf-sieve-editheader-00.txt


Cyrus Daboo wrote:

> I would like to draw your attention to the following draft:
>
> <http://www.ietf.org/internet-drafts/draft-ietf-sieve-editheader-00.txt>

A little bit late comments:

 >5. Interaction with Other Sieve Extensions
 >
 >   Actions that create messages in storage or in transport to
 >   MTAs MUST store and send messages with the current set of
 >   header fields.

I am not sure I understand what is "in transport to MTAs", is this 
trying to say "in MTA's queue"?

 >   For the purpose of weeding out duplicates, a message modified
 >   by addheader or deleteheader MUST be considered the same as
 >   the original message.

Hmm, even if the scripts replaces the Message-Id header ;-)?

 >  For example, in an implementation that
 >   obeys the constraint in [SIEVE] section 2.10.3 and does not deliver
 >   the same message to a folder more than once, the following
 >   code fragment
 >
 >       keep;
(Continue reading)

Permalink | Reply | 6 comments |
headers
Arnt Gulbrandsen | 5 Apr 2005 13:07
Picon
Favicon
Gravatar

Re: Working Group Last Call: draft-ietf-sieve-editheader-00.txt


Alexey Melnikov writes:
> Cyrus Daboo wrote:
> >  For the purpose of weeding out duplicates, a message modified
> >  by addheader or deleteheader MUST be considered the same as
> >  the original message.
>
> Hmm, even if the scripts replaces the Message-Id header ;-)?

It seems to me that banning removal/addition of certain fields 
simplifies life a lot without removing significant benefit: Message-ID, 
Content-Type, Content-Transfer-Encoding and MIME-Version.

Modifying those four fields adds so many corner cases to the 
implementations. Do we have to go there? Is it perhaps better to just 
say "editheader operations MUST NOT modify those four fields"?

(Solving a difficult problem gives a certain satisfaction. But avoiding 
it can be good, too.)

Arnt
Permalink | Reply | 5 comments |
headers
Arnt Gulbrandsen | 5 Apr 2005 13:15
Picon
Favicon
Gravatar

Re: Working Group Last Call: draft-ietf-sieve-editheader-00.txt


Another minor point: If a message is rejected after being modified, 
which version of the message should be sent to the bounce address, the 
original message or the one with a modified header?

Sorry I didn't notice that until now.

Arnt
Permalink | Reply | 0 comments |

Gmane