Mail server changes are completed.  Mail that fails SPF, DKIM, or DMARC checks will no longer be rejected outright, instead they will be placed in your spam folder by default.  In the process of implementing this, I discovered many perl modules needed by spamassassin where not installed and so portions of spamassassin were not functioning.  Spam filtering should therefore be more effective now.

     You can now whitelist these as you could other e-mails scored as spam using the spam control facilities described here:

     https://www.eskimo.com/support/mail/spam-control-facilities/

     Similarly you can write procmail rules that handle such failures as you desire.  E-mails will now contain a header line like this:

     Authentication-Results: mx2.eskimo.com; dmarc=pass (p=none dis=none)
header.from=gmail.com

     That dmarc= may be “pass”, “fail”, or “none” and you can write rules to key off of these if you so desire.

     By default, any e-mail that arrives in your “spam” box should not be trusted, forged mails will go here.  So if you get e-mail from your bank saying you need to update your authentication or some such, do NOT click on the link if said mail is in your spam box.

     As a general safety note, I recommend NEVER clicking on these types of links, instead go directly to the site in question and make any necessary changes there.

     About a year ago we implemented opendkim, opendmark, and spf checking in order to reduce mail forgeries.  This did have the intended effects, although it’s not impossible to forge e-mails with these measures in place, it is difficult enough that it prevents the vast majority.

     However, DMARC protocol and to a lesser degree DKIM seems to be too difficult a concept for some mail providers to properly implement causing some legitimate mail to be rejected because it was marked to be checked by the sending sites DNS but they didn’t implement it correctly so it gets rejected.  This has particularly been an issue with one rather large cloud provider, but now we are seeing issues with NewEgg, a computer retailer I do quite a lot of business with and with GoDaddy.

     The existing system provides no effective means of whitelisting individually, and I do not wish to whitelist sites site-wide because then those sites can be forged.  However, I prefer to give the individual the ability to do so.

     Presently, opendmarc is implemented by opendmarc set to reject mode.  I intend to change this so that it only adds a header line to the mail and then add a rule to spamassassin to score the existence of a header indicating a failed dmarc with a really high value so that it will go to the spam folder unless you whitelist the site in your .spamassassin/user_prefs file OR you do something different in your own .procmailrc rules if you choose to override system rules.

     This way people savvy enough to recognize a forged e-mail can override the system wide filtering for themselves if they wish and those that can’t will at least have the option of examining their spam folders for missing mail and odds are good that if you’re expecting the e-mail it probably is legitimate.

     However, I will need to do this in two phases and there will be an interval during the process in which forged e-mail WILL go to your INBOX, therefore I caution you NOT to follow any links that say you need to provide authentication information for this site or any other site you do business with as they may be forged.  I will send a second notice when this is completed.

     During the first phase, I will change the configuration on OpenDmarc milter NOT to reject failed mail but only to add a header line.  Then once I find some examples of forged e-mail or create some, so I know what the headers look like, I will add a rule to spamassassin.  Between changing the configuration and adding the rule, forgeries will get through so be extra cautious with incoming mail until this has been completed.

     Amazon has lost power to one of their data centers.  This is causing issues reaching sites which they host.  They do not elaborate on the nature of the power outage but you can read about it here:

    Major services including Slack, AWS, Hulu, Imgur facing outages

     I don’t envy the folks having to work on this.  Just hoping to head off a few “can’t send mail to” AWS sites tickets.

     Taking website down to make another backup after finding more missing stuff.  This should take approximately one hour to complete.

     This will affect https://friendica.eskimo.com/ https://hubzilla.eskimo.com/ https://nextcloud.eskimo.com https://www.eskimo.com/ and all customer sites hosted with Eskimo North.

     Sorry for the downtime between about 10pm Dec 18th and 1am Dec 19th.  In the process of trying to fix some golang stuff so I could get a new application running, I meant to remove a golang subdirectory in /usr/share and accidentally hit return after typing rm -r /usr before I finished the rest of the path.  I hit delete right away but it had already removed half of /usr/share by that time.

     I think I restored everything missing but if you notice anything wrong please use the ticket system at https://www.eskimo.com/support/osTicket/ to open a ticket.

     We experienced a very brief denial of service attack around 3pm today.  By the time I logged into the router and turned on traffic analysis to determine the nature and origin it had stopped.

     A number of users complained about the introduction of Dashboard a while back.  It is an app now and could be disabled.  Given that nobody had anything good to say about it and it was slow as molasses in liquid helium, I have disabled it.

     https://nextcloud.eskimo.com/ is restored to service.  The automatic updater just would not work.  After about a dozen retries and it hanging in various spots during the upgrade, I manually upgraded which was successful.  There are a number of older applications that are no longer supported and a number of new available that I’ve yet to install but those apps that were installed that remain compatible are operational.

     Nextcloud is down tonight.  An update blew up and left it in an unusable state.  I’ve been working at it for about eight hours but need to get some sleep.

     At approximately 11:30PM Friday December 10th, Pacific Time, I will be rebooting the physical hosts which in turn will reboot all the virtual machines.  This is necessary because some system library updates that have been recently applied require a system restart to utilize the new code which addresses some Linux security concerns.  This should take about ten minutes for all hosts to complete.

     This will affect all shell servers, web service, mail service, and https://friendica.eskimo.com/, https://hubzilla.eskimo.com/, and https://nextcloud.eskimo.com/.