OS X, iPhone, iPad, sometimes Windows, and information on other peripheral devices.
THE PROBLEM: I finally took the plunge and subscribed to Office 365. Once installed, I noticed all the User Interface (UI) was in Japanese. There was no setting in each Office applications’ Preferences and also made sure that US English was chosen in OS X’s System Preferences > Language & Region > General. I had used the Japanese setting before, so I made sure to delete that from the list and restart the computer. I even deleted my Japanese input method from the Keyboard Preference pane. To no avail, Word, Excel, and Powerpoint UIs were stuck in Japanese.
THE CAUSE: If you’re a long time Mac user like me, you have probably migrated an old OS X account from computer to computer – preserving the users’ preferences through many versions of Microsoft Office. And if you’ve worked for a foreign company, you probably have installed a non-native language version of Office once before but uninstalled it since then. Your computer might have been setup by the company IT in a foreign language, then your account was created in English. In scenarios like this, “smart” installers like the one for Office 365 for Mac might picked up the scent of the foreign language files and presented you Word, Excel, and PowerPoint in that foreign language.
THE SOLUTION: You can fix this by forcing the individual application to re-remember (or forget) it’s UI language.
- Open System Preferences > Language & Region > Apps pane
- If Word/Excel/Powerpoint is not listed, click the “+” button to add it.
- From the dropdown list, choose the language it’s currently showing (in my case, Japanese). Keep System Preferences open.
- Open the application, then Quit it.
- With the application closed, now choose the language you want (in my case, US English)
- When you open the application again, it should be in the language you want it to be in.
- One step further: If you’ve chosen the same language as the System’s default language, you may delete the entry from the list using the “-” button.
This is a much safer solution than to delete the lproj folders from the Contents of the application or executing Terminal commands against the plist files.
With the upgrade to OS X Catalina’s 64-bit environment, ScanSnap Manager, the heart and soul of the system is no longer usable. The new 64-bit ScanSnap Home software is not compatible with the older scanners.
Your choice is to:
- Junk the old scanner and get a new one (expensive)
- Use 3rd party 64-bit scanning software like VueScan or ExactScan (clunky)
- Keep the older 32-bit compatible OS X running until the day you buy a new scanner (dangerous)
Although choice 3 sounds like a bad idea for security, there is a way to get around this:
- Load OS X Mojave in a virtual machine (Parallels/Fusion)
- Designate an old Mac as a scanning station
If you’re a hoarder holding on to an old ScanSnap, you probably have a end-of-life Mac being used as a dumb station for listening to LIVE Lo-Fi Beats on YouTube. You can designate this machine as a scanning station. You might even have an older printer that still works that you’re not willing to throw away. This Mac will also be your print station! Just remember, this Mac will soon be a security issue, so make sure you don’t leave anything on it.
Of course, if this doesn’t inspire joy, Marie Kondo it and just get a new scanner.
Recently I moved a Cyrus mailstore on a dying XServe to a Dovecot mailstore on a new Mac mini.
I f**ked up and copied files without the -p option to preserve the file dates.
cp -p #Doh!
Mail clients like OS X’s Mail.app do not read the mail header for the actual message’s received-date and uses the file modification date. Now I have hundreds of thousands of mail messages from 2004 that say they are from Dec 31, 2019 (Yes, I was working New Year’s Eve).
So I had to find a way to read the dates from the messages and set the modification dates on each message file. As a lazy hacker, I looked for somebody that already had the same problem. I found Steve Major’s example. It was easy to follow and helped me see the limitations of BSD on OS X. There were other example scripts for Linux but those wouldn’t have worked for OS X. Mainly, the -d option for the date command had a totally different implementation.
date -d #OS X is not Linux
Like I said, I’ve been running a server since 2004, so I was unsure if all the mail headers would include a “Date” field compliant with RFC2822. They didn’t.
I had to take the largest common denominator of date formats and try to get them to conform to RFC2822. So, I first wrote a quick script that parsed the files and wrote all the Date fields to file for examination. I quickly saw that 99% of the messages could be forced to conform to the format that I needed with minimal intervention.
So I took Steve’s code and modified it to my collection of messages. And in the meantime, figuring out that OS X BSD can reformat dates if it was sanitized to a known format.
date -j -f "%d %b %Y %T %z" "$datestring" "+%Y%m%d%H%M.%S
This is where I found out I didn’t have to manually convert the Month names (%B) to Month numbers (%b), but I had to sanitize the Timezone (%Z) to a UTC offset (%z)… and that the legacy timezone format we’re all familiar with like “CST” was no longer kosher with UNIX. In addition to that, I would have to force the OS X shell to read ALL locales if I wanted to convert legacy timezones automatically to UTC offsets. But because I pre-examined those Date fields, I noticed that only users in the US had their UTC offset missing and only had legacy TZ. All other countries are SO used to handling UTC offsets, it was a given.
So after two weeks of programming in-between grocery shopping and flipping houses, I have finally created:
I’ve been running a mail servers for 15 years. I’ve held on to the same domain names and IP addresses since .com opened up to the public. But with Google’s implementation of IPv6 security policies, I am now shut out from 26% of the e-mail network in America – that’s Gmail’s market share.
As Tanguy points out in his blog, Gmail servers are blocking incoming messages for no good reasons. Jari, has a different approach, but the same source of problem. Gmail gives zero consideration to non-gmail email. I have a Comcast e-mail address that cannot send messages through a Comcast SMTP server to a Gmail account… and Comcast is the LARGEST supplier of Internet service in the continental United States.
And according to actual people that work in the department at Google in charge of this mess, they have no better reasons. One of them hypothesizes that there is not enough “good” traffic between our servers that the algorithm may learn which messages to pass through and which ones are actually spam coming from spoofed smtp hosts.
Really? Statistically, there’s a 26% chance that one of my e-mails is meant for a Gmail user (in actuality, higher because I work with local schools who are on Google’s suite of services for education). So some spammers must be sending a thousand times more spam to Google users while spoofing my hostname and IP address? But I still get hundreds of spam in MY Gmail account. So what makes it possible for spammers’ messages to get through but not MINE? Sheer quantity?
Let me make it clear that I am FOR moving to IPv6. We need more IP addresses if we keep going this route in technology. The accompanying changes in protocols can make some of the more exploited parts of the current Internet more secure. But then, people don’t get to send birthday party invites or veteran’s benefits notices to Gmail users. It’s the implementations out there that suck.
Even if you set up SPF, DKIM, DMARC on outgoing messages, if your e-mail has “spammer-like behavior”, it gets rejected. Spam-like behavior includes, messages to multiple recipients. The threshold is TWO recipients.
By the way, as always, Alex at Topicdesk has an excellent tutorial on adding DKIM to your OS X Server 5.x. The only change with OS X Server 5.2 and up is that you must fix a bug(?) in amavisd-new 2.0.11. For OS X Server,
#In /Applications/Server.app/Contents/ServerRoot/usr/bin/amavisd #Add at line 22852 $msginfo->originating(c('originating'));
And with OS X Server 5.x, SPF is already compiled into the mail system. You only need to add TXT records to your DNS entry.
If you’re running on older versions, Alex has a SPF tutorial also.
#Example: Replace with your actual domainname and ipv4/ipv6 addresses domain.tld 3600 IN TXT v=spf1 ip4:184.108.40.206 ip6:1111:2222:3333:4444::/56 ~all
Notice one problem with the IPv6 address. If you lease one (1) static IPv4 address from your ISP, they’ll probably give you a /56 block of IPv6 addresses… that’s 4.7 sextillion hosts. They ALL have to point back to your server. If you’ve ever hosted reverse DNS, you’ll know that’s impossible to manage PTR records. And I think that’s where Google decided to authenticate using SPF instead of forcing admins to create 4.7 sextillion arpa records.
This was especially true in my case as my ISP’s transitional equipment would assign a random IPv6 address from the 4.7 sextillion possibilities to my single machine every day.
Of course, you must also use Google’s Postmaster Tools to generate a
google-site-verificationhash and add that as a TXT entry to your DNS records. This is fairly easy, but I don’t see how it verifies anything.
If an iPhone has full bars (shows 4G or LTE) and can make/receive phone calls but cannot get to the Internet (via Safari or any other IP app), then it’s a routing issue. Out of many routing issues, it MAY be that your cellular provider is having problems. BUT if all other devices (e.g. your friends and family’s) devices are working, then it is probably a routing issue with YOUR phone only.
There are several ways to troubleshoot routing issues on your phone.
1) Simply quit every app by swiping them away and turn your phone completely off, then back on. This will clear the cache and your phone may request the cellular provider for an alternate route.
2) Settings > General > Reset > Reset Network Settings. This will wipe out all network settings in addition to the network cache. Your iPhone WILL request the cellular provider for routing information as if it was new out of the box.
Now, there is a setting that will INHIBIT the iPhone from renewing the routing information from the cell provider – Data Roaming. For some reason, if you have Data Roaming turned ON, the cache is repopulated with roaming routing information. You have to turn Data Roaming OFF while attempting the above.