Since I'm currently looking for a new email client for a Win 7 system I'm exploring my options. I discovered that one candidate, Mailbird, does phone home. For me it is very hard to find such information. Searches generally yield results that discuss encryption and similar issues. My technical skills arent good enough to use stuff like Wireshark or whatever would be appropriate. 'if you are not paying, you are the product being sold' Anyone ? I don't need anything fancy, just something that works.
I guess it depends on what you mean by "phoning home".... almost any email client might check for updates... that's phoning home, but I would consider that harmless... what are you worried about?
Mailbird phones home. http://cubiq.org/the-best-and-the-worst-email-clients-for-windows Mixpanel, if that rings a bell. In the old days you either paid for a product or you used a product made by hobbyists. That's the sort of thing (or worse) I care about. I guess I'm old.
Thunderbird would be one option. Out of the box, it does phone home for several purposes (during email account configuration if online, for application and addon updates, blocklist retrieval, perhaps others I can't remember). However, like other Mozilla applications/derivatives, it has an extensive preference system which you can control via Tools->Options. The lower level about:config interface is accessible through Tools->Options->Advanced->Config Editor. It supports extensions, including some that control and/or display network traffic. It supports logging, which is another alternative to external traffic sniffing. WebBrowser functionality is built in, but you can configure/use it for standalone email work. Thunderbird/Firefox, FossaMail/Palemoon, TorBirdy/TorBrowser, SeaMonkey. Given the common heritage, much (but not all) of what you read about one will apply to the others.
Fighting "phoning home" at the app level is pointless, I think. Sisyphean. Better is just using VPN services and/or Tor for private stuff. Then phoning home isn't problematic.
@mirmir Had to look it up. Sis·y·phe·an ˌ/sisəˈfēən/ adjective adjective: Sisyphean (of a task) such that it can never be completed.
I think it is, if an app wants to grab your real ip address first (which any app can do from the system) and send it home the receiver gets the vpn ip address or the tor exit node ip address in the regular packet headers, plus your real IP address in the packets payload, this blows your anonymity out of the water right there. I have started looking at SELinux I was wondering whether it is workable to enforce permissions on user apps to prevent them accessing system level stuff that they have no legitimate reason to access.
Well, it's never prudent to use the same system for both sorts of work. For exactly that reason. Compartmentalize. Use at least VMs, and separate hosts when it really matters.
The simplest way to prevent an e-mail client from calling home is with a software firewall. Once installed, there's no reason that an e-mail client needs to connect to anything other than the e-mail servers that you use. Permit outbound to the IP of your mail servers. Restrict it to the required port and protocol. Then block everything else. You can even eliminate its need for DNS by putting the IP of the mail servers in your hosts file.
I think the software firewall approach is worthwhile. As a layer, anyway. Those that allow their email client to indirectly make use of other components/applications (simple example: passing a URL to external browser for opening) would have to take additional steps. This may hold in reverse as well. If an email program supports automation in a way that could allow another application to use it to silently send email out, that too would have to be addressed. Some points which we might consider covered by the earlier comment dealing with application permissions. Even if all of that is locked down, an email application will still be allowed to send info off machine. It is here that I would like to explicitly add: Be sure to investigate and inspect what it actually sends to the server (email, news if applicable, etc)... especially WRT protocol and header fields that aren't normally visible to the user. The HELO/EHLO command's domain or address literal, which is typically propagated all the way to the recipient via Received header, would be one example. There are a number of places where information can be leaked, including information which would be sufficient to burn *some* people who think they are adequately compartmentalized. I recall hearing of a case where some bad guys were zeroed in on with the help of a rigged client that leaked info through Message-ID generation algorithm. I shed no tears for them. However, I do shed tears for good people who become victims of technology they have little hope of ever understanding.
Ive just been building up a spare system after my main computer blew up the other day. Included in all that is getting Thunderbird set up again. The version I was on was 17. I installed from that version and in manually configuring it I was horrified to see the thing try and call home. It was something about an "ISP database" I thought what the heck is all that about? Yes its to help in the set up process, but I'm afraid that leaved me more than a little suspicious . Also, the chat was enabled by default phoning out as soon as the program was started. I'd shudder to think what the "latest and greatest" version does. Who on earth is going to forever carry on trying to keep up with the inordinate updating and changing of settings? I'm thinking of utilizing SeaMonkey's email when I get it installed again. I'm sure this will be a better option than what Firefox is doing. Exactly.... and therein lies the trap.
Well, just in case... https://mxr.mozilla.org/comm-centra.../prefs/content/accountcreation/emailWizard.js https://mxr.mozilla.org/comm-centra.../prefs/content/accountcreation/fetchConfig.js https://mxr.mozilla.org/comm-central/source/mailnews/mailnews.js Code: // where to fetch auto config information from. pref("mailnews.auto_config_url", "https://live.mozillamessaging.com/autoconfig/v1.1/"); // Added in bug 551519. Remove when bug 545866 is fixed. pref("mailnews.mx_service_url", "https://live.mozillamessaging.com/dns/mx/"); // Allow to contact ISP (email address domain) // This happens via insecure means (HTTP), so the config cannot be trusted, // and also contains the email address pref("mailnews.auto_config.fetchFromISP.enabled", true); // Allow the fetch from ISP via HTTP, but not the email address pref("mailnews.auto_config.fetchFromISP.sendEmailAddress", true); pref("mailnews.auto_config.guess.enabled", true); If someone does find a Mozilla derivative appealing, I would suggest they *try* to use a newer if not newest version and disable the features they do not want. Because security fixes.
My technical skills aren't what they used to be. Usually you just permit the software client to allow outbound connections ? For sending mail ? I could try getting the IP of the mail servers of my ISP, but I'm not such how stable that is, if they are willing to give that out. For a setup with Eset Smart Security, is there is simple way to do this ?
Outbound connections are all that's required for a mail client. I'm not familiar with Eset. I can't advise regarding specific settings, but if the mail client isn't already permitted access, the firewall should tell you where it's trying to connect to, either as an IP address or a server name. Depending on the e-mail service the server for outbound mail might have a different IP address and name than the inbound server. A utility like TCPView will show you the IPs if you have it running when you check and/or send mail. For the most part, e-mail clients get the IP of the mail server through the DNS service, same as the browser. You can either allow it to do so or you can add the server names and IPs to your hosts file.