Pop3 with Gmail?
Blitz3D Forums/Blitz3D Programming/Pop3 with Gmail?
| ||
| i tried that code in the archives for pop3 retrieval with my gmail account. It doesnt work. I think the problem is something about the SSL connection. I changed the port in the pop3 code to match with gmails but it still wont go through, doesnt even give me an error message. Is there any code that will let me do pop3 with a secure connection? |
| ||
| im not entirely sure thats the problem but im pretty sure. Also i need to mail an email using smtp but gmail needs authentication and there arent any email programs in the archives that implement authentication on outgoing mail. thanks |
| ||
| I think GMail doesn't allow pop3 or something... You have to download and install a patch in order to run Outlook with GMail. |
| ||
| GMail does support pop3 :P but unless you have SSL you cant retreive anything :P |
| ||
| http://gmail.google.com/support/bin/topic.py?topic=194 |
| ||
| gmail does support pop3 but you need ssl to download and you need to authenticate yourself to use the smtp server so is there any blitz code out there that can do this? could i modify current code from the archives to do this? |
| ||
| does anyone know how to do this? |
| ||
| You need to get the SSL key. |
| ||
| how do i get it and how would i use it in the code? Also how do i authenticate myself for smtp? |
| ||
| They might not want to give it to you though. |
| ||
| www.google.com Version 3 Serial Number: 20:F1:DA Certificate Signature Algorithm: PKCS #1 MD5 With RSA Encryption Issuer: E = server-certs@... CN = Thawte Server CA OU = Certification Services Division O = Thawte Consulting cc L = Cape Town ST = Western Cape C = ZA Subject's Public Key: 30 82 01 0a 02 82 01 01 00 cc 70 f7 93 c3 58 fd 28 6a c8 6c 6e 89 42 55 7d ad 56 88 d0 ee 51 5a f2 70 8f a5 64 f2 cf b7 10 6f 9f 00 c7 8b dc b6 72 22 79 e8 0e bf 03 de 02 50 3b 3b ca 4c da 55 b6 f4 1d a6 d3 3c 8b 45 f3 dd 65 e5 ce d7 a5 f9 36 72 08 52 6c d2 1d 37 9d 5a 26 c1 80 3a 81 b9 be 2b 70 37 d9 c3 dc eb 01 be 8b a6 a1 cc 5d 85 10 53 6e 8d 1c 2f ee 54 d2 79 51 2d 46 3e ce 7c b9 e2 a3 55 30 1f 29 8a f4 15 e0 ef 50 92 00 e4 58 6d 5d 8a 8c ba c9 1e 69 56 07 cb 0a 78 ec 97 59 34 3e 23 e2 64 08 ac 20 5e 7e 1e 1e 57 34 db 3e 1a d5 6c af 49 59 76 ad df ce 43 8b 12 3e e7 3f 73 75 75 a1 99 83 d2 15 be d5 6a e7 1b 05 99 24 48 2f 0a f7 a2 50 83 dd 88 2d 49 d3 17 a3 27 4d 19 62 38 2d 7a 06 d0 4e 0b 86 7f b5 29 e6 26 3a 88 35 e4 02 96 b6 e2 7c 44 d2 3d 81 88 c8 d4 aa c9 40 69 3e 4a be 7b 6d 02 03 01 00 01 Certificate Signature Value: bb 85 a6 15 02 f8 74 36 b6 0c 01 27 f8 75 90 9d ab 5f 7f 3c 3e 2b f7 80 74 31 77 6f d4 2f 85 a7 ca f5 be 9a b8 f3 66 ff 49 bb e3 9d 5b a4 79 30 41 b3 e1 23 79 08 b5 6a fc a5 b9 85 d0 4f d2 9f 82 a7 36 ed ae 65 c0 e3 2d 62 b9 8e 00 74 c4 ce 79 32 01 76 7f 1a fe c2 62 91 f5 1a c1 66 11 df 7a 0d 1a 13 26 76 15 3b 54 0a 4b d6 f4 c9 e1 cc 3b 59 d0 32 43 1f 14 ec 69 69 91 9d 7d 1b 12 61 Connection Encrypted: High-grade Encryption (AES-256 256 bit) SHA1 Fingerprint: F0:D4:17:B2:2D:F8:E9:C7:D4:A6:76:94:E4:22:2C:EA:6A:CD:43:73 MD5 Fingerprint: 75:25:47:53:92:67:0B:D8:1C:4E:E2:48:FD:55:07:B7 (I think this has to do with modifaction in transit) If you have Mozilla Firefox, double click the padlock pic in the address bar |
| ||
| MD5 (Message Digest Algorithm 5) is a cryptographic hash algorithm developed at RSA Laboratories. It can be used to hash an arbitrary length byte string into a 128-bit value. MD5's ancestors, MD2 and MD4 have been broken, and there are some concerns about the safety of MD5 as well. In 1996 a collision of the MD5 compression function was found by Hans Dobbertin (Hans Dobbertin, FSE'96, LNCS 1039). Although this result does not directly compromise its security, as a precaution the use of MD5 is not recommended in new applications. Highlights The hash function collisions recently discovered have minimal practical impact at this time due to the limitations discussed further. It is not clear that these research results can be turned into practical exploits on most typical uses of these hash functions, so there is no immediate need to replace hash algorithms. As a precaution, applications using a legacy hash function described as vulnerable should upgrade to the NIST-approved SHA1 or SHA2 family of algorithms (RSA Laboratories suggested a migration to SHA1 in 1996). Applications using SHA1 do not appear to be at risk, but conservatively, developers may also consider planning an upgrade to the SHA2 family in the next few years. Several results concerning the security of hash functions were presented at the CRYPTO 2004 conference Aug 16-19 in Santa Barbara, CA. Hash functions are primitives used in a variety of cryptographic constructions, and are designed to be both "one-way" and "collision resistant". A one-way hash function is one for which it is hard to find the input string x corresponding to the output string h(x). The attacks presented at the conference do not attempt to "invert" the hash functions in this way. Instead, the attacks aimed at producing a hash collision, i.e., finding distinct strings 'x' and 'y' such that h(x)=h(y). In practice it is more difficult to find "meaningful" collisions, where the two strings are not just any bit sequence, but are readable text. (Conservatively though, it is wise to assume finding such "meaningful" collisions is only slightly more difficult than finding arbitrary collisions. Importantly, the cryptanalysis presented at the conference has not led to any significant attack on the most widely used and standardized hash function, SHA1, although older hash functions, including MD5, are now considered to be broken. The ability to find a meaningful hash collision can result in security breaches. For example, if one could find two legal contracts that have the same hash value and hence have the same signature, an attacker could replace one document with the other, and in a court of law there would be an ambiguity about which contract was valid. The MD5 and SHA1 algorithms are two popular hash functions, although only SHA1 is now considered secure. The algorithms take an arbitrary input string, from an e-mail message to an operating-system file, and generate what should be a unique fingerprint. With a secure hash function, changing even one letter in the input file results in a completely different fingerprint. Security applications also rely on such fingerprints to be unique to certify that a software component is safe to execute. If a malicious attacker can generate the same fingerprint on a piece of software with a back door as already exists for a certified piece of code, substituting the malicious code would give the incorrect impression the alternate piece of code was safe to run. This type of attack is known as a second-pre-image attack, and such a collision is more difficult to find. Fortunately, the attacks presented at CRYPTO 2004 are not yet able to achieve such second pre-image collisions. Three separate groups of authors presented attacks on hash functions in the main sessions and in the more informal "rump session". Although each approach was distinct, they all can be considered to be refined applications of the techniques of differential cryptanalysis. The techniques and results of Eli Biham and Rafi Chen focused on finding SHA0 collisions, and Antoine Joux's work described how finding "multiple collisions" is not really harder than finding single collisions for Feistel type algorithms. Four Chinese cryptographers (Xiaoyun Wang, Dengguo Feng, Xuejia Lai and Hongbo Yu) focused on MD5. Both Biham and Joux had refereed papers in the conference, and used the rump session to discuss how their results were improved since their discovery last year. Although the Chinese group's methods also were submitted to the main conference, their techniques were not yet sufficiently complete or understandable at that time. Their results, focused on MD5, are more recent news, and were only presented at the rump session. The MD5 attacks were the most exciting ones, and had been independently confirmed by the time of the announcement. Certain implementation mistakes had caused some confusion among researchers during this verification process, but correct and full MD5 collisions can and have been efficiently found. Their approaches also apply to three other hash algorithms: HAVAL, MD4, and RIPEMD. The audience responded to the presentation of Feng, et al with a standing ovation, and the statement that MD4 collisions could be computed "by hand" was made for dramatic effect. While a significant milestone, the emergence of these attacks is not a sudden surprise, considering the longstanding warnings, and prior recommendations (since 1996) to use the more secure and standard SHA1. Biham's and Joux's methods yield full SHA0 collisions. SHA0 is a prior version of the SHA1 algorithm commonly used today; SHA0 was quickly retracted by the NSA once security flaws were noted shortly after the algorithm was issued. The replacement, SHA1, was designed to be immune to the suspected vulnerability to differential cryptanalysis that SHA0 has. Indeed, the attacks presented at the conference work poorly in trying to attack SHA1. At present, there are only attacks on "reduced round" versions of SHA1, which do not extend to the full version. Such purposefully weakened ciphers are never used in practice, but instead as a testing ground for cryptanalytic approaches. The most significant future threat to SHA1 may well be the increased cryptanalytic attention encouraged by the MD5 and SHA0 collisions. Although there has been a lot of publicity about these "breaks", the fact is that they can only be exploited in a very limited venue where an attacker can obtain a signature on a carefully constructed message resulting from a collision-search attack. How should implementers respond to this news? There is no need to panic, since it will likely be some time before the weak hash functions can be turned into practical exploits. However, applications using one of the legacy hash functions described as vulnerable should upgrade as soon as possible to the NIST - approved SHA1 or SHA2 family of algorithms (RSA Laboratories suggested a migration to SHA1 in 1996). Applications currently using SHA1 do not appear to be at risk, but conservatively, developers may also consider planning an upgrade to SHA2 in the next few years. |
| ||
| ok so what im understanding is that none of you know how to do it. |
| ||
| why are we talking about exploits and such, if outlook can connect to it then why cant we have code that does the same? |
| ||
| If you write a program to open https://gmail.com then it will have to some how give you the key |
| ||
| im not talking about opening http://gmail.com im talking about accessing it using pop3. If outlook and other pop3 programs can access mail then there must be a way. Does anyone know how to do this in blitz? |
| ||
| cmon people |
| ||
| I'd like to do this as well. I assume this is the same thing as 'authenticated smtp'. Does any have any idea where to start with this stuff? |
| ||
| i dont think anyone knows, the topics been up for about a week now |
| ||
| If someone would like to give me an invite to gmail so I can create an account, I'll happily knock up some code for you in either Blitz, VB or Delphi, which ever you prefer :) |
| ||
| If you know how to do it Qube could you explain what's involved or point me in the direction of the info? I'd like to do this myself but I'm a but stuck as to how to go about it. |
| ||
| Telnet to your smtp server, then go through the smtp commands that are available through searching for smtp protocol. This will allow you to know what to send to the smtp server and what to expect back, like +ok messages. Using Telnet you can test the smtp commands to be and messages coming back, then build your Blitz program from that. You MUST know what the gmail server is expecting, and how it expects your information to be sent. Most SMTP servers are standard (obviously), but it is good to know what messages to expect. |
| ||
| Invite Senty. I hope to see some code soon :D |
| ||
| Thanks Cygnus :) I'll sign up and get cracking - expect code in the next few days... |
| ||
| Cheers dude :D |
| ||
| Huh!. In Delphi & VB, no problems getting it to talk to GMAIL via POP3-SSL. Yay for professional RAD tools. Doing it all in Blitz code alone. Complete pain in the butt and way too much work writting POP3-SSL routines. Are you guys after Blitz code alone? or does it matter if there's a few DLL's involed? The easiest way (for me) is to create a delphi DLL and access that via Blitz. It won't be pretty, but it'll work. Unfortunately, when it comes to serious applications Blitz (increase grrrr value for Blitz+) just doesn't hack it. So... Would a DLL wrapped into Blitz hurt? |
| ||
| I don't see a problem using a DLL, so long as it doesn't bring up anything on screen. |
| ||
| I'd use the DLL, No problem. |
| ||
| I have a gmail too and i'm interested to make a program to read my mail. So, i'm interested in the solution: in wich way it is possible to use pop3 with gmail? |
| ||
| no one knows yet, qube disapeared. |
| ||
| I've not disappeared, lol. As getting a license free pop3-ssl routine wrapped into a DLL and working in Blitz is not a simple task, then its gonna take a while longer than I thought :( Also as I make my money programming and this is a long winded freebie then I can't dedicate hours and hours each day to it. So hold in there, it will arrive in a nag free, license free POP3-SSL blitzy thing. |
| ||
| *bump |
| ||
| lol, I'm still alive and doing it in my spare time. It's nowhere near as I thought as Blitz for this type of stuff just doesnt cut the mustard unfortunately. A simple stream is easy. A complete SSL stream is a pig to be honest. I've done this stuff many times before in Delphi (yay to ocx) but as Blitz doesn't support OCX I'm having to slowly wrap a DLL into it and its hard going. As my main time is spent writting apps for money and must come first, this crazy side project is slow going. But it'll get there. I did have a try at writting the SSL routines in pure Blitz but I burst out laughing for reasons I won't mention. Anyway, for a quick update, i'm wrapping a delphi DLL into blitz to handle the issue. All free for commercial use and nag free. All I'll want in return is if anyone uses it is to give credit somewhere in their game/app. Fair enough I think :) |
| ||
| It would be nice to have ssl dll so you could connect to https and other ssl things. |
| ||
| If you download Mozilla Firefox or Mozilla Thunderbird, there is a ssl3.dll in the root directory of it. |
| ||
| I think, you are talking about TLS (Transport Layer Security). You could use OpenSSL from http://www.openssl.org. Maybe you could use the openssl binary alone (not a clean way, but it should work) like mentioned on http://sial.org/howto/openssl/examples/. The cleanest way would be, however, to use the openssl dll api calls. |
| ||
| P.S. to try out openssl you could install cygwin with the openssl package (www.cygwin.com). But openssl can be compiled under win32 aswell, so you do not need the cygwin.dll for your project. |
   |