At 01:30 PM -0400 7/7/03, John Alton Tamplin wrote: > That's what sieve is for -- do it in the server and you won't have to > rely on a particular client doing it for you.
OTOH, if I do it in my client, then I don't have to rely on all the servers I have to deal with all running sieve. They don't, and so I can't count on it. I only mentioned the one server, but I'm not ready to count on it being the only server I ever deal with. I have a number of issues relevant to the way I set up my email, that are not relevant to the question at hand. > I disagree - it sounds like it would be defensible if Cyrus supported > storing such messages even though it is clearly recommended against by > the standard. If Eudora insists on storing such messages, it should >be > prepared to deal with a server that is unwilling to do so. Obviously there's a problem with the RFC in this case, in that it makes a recommendation to the client but no recommendation or requirement for the server. But the RFC clearly says that the client is allowed to store a non-RFC2822 message, if it has a valid reason. Nowhere do I see that it says the client should deal with the server refusing to handle cases which the RFC says the client is allowed to do. More importantly, I don't see that the Eudora people are going to think they should work around an IMAP server lacking a feature which the RFC says the client should be able to use, especially when they are claiming that other IMAP servers don't have this restriction. If I'm going to go back to Eudora and say they should change their code, I need a stronger analysis than just "I disagree" -- particularly when the RFC clearly says the client should be able to do this. > If you allow the IMAP server to store arbitrary data, it makes the >other > functions much more difficult I tried to make it clear that I do not consider storing a non-RFC822 message to be a valid reason, in the RFC2119 sense, to violate the "SHOULD". IMAP is designed for storing Internet email, and that requires at minimum RFC822. (RFC733, the RFC822 predecessor, is far to old to consider here. RFC822 is over twenty years old; RFC2822 is only two years old. We long ago reached that point where it's reasonable to assume that all Internet email is RFC822-compliant, but we just are not at the point where it's reasonable to assume that all Internet email is RFC2822-compliant.) > Allowing null characters in particular is problematic for any code >that > uses null-terminated strings for messages or parts of messages, and Using null-terminated strings with data that might contain nulls is problematic. > would require changing the code everywhere to use and pass the length >of > all the strings instead. You are basically saying that even if (emphasize "if") the code is clearly wrong, that it won't be changed because it's too difficult to write correct code? I don't follow this argument at all. This problem with null-terminated strings has been widely known since long before cyrus. > As far as STD0011 not being obsoleted, there are plenty of RFCs etc. > that are not obsoleted by something but are still not best current > practice. But it's very seldom that two years is considered an adequate transition. > Clearly if the RFC it has been based on has been obsoleted, > the STD should be updated as well. But rfc-editor.org says it hasn't been. I'd very much like to see more discussion on this, and not just a brush-off "that's not how we do it here". Edward