Apr 032017
 

Since getting a HiDPI screen, I have been plagued with claws mail merrily doing the right thing with proper emails, but showing HTML emails at a tiny size.

Whilst it doesn’t appear to be a preference you can change in the normal way, there is a zoom variable you can change within the Claws preferences file. Quit claws, and edit ~/.claws-mail/.clawsrc and scroll down through the file until you find the “[Fancy]” section :-

[fancy]
enable_images=1
enable_remote_content=1
enable_scripts=0
enable_plugins=0
open_external=1
zoom_level=100
enable_java=0
enable_proxy=0

Change the “zoom_level” to a suitable percentage (such as 200).

Mar 182017
 

The TiPro programmable keyboards are quite fun for those who are into their keyboards, but with one big problem: the programming tool is Windows only. Well at least if you happen to have a USB-based TiPro; otherwise you need to set up the serial interface as the PS/2 interface is only usable for programming with a 32-bit Windows.

As it turns out, if you try to run it under a virtual machine and assign the USB device of the keyboard to the virtual machine, it still fails – somehow it doesn’t like staying assigned to the virtual machine. However there is a fix for this – using the command-line VirtualBox tools to set up a permanent USB filter.

To assign, first of all determine the name of your virtual machine with :-

VboxManage list vms

Next, add a USB filter – you can normally assign it to “slot” (or index) 1, but you may have to check what slots are available if you already do this :-

VBoxManage usbfilter add 1 --target "W10" --name TiPro --vendorid 0x1222 --productid 0xfaca

Once that is done, the Windows tool should be able to find the keyboard to start programming it. If necessary, reboot the virtual machine or try assigning the USB device via the menu option.

During programming it is helpful to remember than raw USB HID codes can be used by right-clicking in the input field for a key, selecting “Text Input” and inputing the code in the form “/${hex hid code} ${hex hid code}\” – such as “/69 69\” (a list can be found at: http://www.usb.org/developers/hidpage/Hut1_12v2.pdf)

Removal at the end:

VBoxManage usbfilter remove 1 --target "W10"

After the removal it seems that disconnecting and reconnecting the device is necessary for Linux to pick it up (or possibly a udevadm trigger).

b

Feb 272017
 

Strictly speaking how some cloud services do mail wrong, but whilst it is not all, there are still quite a few that do which is why there are no names contained within this rant.

When you have some cloud-based service send email, it makes sense for the “From” header (i.e. what sensible normal people think of as the sender address) to contain the email address of the person using the cloud-based service.

Fair enough.

But if the real sender address or envelope sender address (which is contained within the SMTP transaction) comprises the email address of the person using the cloud-based service you may well run into problems. Many organisations publish an SPF record in their DNS to indicate what network addresses are approved for, and many mail servers check the envelope sender against the published authorised network addresses.

If the network address used by the cloud service provider does not match what is in the organisation’s SPF record then the recipient’s mail server is free to reject the mail. And they often do.

Now the most obvious “fix” for this is to add the cloud service provider’s network address to the organisation’s SPF record.

The only trouble with that is that it isn’t always possible. There are various limits to how long an SPF record can be so adding addresses to the SPF record recklessly is unwise, and a sensible DNS administrator will only add to the SPF record for important services. So if the cloud service is being evaluated or being used by something less important, or is being used for non-work related purposes, then it likely won’t meet the “important enough to get added to the SPF record” criteria.

So why not fix the source of the problem?

All that has to be done is to use a different address for the envelope sender, and you can even arrange things to send bounces back to the right place.

Set the envelope sender to something like “customer+${original email}@${cloud service address}” (obviously when replacing the ${original email} you will have to change the “@” sign to something reversible). All of a sudden you are no longer “forging” the envelope sender, and not tripping over anyone’s spam defences.

Process the bounces to “customer@${cloud service address}” and you can send the bounces to the right place.

Feb 122017
 

A very long time ago, I used to collect spam in order to graph how much spam a single mail server was likely to get over time, and almost as long ago, I lost interest in maintaining it. As a consequence I still get a ton of spam every day and after a long period of procrastination I have been slowly raising defences against spam.

This particular recipe is not really a defence against spam – it verifies that the remote server is properly DNS registered with a reverse DNS registration – in other words that the IP address it is connecting from is registered. This is a requirement for all mail servers, and as it turns out, spammers don’t care for registering their servers in the DNS.

This ACL snippet goes into the ACL for checking the recipient or for checking the message :-

 deny
   message = Your mail server is not properly DNS registered
   log_message = BLOCKED: No rDNS
   condition = ${if eq{$host_lookup_failed} {1} {1}{0}}
   # Check rDNS and block if not registered

There are three items of interest :-

  1. The message is intended to be easily read by recipients to determine what the problem is. It turns out that many people do not read NDRs, but if we get the message right at least we are doing the right thing.
  2. The log_message is intended to make automating log parsing easier.
  3. Within the condition, the $host_lookup_failed variable indicates that the reverse DNS lookup returned NXDOMAIN and not that it timed out (which would be $host_lookup_deferred).

That’s all there is to this little piece of configuration.

Feb 082017
 

One of the things that come up whenever IPv6 is mentioned on certain news sites, is that there are people out there who think that NAT solves all of the address size problems and doesn’t have any negatives. I could present a whole series of blog articles on why NAT is the work of the devil, and presents a clear and present danger to life, liberty, and the pursuit of happiness (I might be exaggerating just a touch here).

The naive approach to a security issue originating from a certain network address is to block that network address permanently, pending an appropriate response, or temporarily. Not a bad idea although it does resemble a game of hunt the wumpus, and to assist in this, there are community based collective blocklists.

But what happens when you block an address, and that address is the public address of a NAT device? You block everyone sharing that public address, which could be just a household or it could be thousands of unconnected people. For instance, I have up to 32,000 people behind a handful of public IP addresses.

And yes I do regularly see problems where blocks have been put in place, and from what I can see this is a problem that is widely shared amongst people who NAT.

And once you are blocked in this way, you may be able to get it removed if you manage to identify which blocklist you are on, stop the network abuse and it has a well-run mechanism for removal. Most blocklists (including the ones I run) don’t work this way.

Every IP address has a reputation associated with it, and if you share a public IP address that has a poor reputation, parts of the Internet will disappear for you, and these include some well known services.