Problems with CPpop

[darsh]

i am using a proprietary mail fetching software for getting mails from my server. i tried to send a mail to my own account from a different account with attachment of 325kb but when i checked it in webmail it shows only 322kb. and because of this when my mail fetching software is fetching the mails from the server it drops the connection after getting 322kb(i dont know what happens but it doesnt downloads the entire attached file). is this a problem with CPPOP? how does CPPOP handles the mail attachments? does it compresses it by any mean?? is there any documentation available for CPpop???
i contacted the mail fetching software's vender. but he is not able to help. there seems to be very less or no docs available for cppop.
can anyone please help?

 

[shaun]

Have you tryed downloading the attachment to see if it's complete. You should look at the Actuall Bytes of a file to see if it's the same size, on diffrent Hard Drives KB & MB can vary alittle bit depending on the drive.

 

[darsh]

cppop

the problem is not in kb and mb.. the problem is even in no. of bytes being reported...

 

[bdraco]

http://www.faqs.org/rfcs/rfc1939.html

pop3 protocol doesn't even require that you return the number of bytes in the message, just the message itself.

So whoever wrote the mail fetch software is violating the RFC


[quote:f6e967c2ee]

RETR msg

Arguments:
a message-number (required) which may NOT refer to a
message marked as deleted

Restrictions:
may only be given in the TRANSACTION state

Discussion:
If the POP3 server issues a positive response, then the
response given is multi-line. After the initial +OK, the
POP3 server sends the message corresponding to the given
message-number, being careful to byte-stuff the termination
character (as with all multi-line responses).

Possible Responses:
+OK message follows
-ERR no such message

[/quote:f6e967c2ee]

PS. neomail/openwebmail has nothing to do with cppop as it reads the mbox right off the server

 

[darsh]

STAT command of POP3 protocol requires the message size in bytes to be returned, which needs to be the exact size of the message and not compressed or any other.
check the RFC link
check STAT command and its response and the requirement on it.
http://www.faqs.org/rfcs/rfc1939.html

 

[bdraco]

[quote:1e80c931dc][i:1e80c931dc]Originally posted by darsh[/i:1e80c931dc]

STAT command of POP3 protocol requires the message size in bytes to be returned, which needs to be the exact size of the message and not compressed or any other.
check the RFC link
check STAT command and its response and the requirement on it.
http://www.faqs.org/rfcs/rfc1939.html
[/quote:1e80c931dc]

Yup .. your right .. sorry about that .. is cppop returning an incorrect stat ?

 

[darsh]

yes it is

 

[darsh]

values of bytes are lesser then actual

the value of bytes (octets)in response to RETR and in response to STAT are less then the actual total mailboxsize.
does cppop compresses the mails somehow??

where can i contact the people who made cppop?

 

[rpmws]

[quote:e5e039e48f][i:e5e039e48f]Originally posted by darsh[/i:e5e039e48f]

the value of bytes (octets)in response to RETR and in response to STAT are less then the actual total mailboxsize.
does cppop compresses the mails somehow??

where can i contact the people who made cppop?
[/quote:e5e039e48f]

You have been sitting here talking to the guy who wrote it from scratch. &Bdraco& It's been in use for quite a while now on atleast what Nick? 300k domains?... I have had one client back 2 months ago tell me that he had a similiar problem. But not many complaints if any or Nick (Bdraco) would have fixed it. In fact as I write this I bet he already has.