Cleancode.org >> Projects >> email

January 4th 2009 : 3.1.2 Released - posted by dean
A quick update release to fix an issue with using an external editor in Cygwin and also adding an option (--no-encoding) to let people avoid UTF-8 encoding of non ASCII characters.

January 3rd 2009 : 3.1.1 Released - posted by dean
This release just addresses some compilation issues that people were having. If you experience anymore compilation issues, please let me know as I only have Debian and Mac OS X to test on.

January 3rd 2009 : Using Gmail - posted by dean
I have had a lot of e-mails lately about people wanting to use eMail with Gmail. They seem to be having an issue using it over port 465. For those that don't really care and want it to just work, use either port 25 or 587. Port 465 is considered a legacy port. For those that want more information, read below.

eMail has support for TLS which is the new standard for secure SMTP communications. TLS is basically SSL communications but it provides a new way to allow both unsecure and secure communications to an SMTP server. With TLS, a client connects and is greeted by the SMTP server over an unsecured link. This allows clients that are not TLS/SSL compliant to query the server and ask what it's able to do. Most TLS capable servers will only allow you to query it for supported technologies. Usually, if the server reports back "STARTTLS", that means you must establish a secure connection with the server before you can actually send mail. For instance:

chloe:src dean$ telnet smtp.gmail.com 25
Trying 209.85.133.109...
Connected to gmail-smtp-msa.l.google.com.
Escape character is '^]'.
220 mx.google.com ESMTP d35sm25072600and.5
ehlo dean
250-mx.google.com at your service, [24.99.212.73]
250-SIZE 35651584
250-8BITMIME
250-STARTTLS
250 ENHANCEDSTATUSCODES

You can see that I telneted to port 25 on smtp.gmail.com and issues the EHLO command, gmail sent me back a list of technologies it supports. One of them is STARTTLS. At this point, I would issue the STARTTLS command and create a secure connection with the server using SSL.

However, the old way of doing this was by using SSL1 or SSL2. This was more similar to how HTTPS works. In order to make it work you had to connect to a dedicated port (usually 465) and immediately negotiate a secure connection. So if you telnet to smtp.gmail.com on port 465, you will not see a greeting like I did above.

Neither one of these are "less secure" than the other. They just go about doing things differently. TLS allows for a little more flexibility in that non TLS capable clients can still check a server to see if they can send mail through it while the legacy SSL way requires a secure connection first.

eMail only support TLS while some other mail clients that have been around longer and initially had the old SSL support before TLS came around may support both and so you may be able to use both port 465 and 587 with some other mail clients. However, TLS is the RFC compliant standard for secure communications with SMTP servers and more mail clients will be incorporating this and the old SSL way will eventually be removed as it is, since the TLS standard was written, deprecated.

Since I have no desire to write in support for deprecated technology, only TLS will be available in eMail unless I get a sudden outcry of individuals that just simply can't change the port number to 25 or 587 for some reason. So, to move on, start using TLS port 25 or 587 with eMail and even you other mail clients. The future will thank you. :)

November 29th 2008 : New release 3.1.0 - posted by dean
Version 3.1.0 is released today and fixes some big bug issues and adds a few features.

- Added UTF-8 support for headers and message
- Added a timeout option
- Fixed bug that was causing 100% CPU usage on some mailings
- Fixed the "No SMTP Server specified" issue that existed on 64bit and Solaris systems.
- Fixed issue where mime types weren't being guessed correctly or the mime type was coming out blank.
- Added VCARD support.

September 21st 2008 : Mac OS X PPC issues - posted by dean
I got an e-mail from a Mac OS X user that told me that compiling eMail on a PPC Mac causes compilation issues. The errors stem from compiling dnet.c in dlib and it seems to have an issue with the dsocket struct. His set up is Mac OS X 10.5.5, gcc 4.0.1, PPC hardware.

If you have a Mac with OS X 10.5.5 sitting on the PPC platform and you have some programming skills, help us figure this one out. I have a Mac myself, but compilation works absolutely fine on the Intel platform for some strange reason...