Question

[David Mackintosh]

On Mon, Aug 02, 2004 at 11:32:43PM -0600, brad.mugleston at comcast.net wrote:
> 
> More update - talked with Comcast today - it was using some chat 
> software.  They swore that they didn't have a cap on down load 
> attached file size (well they do have problems at 3M and suggest 
> you break the file apart).
> 
> So, I tried it using OUTLOOK on my sons computer and it 
> downloaded a 300K file with no problems so it does seem to be 
> with fetchmail or something else on my system.
> 
> i'm runnim fetchmail (in a cron file) as 
> 	fetchmail -v -d 900 --fetchsizelimit 0
> 
> I just added the filesizelimit but it doesn't seem to help (zero 
> is suppose to mean no limit).
> 
> Didn't have any other time to play.
> 
> Any suggestions?
 
Here's a random suggesion -- is your provider using an exchange
server as your mail server?  Older versions of exchange used to lie
to pop and imap clients about the sizes of messages (exchange would
report the compressed size in its information store, not the number
of bytes to be transfered) -- and naturally Outlook can deal with
this brokenness.  Fetchmail used to have a switch to tell it that
it was dealing with a broken exchange server but I don't see it
quickly looking.

The other thing you can do is try another POP/IMAP client on your
linux system (Mozilla, KMail, Evolution -- take your pick) against
ComCast's server to see if there's something wrong with the
networking settings (MTU or something).  

-- 
 /\oo/\
/ /()\ \ David Mackintosh | Public Key: 
         dave at xdroop.com  | http://www.xdroop.com/dave/gpg.html
         $ gpg --recv-keys --keyserver subkeys.pgp.net 4C032504
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/redhat-install-list/attachments/20040803/c2fbf3a1/attachment.sig>