Re: POP3 maildrop size and message size

[Matt Madison <[e-mail]>]

John Gardiner Myers <[e-mail]> writes:
>I think the current specs quite clearly define the octet sizes as
>being exact values.

On the contrary, it does not do so "clearly".  Exactness is implied,
but "size" is not precisely defined. Is it simply the size as stored on the
server, or is it supposed to be the size as transferred to the client?
Does it include the CRLF's between lines, or not?  How about the extra
dots tacked onto the front of lines beginning with dots?

What I'm getting as is some leniency in the definition.  The main reason
for this is to alleviate what could be substantial, unnecessary, overhead
on the server end of things, because:

    1. Not all operating systems maintain file sizes in bytes.

    2. Not all maildrops are structured such that messages are stored
       in the same form as they will be transmitted -- for example,
       the local operating system might use just linefeeds to end
       lines, rather than CRLF's.

And to be a little more forward-thinking, what about message stores capable
of handling multimedia and multipart messages stored in a binary format?
Isn't it a little much to ask that POP servers built on these sorts of
message stores encode an entire maildrop in base64 (or whatever), just
to get the size?

After all, the exact size isn't needed for the purposes of the protocol -
a retrieved message is terminated with CRLF.CRLF.

If a client might need the exact size of a message, how about adding a
SIZE command to the protocol -- with appropriate definition of "size"
and appropriate admonitions about the possible overhead the use of
the command could incur?

-Matt