I have been using AutoKey on my Linux desktop to provide automated text insertion capabilities similar to what I get from AutoHotKey on my Windows systems. I prefer to keep things like my email and ticket signatures stored as hotkeys so I can more granularly choose when to use them.

The version of AutoKey included in the Ubuntu repositories has an issue where blank lines are inserted rather than the expected text.

Googling yielded the solution from an AskUbuntu post.

To fix the blank line issue, create a file named org.autokey.service at /usr/share/dbus-1/services with the following content:

[D-BUS Service] 
Name=org.autokey.service 
Exec=/usr/bin/autokey

After creating the file with the content above, kill and restart the AutoKey process or just reboot your computer. AutoKey should now properly insert text instead of blank lines!

D-BUS handles all of the communication between different processes running on the Linux system. It appears the D-BUS service for AutoKey is not configured correctly upon installation.

We have lately had a rash of compromised email accounts in our Office 365 Exchange Online infrastructure. It appears a well-crafted phishing email caught at least a small percentage of our 100,000-plus mailboxes.

The outbound SPAM protection in Office 365 and Exchange Online is very robust. Suspected SPAM messages are sent through a high-risk pool of IP addresses, and accounts are limited to 10,000 outbound messages per day before being blocked by the anti-SPAM intelligence. A support ticket must be filed with Microsoft to reactivate an account once it is blocked from sending outbound mail.

Normally, the anti-SPAM alerts received when an account hits the outbound message limit are sufficient for administrative notification. The most recent set of spammers, however, have been intelligently working underneath this notification system by sending less than 10,000 messages daily. The spammers instead cover their tracks by setting up email forwarding or an inbox rule to hide any bouncebacks from the slew of outbound junk.

Email forwarders victimized the most recent compromised accounts. These accounts came into the help desk with the same symptom of not receiving email messages. A look at the mailbox through Exchange Online PowerShell reveals the cause:

The spammer set the mailbox to forward all mail to an external address under their control, thereby hiding the nefarious activities.

To remove the forwarder, run the following in PowerShell:

Set-Mailbox [email protected] -ForwardingSmtpAddress $Null

In some cases, spammers will instead setup an inbox rule to hide their activity. View all inbox rules for a mailbox through PowerShell by running the following:

Get-InboxRule -Mailbox [email protected]

For a clean mailbox, this should return nothing or return valid inbox rules created by the customer.

It never hurts to educate your customers on never giving out login information through an email!

We had a request to add permissions for a customer throughout a deeply nested structure in our Exchange Online Public Folders.

These commands will not override or change permissions where they are already set.

Connect to Exchange Online PowerShell

$Cred = Get-Credential
Connect-MSOLService -Credential $Cred
$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://ps.outlook.com/powershell -Credential $Cred -Authentication Basic -AllowRedirection
Import-PSSession $Session

Add Permissions and Verify Success

In PowerShell, run:

Get-PublicFolder -Identity "\Folder Name" -Recurse | Add-PublicFolderClientPermission -User jsmith -AccessRights Owner

Verify the change was successful:

Get-PublicFolder -Identity "\Folder Name" -Recurse | Get-PublicFolderClientPermission | Where-Object { $PSItem.User -like "SMITH*" }

Use the customer’s name in the Where-Object cmdlet. All of our accounts are named in a “LASTNAME, FIRSTNAME” format, and the command reflects that. This command will print all of the customer’s rights through the tree.