ietf-mta-filters
[Top] [All Lists]

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

2005-04-04 16:38:06

On Thu, Mar 31, 2005 at 05:54:52PM -0800, 
ned(_dot_)freed(_at_)mrochek(_dot_)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).  


  [ some stuff removed for the reason mentioned below ]

In any case, since RFC 3834 only makes this a SHOULD-level thing, I guess I
could live with changing the MUST to a SHOULD if there's a consensus
to do so. I'm not seeing the consensus, however.

So back to the specific recommendation: if you have the envelope
recipient address available, IMHO the spec should allow you to make use
of it in this test;

"Allowing it" equates to a MAY, and a MAY is a violation of RFC 3834.
I think there is broad agreement that we need to be at least as stringent
as RFC 3834.

I have no desire to change the MUST NOT to a SHOULD NOT; and I would
find no happines in that "MAY."  I am in full support of stongly
checking these received headers as your draft suggests.  I'm having a
hard time understanding how your responses have much to with my response,
which tells me that I haven't said something correctly.

With that, and the fact that I see a new rev out, it's probably best to
move on to a fresh look at that new draft.

Yours,
-mm-


<Prev in Thread] Current Thread [Next in Thread>
  • Re: I-D ACTION:draft-ietf-sieve-vacation-00.txt, Mark E. Mallett <=