I have not tried a hosted spam filtering service, but I have had success with using amavisd on my email server once I trained the Bayesian filter with my spam and ham corpus. I also turned on razor, SORBS, SURBL, Spamhaus, and BRBL. The MTA is configured to drop pathological email attempts.
On any given day, at least 50% (and sometimes up to 75%, the weekly average is 60%) of the spam attempts get dropped before anything is delivered for filtering. Amavisd is able identify around 50% to 70% of the spam during filtering, which gets automatically redirected to the Junk folder. I could probably improve that a bit more, but it does not seem to be worthwhile at this point.
There are different attacks, however, that makes the QR option in SQRL worse in a practical sense than a username/password. One example is a variant of the hidden-browser attack against a smartcard-based hardware token. The SQRL client in this case serves two purposes: First it reinforces the user's mental perception of what they think is going on and, second, it provides the authentication. An attack against the QR option in SQRL is more significant than a site-specific QR authentication scheme because a SQRL client has the ability to authenticate against multiple web sites.
At the very least, any site using SQRL that cares about security should disallow logins where the SQRL client and browser IP addresses are different. Web sites should also implement the "respond to the SQRL client with the authenticated session URL" option. With this option, users would be required to use a browser on the same machine as the SQRL client. Finally, users should use a client that integrates with the browser as this would enable detection of a web page URL mismatch.
While I truly believe that one should not bet against stupid users (Mother Nature can always make a "more stupid user"), the attack vector would still have a challenge with SQRL.
The SQRL client is supposed to (modulo bad client implementations) request verification of a valid login from the user before proceeding. For this attack to work the user is looking at some website, sees a QR code on the page (advertisement, bogus login, etc), decides to scan the code in the SQRL client, sees the SQRL client popup a code for a different website, and then decides to proceed with the login. It does not appear that SQRL is any worse then a username/password system in protecting the user from doing stupid things.
They may be crap, but it does not appear that this attack would work with SQRL. The SQRL client hashes the URL of the website, signs the result, and then sends the result to the URL encoded in the QR code. In this attack, the client would see that there is a mismatch between the phishing website and the URL encoded in the QR code. If the attacker modifies the QR code to fix that discrepancy, the SQRL blob would have the wrong URL hashed and the server would reject the login attempt.
The researcher does not mention SQRL in his post or the github repo. That was added by the editor or the submitter.
Yep, I was trying to mimic the spam/ad writing style.
The last 20% is not trivial to eliminate and often (always in many cases) overwhelms legitimate mail. I have spent the last few weeks retraining spamassassin to gain a few more percentage points. I think I will enable autolearn and dovecot-antispam to help keep the Bayesian database current.
Alphabet/Google/whatever they are called is a for-profit business. This endeavor has to (roughly) do one ore more of the following:
Anything else would violate their fiduciary responsibilities.
Repeat after me: Do not plug into random USB ports or connect to random WiFi hot spots unless you are comfortable with their security practices and business model.
In the United States, your assertion that "working stiffs" are burdened with most of the taxes is not supported by the facts. If you look at total taxes paid (local, state, and Federal) as a percentage of income, the bottom 40% are taxed at about 20% and the top 20% are taxed at about 30% (Washington Post). So the rich are paying taxes at a higher rate then the "working stiffs."
If you look at it from the "income to the Federal government" perspective, as of tax year 2011, the top 5% paid 57% of the collected income tax and the bottom 50% paid 12% of the collected income tax.
Based on those two facts, I assert that the "working stiffs" are not taxed at a higher rate then the rich. Also, at the Federal level, the rich pay far more in taxes. Where the "working stiffs" lose out (and the Washington Post article shows this) is at the local and state level.
I think you have misinterpreted the rules a bit. Campaigning and party activity are prohibited with government resources.
The President and Cabinet sending emails on implementing political goals are permitted activities. Sending emails about ?NC platform discussions are not permitted.
When I went through ethics training with the GC, it was very clear what was and was not permissible. From the GC point of view, the default was use goverment email and save every email.
I can see the desire, particularly at the executive level, not to leave a record because policy formulation can be a messy activity. However, I'm not sure that is the motivation in this case. First, there is no control over the retention of the other end and, second, a lot discussion happens on the classified side.