POP3 LIST Command
am 23.08.2006 06:04:22 von Jon BerryThe POP3 LIST command displays a message number and the number of octets.
What are octets?
How can I convert octets to bytes?
Jon
The POP3 LIST command displays a message number and the number of octets.
What are octets?
How can I convert octets to bytes?
Jon
On comp.mail.misc, in
Correction: Someone who _sometimes_ calls himself "Jon Berry" wrote:
> Path: text.usenetserver.com!atl-c01.usenetserver.com!news.usenetse rver.com!atl-c05.usenetserver.com!news.usenetserver.com!post news.google.com!news4.google.com!newshub.sdsu.edu!elnk-nf2-p as!newsfeed.earthlink.net!stamper.news.pas.earthlink.net!new sread4.news.pas.earthlink.net.POSTED!ccab4afb!not-for-mail
> From: Jon Berry
No rank newbie would know enough to munge his From header's
email address like that.
http://groups.google.com/advanced_group_search
Jon Berry
Results 1 - 12 of 12 posts in the last year
1 austin.food
1 borland.public.jbuilder.ide
1 borland.public.jbuilder.micro.mobileset
1 comp.mail.sendmail
That's an MTA (mail server). Not Windows, either. Linux/Unix.
Strangely out of place on this list.
1 comp.music.midi
1 comp.sys.ibm.pc.hardware.systems
1 ibm.software.websphere.studio.device-developer
1 microsoft.public.dotnet.framework
1 microsoft.public.dotnet.framework.interop
1 microsoft.public.dotnet.framework.setup
2 microsoft.public.dotnet.languages.csharp
That's not the posting history of a rank newbie, either. This
guy knows the Usenet very well indeed.
Obviously, this is a troll's sockpuppet.
> User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
I doubt it. No Usenet pro would use that piece-of-crap
newsreader.
> X-Accept-Language: en-us, en
> MIME-Version: 1.0
> Newsgroups: comp.mail.misc
> Subject: POP3 LIST Command
Yes. POP3 has a LIST command. Quite a few others, too.
TOP is my favorite.
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> Content-Transfer-Encoding: 7bit
> Lines: 7
> Message-ID:
> Date: Wed, 23 Aug 2006 04:04:22 GMT
> NNTP-Posting-Host: 24.206.115.37
> X-Complaints-To: abuse@earthlink.net
> X-Trace: newsread4.news.pas.earthlink.net 1156305862 24.206.115.37 (Tue, 22 Aug 2006 21:04:22 PDT)
> NNTP-Posting-Date: Tue, 22 Aug 2006 21:04:22 PDT
> Organization: EarthLink Inc. -- http://www.EarthLink.net
> Xref: usenetserver.com comp.mail.misc:160233
> X-Received-Date: Wed, 23 Aug 2006 00:04:23 EDT (text.usenetserver.com)
http://slrn.sourceforge.net/docs/README.offline>
Don't help trolls. Especially trolls interested in MTAs, which
generally means _spammer_. Or wannabee spammer.
And I wouldn't want one to understand POP3 servers either.
Bet he has a sig written to make everyone think he hates spam.
Note: I won't be downloading any articles on this thread.
Alan
--
If you don't have the integrity to post under a single, unique
alias, without the "X-No-Archive: yes" header, than I won't
download your articles nor any responses to them. Yes, I can
tell. See my headers for personal info.
Post removed (X-No-Archive: yes)
On Wed, 23 Aug 2006, Jon Berry wrote:
> What are octets?
> How can I convert octets to bytes?
For your purposes, you may consider "byte" and "octet" to be synonyms.
Before anyone jumps on me for having said the above: this is not
technically true. I probably have more (33+ years) first-hand knowledge
of the difference than almost any other individual currently reading this
newsgroup. In brief:
. an octet is a collection of 8 persons or things. In computing, an
octet is a 8-bit value.
. a byte is a group of bits, not necessarily 8 bits. 8 bits is
indisputably (and overwhelmingly) the most common bytesize.
It is therefore more precise to refer to 8-bit values as "octets" instead
of "bytes". All octets are bytes, but not all bytes are octets.
Internet standards documents always refer to octets and not bytes. In
general, these documents avoid the use of the word "byte" entirely in
favor of terms (such as "octet", "4-bit value", "16-bit value", etc.)
which specifically and unambiguously define the size of the object.
Unless you deal with programming in certain arcane contexts, you can
largely disregard the difference between octet and byte, as long as you
remember that octet is the more precise term.
-- Mark --
http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.
Mark Crispin wrote:
> On Wed, 23 Aug 2006, Jon Berry wrote:
>
>> What are octets?
>> How can I convert octets to bytes?
>
>
> For your purposes, you may consider "byte" and "octet" to be synonyms.
Thanks for the reply.
Does the number of octets returned from the LIST command refer to the
entire message (including headers) or just the body of the message?
I seem to be having a problem coming up a little "short" when I try to
read in a byte stream using the RETR command based on the size returned
from LIST.
Jon
On Wed, 23 Aug 2006, Jon Berry wrote:
> Does the number of octets returned from the LIST command refer to the entire
> message (including headers) or just the body of the message?
> I seem to be having a problem coming up a little "short" when I try to read
> in a byte stream using the RETR command based on the size returned from LIST.
RFC 1939 (the POP3 specification) requires that the octet count be exact.
This requirement is often violated by certain POP3 server implementations.
Unlike IMAP, which has protocol-level dependencies on its octet counts
being exact, POP3 and NNTP have a tradition of such counts being advisory
estimates and often quite inaccurate.
There was an attempt to require exact counts in updates to the POP3 and
NNTP specifications. The attempt succeeded with POP3 in RFC 1939; but as
noted above some servers still don't comply.
-- Mark --
http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.
Mark Crispin wrote:
> RFC 1939 (the POP3 specification) requires that the octet count be
> exact. This requirement is often violated by certain POP3 server
> implementations.
That seems to be the case.
Do you recommend reading the stream line by line?
Also, this particular server always deletes a message after the RETR
command is used, even if I use a RSET command before QUIT.
I would like the messages to remain on the server.
Is there a way to use TOP to retrieve the entire message?
I have noticed that clients such as Mozilla Thunderbird are able to
retrieve message on this server without setting the delete flag, but I'm
not sure how they are doing it.
Regards,
Jon
This is a MIME GnuPG-signed message. If you see this text, it means that
your E-mail or Usenet software does not support MIME signed messages.
The Internet standard for MIME PGP messages, RFC 2015, was published in 1996.
To open this message correctly you will need to install E-mail or Usenet
software that supports modern Internet standards.
--=_mimegpg-commodore.email-scan.com-29787-1156376486-0002
Content-Type: text/plain; format=flowed; charset="US-ASCII"
Content-Disposition: inline
Content-Transfer-Encoding: 7bit
Jon Berry writes:
> Mark Crispin wrote:
>
>> RFC 1939 (the POP3 specification) requires that the octet count be
>> exact. This requirement is often violated by certain POP3 server
>> implementations.
>
> That seems to be the case.
>
> Do you recommend reading the stream line by line?
Of course. Don't forget to undo the dot-stuffing, and watch for a line with
a lone dot.
> Also, this particular server always deletes a message after the RETR
> command is used, even if I use a RSET command before QUIT.
Obviously it's broken, then. It fails to meet the technical definition of a
POP3 server.
> I would like the messages to remain on the server.
>
> Is there a way to use TOP to retrieve the entire message?
Try passing a ridiculously high body line count.
> I have noticed that clients such as Mozilla Thunderbird are able to
> retrieve message on this server without setting the delete flag, but I'm
> not sure how they are doing it.
It is highly unlikely that Mozilla is doing anything other than issuing a
RETR command, so I'm a bit skeptical about your claim that the server
deletes downloaded messages automatically. The only theory that might fit
all available facts is Thunderbird just closing the server connection
without even sending a QUIT, and the server does not delete message if the
connection gets closed in this fashion.
Try closing the network connection without sending a QUIT command, and see
what happens.
--=_mimegpg-commodore.email-scan.com-29787-1156376486-0002
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
iD8DBQBE7Oemx9p3GYHlUOIRAiYbAJ9HP7qNbh2hu/P1RQ193EHLkZ+ZmwCf aopA
LOSsNNg3w5N7daEkY7HzwfQ=
=fIVb
-----END PGP SIGNATURE-----
--=_mimegpg-commodore.email-scan.com-29787-1156376486-0002--
On Wed, 23 Aug 2006, Jon Berry wrote:
> Do you recommend reading the stream line by line?
Yes. That is the intended way that POP3 protocol engines work.
> Also, this particular server always deletes a message after the RETR command
> is used, even if I use a RSET command before QUIT.
That is non-compliant behavior. A message must not be deleted unless a
specific DELE command is issued; and a server must respect the RSET
command and cancel and DELE.
Sadly, I have seen servers that do this.
To put it bluntly, such behavior is evil. Only fascist pigs, who don't
understand what "service provider" means, would even think of doing such a
thing. The appropriate customer response is to fire that ISP and use one
that treats their customers (and published standards!) with respect.
> I would like the messages to remain on the server.
> Is there a way to use TOP to retrieve the entire message?
The only way that I can think of is to use TOP with a very large value.
However, as TOP is optional-to-implement in the POP3 specification, this
is not a guaranteed solution.
> I have noticed that clients such as Mozilla Thunderbird are able to retrieve
> message on this server without setting the delete flag, but I'm not sure how
> they are doing it.
I have two guesses.
First is your suggested kludge of using the TOP command.
Second is for the client to disconnect without issuing a QUIT. Perhaps if
the server thinks that the client crashed, it won't do the evil delete
behavior.
I don't consider either to be good behavior on the part of the client; but
when faced with evil you may have no choice.
-- Mark --
http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.
Mark Crispin wrote:
> The only way that I can think of is to use TOP with a very large value.
> However, as TOP is optional-to-implement in the POP3 specification, this
> is not a guaranteed solution.
Yes, this works. So far, the highest value I have tested that works is
10 million. 100 million gave an error.
Do you guys happen to know the maximum value I could use with TOP?
Is it dependent on the server?
> Second is for the client to disconnect without issuing a QUIT. Perhaps
> if the server thinks that the client crashed, it won't do the evil
> delete behavior.
This works also. This may be the best solution if you're saying that
TOP is not guaranteed to be implemented...
It would be nice to know how the popular email clients handle this when
you select "Leave email on server".
Perhaps I should go ahead an issue an RSET and then close the connection
without doing a QUIT.
Jon
On Thu, 24 Aug 2006, Jon Berry wrote:
>> The only way that I can think of is to use TOP with a very large value.
>> However, as TOP is optional-to-implement in the POP3 specification, this is
>> not a guaranteed solution.
> Yes, this works. So far, the highest value I have tested that works is 10
> million. 100 million gave an error.
> Do you guys happen to know the maximum value I could use with TOP?
The POP3 specification is silent on the magnitude of the lines argument to
TOP. It only says that it is a non-negative number.
> Is it dependent on the server?
Yes. UW ipop3d (which I wrote) allows up to 4,294,967,295.
>> Second is for the client to disconnect without issuing a QUIT. Perhaps if
>> the server thinks that the client crashed, it won't do the evil delete
>> behavior.
> This works also. This may be the best solution if you're saying that TOP is
> not guaranteed to be implemented...
I agree.
> It would be nice to know how the popular email clients handle this when you
> select "Leave email on server".
Supposedly, all that clients need to do is refrain from issuing a DELE
command.
> Perhaps I should go ahead an issue an RSET and then close the connection
> without doing a QUIT.
Be careful about what you assume. The manager of that server clearly
intended to sabotage "leave mail on server". If it dawns on him that you
are evading his evil policy in this way, he may close that loophole.
The manager of that server clearly intends that you not be allowed to
"leave mail on server". You should keep that in mind.
-- Mark --
http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.