APPEND vs RFC2822 vs STD0011

[Edward Reid]

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