Page 8 of 15 FirstFirst ... 345678910111213 ... LastLast
Results 141 to 160 of 297
  1. #141  
    Originally posted by Dan Harkless

    I'm not familiar with this issue. Does the Sprint mail server repackage attachments in received mails into Windows .CAB format or something??
    Yes. Sprint puts files like docs, xls, etc. attached to email into compressed cabs (except for jpg, gif and some others). This is for any email account not just the Sprint email. Pain in the ****.
  2. #142  
    Originally posted by manorton
    Yes. Sprint puts files like docs, xls, etc. attached to email into compressed cabs (except for jpg, gif and some others). This is for any email account not just the Sprint email. Pain in the ****.
    Eh? What do you mean it's "for any email account"? The only way Sprint could affect your other email accounts would be if they intercepted your POP3 transmissions and silently rewrote the data before it got to you, and I'm sure that's not going on...
  3. #143  
    Originally posted by Dan Harkless
    Eh? What do you mean it's "for any email account"? The only way Sprint could affect your other email accounts would be if they intercepted your POP3 transmissions and silently rewrote the data before it got to you, and I'm sure that's not going on...
    Apparently, that is exactly what they are doing. Irrespective of the POP and SMTP servers you may use, you are still passing through the SprintPCS infrastructure. Word has it that they are changing this.
  4. #144  
    Originally posted by millerhifi


    Check out 2bAnywhere, also in beta right now but looks very promising!

    http://www.2banywhere.com/welcome.htm
    Download page says it requires 30mb harddisk space on the desktop. Is that for a conduit or something else?
    David
  5. #145  
    Originally posted by drw

    Download page says it requires 30mb harddisk space on the desktop. Is that for a conduit or something else?

    I tried to register for this 2banywhere and it won't accept mine. I have a Treo 300 and it keeps bouncing me back to the form telling me to fill out all fields?
  6. #146  
    Did you fill out all of the fields?
  7. #147  
    Worked fine for me. Go to their web site. They have a Yahoo discussion forum.
  8. #148  
    Yes I filled out the form repeatedly. There is no option for SprintPCS or CDMA ... so I chose "Other"... maybe that's the problem?
  9. #149  
    Bingo Cingular is not an option either, just put other...
  10. #150  
    The procedure for this has been documented on 2bA's Yahoo discussion group. What I did was click "GSM/GPRS" and specify "other" as the carrier. The software doesn't care about these things. Worked for me.
  11. #151  
    Got registered ... got it working. LOVE IT! I will be anxious to find out what they will charge for the service ... and when some missing features will be implemented like the SMS notification.

    In the meantime I think it is great.

  12. #152  
    Originally posted by Maniac8888
    'quote:
    --------------------------------------------------------------------------------
    Originally posted by Dan Harkless
    Eh? What do you mean it's "for any email account"? The only way Sprint could affect your other email accounts would be if they intercepted your POP3 transmissions and silently rewrote the data before it got to you, and I'm sure that's not going on... '

    Apparently, that is exactly what they are doing. Irrespective of the POP and SMTP servers you may use, you are still passing through the SprintPCS infrastructure.
    I have to say I'm very skeptical. I can't imagine them doing something this intrusive and such a potential invasion of privacy without at least documenting it prominently somewhere. Do you have a link to their website confirming this policy?

    I mean, it doesn't even make sense. I can understand wanting to decrease bandwidth, but it makes no sense to use a proprietary Windows archive format, when they know they have very definitely non-Windows devices like the Treo as probably the most common attachment-capable email clients on their network.

    If this is going on, one way to prevent it would be to use an email provider (and client program) that has POP3S capability. With an encrypted connection, there's no way Sprint could get their hooks into it.

    However, I'm still unconvinced that this is going on. My mail server usually only responds to POP3 queries on the POP3S port, 995, but I temporarily turned on port 110 and made a temporary account whose password I didn't mind sending over the network in cleartext. I then sent that account a MIME-attached Word document and picked the mail up with Eudora on my Treo, setting it to use no encryption.

    Looking at the mail in Raw mode, I can see that the attachment was not munged -- the BASE64-encoded data is unchanged (checked the first few lines), the filename is unchanged (no .cab), and the MIME type is unchanged (still application/msword).

    Is whoever is seeing this .cab-creation behavior definitely using a mail client that connects directly to your POP3 server, and not one that uses a proxy, like 2bAnywhere, Aileron, Basejet, Business Connection, Inbox To Go, Gopher King, and TreoMail do? (Or using a real mail client but setting it up to pull from pop.sprintpcs.com and setting up your Sprint mail account to pull from your actual account?)
    Last edited by Dan Harkless; 12/13/2002 at 04:02 PM.
  13. #153  
    Originally posted by Dan Harkless


    <snip>

    Do you have a link to their website confirming this policy?

    <snip>

    I first saw this problem posted by one of the SnaperMail developers on their Yahoo Forum. They were having problems both reading and passing along doc attachments to third-party applications and they reported their investigations on the matter.

    I have been looking at this myself off and on for a few days because I am as scepticle as you but do not have enough information yet render an opinion other than to say Sprint acknowledges this is happening (at least to me) and it will go away "soon."
  14. #154  
    I use 2beanywhere. Its in beta right now so its free. I check my pop3 and hotmail on it. You can check up to 10 mialboxes
  15. #155  
    Originally posted by Maniac8888
    I have been looking at this myself off and on for a few days because I am as scepticle as you but do not have enough information yet render an opinion other than to say Sprint acknowledges this is happening (at least to me)
    Where did they acknowledge it?

    and it will go away "soon."
    As I said, in my test just now, no rewriting of the Word attachment occurred, so it may be that if this was happening, it has already gone away.
  16. #156  
    That seems to be an accurate statement. It looks like a doc attachment to me too. Please pass this along to Snapermail as they insist it is a cab file with a .doc suffix and SM can't open it.

    BTW, Sprint only told me this on the phone (tier II).

    Out of curiousity, how did you verify that the attachment was a real, honest-to-goodness doc file?
  17. #157  
    Originally posted by Maniac8888
    That seems to be an accurate statement. It looks like a doc attachment to me too. Please pass this along to Snapermail as they insist it is a cab file with a .doc suffix and SM can't open it.

    BTW, Sprint only told me this on the phone (tier II).

    Out of curiousity, how did you verify that the attachment was a real, honest-to-goodness doc file?
    My main mail client is nmh, a UNIX commandline suite. It allows you to see the literal BASE64-encoded data after you do a MIME attachment. I simply checked that the BASE64 data I saw in Raw mode on Eudora matched what it did prior to sending the mail.

    It occurred to me a few minutes ago, though, that Eudora's behavior where it fetches messages in chunks up to 999 lines long may have been stymying this alleged CAB file munging (certainly it would be extremely impractical and challenging to write this supposed man-in-the-middle munging to allow for chunked retrieval). Therefore I used Mocha Pocket Telnet to connect directly to my port 110 and issued a "RETR 1" to download the message in "one swell foop."

    I couldn't verify that the first few BASE64-encoded lines were the same, since the data scrolls by too quickly and Pocket Telnet has neither a scroll lock nor a scrollback buffer, but I was able to wait until the ~500K message had done being output (took a couple of minutes) and then I was able to check that the last 20 lines or so of the BASE64 data matched what they did in nmh prior to sending the mail. They did.
  18. #158  
    I confirm your findings. Doc files ARE NOT encapsulated as CABs going through the the SprintPCS infrastructure. I did not test using with Sprint POP3/SMTP servers.
  19. #159  
    All of the 2.5G and 3G networks employ these image compressors on their Internet access points. They usually have them turned off on WAP access but turn it on for data card access and for PDA browsing access. T-Mobile definitely has this on its network and I am pretty certain that Sprint PCS has a compressor too but I think it is only compressing PNG, JPG and GIF images at the moment. T-Mobile has a website you can go to to turn it off but I dont believe that Sprint offers this option. It would be very useful for mail application developers to have all this documented somewhere by Sprint.
  20. #160  
    Originally posted by Poryphyron
    All of the 2.5G and 3G networks employ these image compressors on their Internet access points. They usually have them turned off on WAP access but turn it on for data card access and for PDA browsing access. T-Mobile definitely has this on its network and I am pretty certain that Sprint PCS has a compressor too but I think it is only compressing PNG, JPG and GIF images at the moment. T-Mobile has a website you can go to to turn it off but I dont believe that Sprint offers this option.
    Wow, you're right! I just did a test with EudoraWeb, which, unlike Blazer and Xiino, doesn't use its own content-munging proxy, but rather connects directly to the site, so is usable for this test, and when I downloaded a 55K JPEG (entering its URL manually), it downloaded only 19K (of binary gunk, since it doesn't have image support).

    When I downloaded an 87K GIF, it showed the length as only 78K on the download progress line (and then crapped out around 30K, which is apparently as big a file as EudoraWeb can handle).

    However, this does not appear to occur for PNG files (at least the non-color-table PNG I tried), as I tried to download a 364K file, and EudoraWeb showed its full original size, before crapping out at 30K.

    Note that I retried downloading the GIF and JPEG over an https connection, and as expected, the encryption prevented Sprint from munging the image files -- the full original sizes were reported.

    Just to be sure Eudora wasn't secretly using a proxy or something, I tried connecting to my web server's port 80 using Mocha Pocket Telnet, and issued a HEAD command on the above-mentioned GIF file, and the HTTP headers showed the full 87K size. I then tried a GET, and after wading through a ton of weird:

    Telnet Error
    Error: TCPIP DOWN ()
    popups from Pocket Telnet, I saw that even with a GET, the headers showed the full 87K length. This is pretty unexpected. I would be surprised if Sprint's proxy would be written to shrink the images but then not update the length in the headers, as browsers could have errors in this case. It also wouldn't explain how EudoraWeb knew the reduced size of the file prior to it finishing downloading.

    But whatever is indicated by the failure to see the munging in the headers with Pocket Telnet, the definitive proof that Sprint does have a transparent proxy in the mix here came because Pocket Telnet, unlike most telnet clients, has no option for local echo. Therefore, if you connect to a port other than telnet or ssh, you can't see what you're typing. I mistyped an HTTP request, and I got back:

    HTTP/1.0 400 Bad Request
    Server: WebProxy/1.0
    ...
    rather than it reporting itself as Apache as it would have if it were really my server responding.

    It would be very useful for mail application developers to have all this documented somewhere by Sprint.
    Well, I've proven that Sprint is operating a man-in-the-middle HTTP proxy, but that doesn't necessarily mean they're doing the same for POP3. Certainly it's easier to munge an image that's requested on its own TCP connection than to munge a file that's MIME-embedded into an email. With email they'd have to be sure not to screw up the email's standards compliance, and make sure not to mess up POP3 server state information. But now that I see that they are silently munging HTTP-transferred images, I am more inclined to believe they're monkeying with POP3 emails as well. I just wasn't able to see it in my testing, unlike with the HTTP case.

    In any case, yeah, extremely bogus if they don't publicly document somewhere the details of whatever content-munging proxies they've got in place...
    Last edited by Dan Harkless; 12/14/2002 at 09:33 AM.
Page 8 of 15 FirstFirst ... 345678910111213 ... LastLast

Posting Permissions