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:188.8.131.52 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.
I had a dashcam to install on a 2019 Cayenne Turbo. I needed a switched power source (ACC) and I thought I could pigtail off of something in the fuse box. I looked in the owner’s manual and found out that there was no fusebox on the passenger side which would have been closer to the desired dashcam position. So I went to the driver’s side and found that…
1. There is no legend or markings telling me the socket numbers
2. The fuses in the sockets don’t correspond to those in the manual
This happened on the 2008 Cayenne Turbo too. The “first year of production” models and their manuals don’t match up.
I couldn’t find a suitable switched power source anyways so I went to the fuse box under the dead-pedal. Same problem here; no markings and fuses are either missing where the manual say they should be or a fuse is in a position the manual doesn’t say there should be one.
Anyways, I made an educated guess and figured out that the middle column in the bottom row had to be “Row D” in the manual. I confirmed this by pulling the fuse from position #16 – Left headlight electronics. When I turned the ignition, a warning for “Left lo-beam…” showed up on the dash. The funny thing is the left headlight still worked without the fuse. It must be the automatic hi/lo beam sensor or some other PDLS feature unrelated to the regular lights.
So for those seeking a switched power source, you can use socket #15 and #16 (Right and Left headlight electronics). There IS enough height for piggy back adapters under the dead-pedal. If you’re using TWO piggy-back/add-a-circuit, BEWARE – the pigtail from #15 will interfere with #16. A little bit of plastic shaving/forming will be necessary. And no, you can’t flip one left-side-right either because the divider in the fusebox interferes with the piggy-back.