The reports of the death of automotive AM radio may have been greatly exaggerated. Regular readers will recall us harping on the issue of automakers planning to exclude AM from the infotainment systems in their latest offerings, which doesn’t seem to make a lot of sense given the reach of AM radio and its importance in public emergencies. US lawmakers apparently agree with that position, having now introduced a bipartisan bill to require AM radios in cars. The “AM for Every Vehicle Act” will direct the National Highway Transportation Safety Administration to draw up regulations requiring every vehicle operating on US highways to be able to receive AM broadcasts without additional fees or subscriptions. That last bit is clever, since it prevents automakers from charging monthly fees as they do for heated seats and other niceties. It’s just a bill now, of course, and stands about as much chance of becoming law as anything else that makes sense does, so we’re not holding our breath on this one. But at least someone recognizes that AM radio still has a valid use case.
Despite the popularity of social media, for communication that actually matters, e-mail reigns supreme. Crucial to the smooth operation of businesses worldwide, it’s prized for its reliability. Google is one of the world’s largest e-mail providers, both with its consumer-targeted Gmail product as well as G Suite for business customers [Jeffrey Paul] is a user of the latter, and was surprised to find that URLs in incoming emails were being modified by the service when fetched via the Internet Message Access Protocol (IMAP) used by external email readers.
This change appears to make it impossible for IMAP users to see the original email without logging into the web interface, it breaks verification of the cryptographic signatures, and it came as a surprise.
For a subset of users, it appears Google is modifying URLs in the body of emails to instead go through their own link-checking and redirect service. This involves actually editing the body of the email before it reaches the user. This means that even those using external clients to fetch email over IMAP are affected, with no way to access the original raw email they were sent.
The security implications are serious enough that many doubted the initial story, suspecting that the editing was only happening within the Gmail app or through the web client. However, a source claiming to work for Google confirmed that the new feature is being rolled out to G Suite customers, and can be switched off if so desired. Reaching out to Google for comment, we were directed to their help page on the topic.
The stated aim is to prevent phishing, with Google’s redirect service including a link checker to warn users who are traveling to potentially dangerous sites. For many though, this explanation doesn’t pass muster. Forcing users to head to a Google server to view the original URL they were sent is to many an egregious breach of privacy, and a security concern to boot. It allows the search giant to further extend its tendrils of click tracking into even private email conversations. For some, the implications are worse. Cryptographically signed messages, such as those using PGP or GPG, are broken by the tool; as the content of the email body is modified in the process, the message no longer checks out with respect to the original signature. Of course, this is the value of signing your messages — it becomes much easier to detect such alterations between what was sent and what was received.
Understandably, many were up in arms that the company would implement such a measure with no consultation or warning ahead of time. The content of an email is sacrosanct, in many respects, and tampering with it in any form will always be condemned by the security conscious. If the feature is a choice for the user, and can be turned off at will, then it’s a useful tool for those that want it. But this discovery was a surprise to many, making it hard to believe it was adequately disclosed before roll-out. The question unfolded in the FAQ screenshot above hints at this being part of Google’s A/B test and not applied to all accounts. Features being tested on your email account should be disclosed yet they are not.
Protecting innocent users against phishing attacks is a laudable aim, and we can imagine many business owners enabling such a feature to avoid phishing attacks. It’s another case where privacy is willingly traded for the idea of security. While the uproar is limited due to the specific nature of the implementation thus far, we would expect further desertion of Google’s email services by the tech savvy if such practices were to spread to the mainstream Gmail product. Regardless of what happens next, it’s important to remember that the email you read may not be the one you were sent, and act accordingly.
Update 30/10/2020: It has since come to light that for G Suite users with Advanced Protection enabled, it may not be possible to disable this feature at all.
For many people, Gmail is synonymous with e-mail. Some people like having cloud access to everything and some people hate having any personal data in the cloud. However you feel about it, one thing that was nice about having desktop software is that you could hack it relatively easily. If you didn’t like how your desktop mail client worked, you had a lot of options: use a different program, write your own, hack the executable of your current program, or in the case of open source just fork it and make any changes you are smart enough to make.
With scripting you can make sophisticated filters that would be very hard to do otherwise. For example, monitor for suspicious messages like those with more than 4 attachments, or that appear to come from a contact between the hours of 2AM and 5AM.
For our example today, I’m going to show you something that is easy but also highly useful.
Google is pulling the plug on their social network, Google+. Users still have the better part of a year to say their goodbyes, but if the fledgling social network was a ghost town before, news of its imminent shutdown isn’t likely to liven the place up. A quick check of the site as of this writing reveals many users are already posting their farewell messages, and while there’s some rallying behind petitions to keep the lights on, the majority realize that once Google has fallen out of love with a project there’s little chance of a reprieve.
To say that this is a surprise would be disingenuous. We’d wager a lot of you already thought it was gone, honestly. It’s no secret that Google’s attempt at a “Facebook Killer” was anything but, and while there was a group of dedicated users to be sure, it never attained anywhere near the success of its competition.
According to a blog post from Google, the network’s anemic user base isn’t the only reason they’ve decided to wind down the service. A previously undisclosed security vulnerability also hastened its demise, a revelation which will particularly sting those who joined for the privacy-first design Google touted. While this fairly transparent postmortem allows us to answer what ended Google’s grand experiment in social networking, there’s still one questions left unanswered. Where are the soon to be orphaned Google+ users supposed to go?
One of the tasks I dread is configuring a web server to send email correctly via Gmail. The simplest way of sending emails is SMTP, and there are a number of scripts out there that provide a simple method to send mail that way with a minimum of configuration. There’s even PHP
mail(), although it’s less than reliable.
Out of the box, Gmail requires OAUTH2 for authentication and to share user data, which has the major advantage of not requiring that you store your username and password in the application that requires access to your account. While they have an ‘allow less secure apps’ option that allows SMTP access for legacy products like Microsoft Outlook, it just doesn’t seem like the right way forward. Google documents how to interact with their API with OAUTH2, so why not just use that instead of putting my username and password in plaintext in a bunch of prototypes and test scripts?
Those are the thoughts that run through my head every time this comes up for a project, and each time I’ve somehow forgotten the steps to do it, also forgotten to write it down, and end up wasting quite a bit of time due to my own foolishness. As penance, I’ve decided to document the process and share it with all of you, and then also make it work on an ESP8266 board running the Arduino development environment.
While it is often said that “necessity is the mother of invention”, we can’t say that’s always been our experience here at Hackaday. You won’t need to search too long before you find a project or hack on this site that definitely falls out of the realm of strict necessity. But that’s part of the fun, there’s a reason this site isn’t called AppropriateUseOfTime.com
But when [Sam Storino] couldn’t seem to stop his cats from howling for their supper at 3:00 AM, he had the perfect opportunity to fulfill that age-old wisdom. Not only did he manage to turn a trip to the plumbing isle of his local home improvement store into a very Steampunk-looking automatic cat feeder, but he also found the time to write up an exceptionally detailed series of blog posts on what he learned during the process.
The heart of the machine is everyone’s favorite Linux board, the Raspberry Pi. You might be thinking the Pi is overkill for a simple timer, and you’d be right. Rather than just dump the food out on a set schedule, [Sam] decided to get a little fancy and come up with some Python scripts that will monitor a GMail inbox and activate the feeder hardware when it receives an email with the title “feed cats”. He then uses IFTTT to send the appropriately named email to the GMail account of his cat feeder on a specific schedule. Hey, nobody said necessity was the mother of straightforward invention.
In the final post of the series, [Sam] goes over the hardware side of the device. Copper pipe makes up the frame, which holds a commercial off-the-shelf dry food dispenser. The feeder was designed for manual operation, but by attaching a continuous rotation servo [Sam] can spin it up and dump a pre-measured amount of food via the Pi’s GPIO pins. The addition of some PVC pipe and fittings takes the food and (at least in theory) divides it equally between the two cat bowls below.
If you think [Sam] may have put a bit more thought than was necessary into something as simple as feeding his pets, keep in mind that he’s in exceptionally good company. Paging through the archives, it seems the intersection of felines and hackers is littered with gloriously complex contraptions.
The abundance of small networked boards running Linux — like the Raspberry Pi — is a boon for developers. It is easy enough to put a small cheap computer on the network. The fact that Linux has a lot of software is a double-edged sword. On the one hand, it is a good bet that anything you want to do has been done. On the other hand, some of the solutions are a bit large for a tiny embedded system.
Take, for example, e-mail. Historically, Linux hosts operate as mail transfer agents that can send and receive mail for all their users and possibly even relay mail to others. In today’s world, that’s usually overkill, but the capability is there. It is possible to install big mail transfer agents into a Raspberry Pi. The question is: should you?
What Do You Want?
The answer, of course, depends on what you want to do. If you have a dedicated board sending out text and maybe even files using an external mail server (like, say, Gmail), then the answer is no. You don’t need a piece of software listening for incoming connections, sorting through multiple users, and so on.
Luckily, there are some simple solutions if you know how to set up and configure them. The key is to avoid the big mail programs that do everything you don’t need.
Mail Front Ends
Let’s tackle sending mail first. If you try to grab the mailutils package, you’ll see it drags along a lot of stuff including mysql. Keep in mind, none of this will actually send mail. It just gives you some tools to get mail ready to send.
Luckily, the bsd-mailx package has a lot less overhead and will do the job. Look at the man page to see what options you have with mailx; you can do things like attach files, set a subject, and specify addresses.
It is a little difficult to set up for Gmail, though, thanks to Google’s security. You’ll need the certutil tool from the libnss3-tools package. You’ll need to create a certificate store, import Google’s certificate, and then set up a lot of options to mailx. I don’t suggest it. If you insist, though, you can find directions on the Web.
By default, programs like mailx and other Linux mail commands rely on a backend (often sendmail). Not only does that drag around too much overhead, it is also a full mail system, sending and receiving and relaying–overkill for our little Pi computers.
Luckily, SSMTP is available which only sends mail and is relatively lightweight. You need a configuration file to point it to your mail server. For Gmail, it would look like this:
# # Config file for sSMTP sendmail # # The person who gets all mail for userids < 1000 # Make this empty to disable rewriting. root=postmaster # The place where the mail goes. The actual machine name is required no # MX records are consulted. Commonly mailhosts are named mail.domain.com mailhub=smtp.gmail.com:587 # Where will the mail seem to come from? rewriteDomain=yourdomain.com # The full hostname hostname=yourhostname AuthUser=YourGmailUserID AuthPass=YourGmailPassword UseTLS=Yes UseSTARTTLS=YES # Are users allowed to set their own From: address? # YES - Allow the user to specify their own From: address # NO - Use the system generated From: address FromLineOverride=YES
You can use a mail agent like mailx or you can just use ssmtp directly:
Enter a message on the standard input and end it with a Control+D (standard end of file for Linux).
There’s only one catch. If you are using Gmail, you’ll find that Google wants you to use stronger authentication. If you are using two-factor (that is, Google Authenticator), this isn’t going to work at all. You’ll need to generate an app password. Even if you aren’t, you will probably need to relax Google’s fear of spammers on your account. You need to turn on the “Access for less secure apps” setting. If you don’t want to do this on your primary e-mail account, considering making an account that you only use for sending data from the Pi.
Depending on the mail software you use, there are a few ways you can attach a file. However, the mpack program makes it very easy:
mpack -a -s 'Data File' datafile.csv email@example.com
The above command will send datafile.csv as an attachment with the subject “Data File.” Pretty simple.
What if you want to reverse the process and receive mail on the Pi? There is a program called fetchmail that can grab e-mails from an IMAP or POP3 server. It is possible to make it only read the first unread message and send it to a script or program of your choosing.
You have to build a configuration file (or use the fetchmailconf program to build it). For example, here’s a simple .fetchmailrc file:
poll imap.gmail.com protocol IMAP user "firstname.lastname@example.org" with password "yourpassword" mda "/home/pi/mailscript.sh" folder 'INBOX' fetchlimit 1 keep ssl
You can leave the “keep” line out if you don’t mind fetchmail deleting the mail after processing. The file should be in your home directory (unless you specify with the -f option) and it needs to not be readable and writable by other users (e.g., chmod 600 .fetchmailrc). According to the fetchmail FAQ, there are some issues with Gmail, so you might want to consider some of the suggestions provided. However, for simple tasks like this, you should be able to work it all out.
In particular, the mailscript.sh file is where you can process the e-mail. You might, for example, look for certain keyword commands and take some action (perhaps replying using ssmtp).
You might not think of the Raspberry Pi as an e-mail machine. However, the fact that it is a pretty vanilla Linux setup means you can use all sorts of interesting tools meant for bigger computers. You just have to know they exist.