Pick your poison I guess. There are a lot of ways to deal with configuration data. The OP seems to want globals, and I figured at least with fully qualified variables at least he eliminates namespace pollution.

There are many many other alternatives too though:

• Config::General which grabs configuration data from a file and plops it into a hash. I happen to like the hash approach, though to your strict point, a hash's elements also are not subject to the helping hand of strictures.
• Using a package and accessing its configuration variables via their fully qualified names. It doesn't pollute package main's namespace, but also doesn't result in the strictures checking.
• Exporting from a configuration module / importing into the main script. While this will benefit from the use strict; assistance, it will also pollute package main's namespace. If you don't have absolute control over the configuration file, it would be easy to inject trouble this way.
• Use Data::Dumper, or Storable to read in the configuration information.
• Put the configuration information into a package, and export a set of accessor funtions to get at the configuration info. That way you're not actually touching the configuration variables, but accessing their data through sanitized accessors. A well behaved accessor should react appropriately when the caller tries to access configuration data that isn't part of the package.
• A config object... This method could automate reading the data in from some source, and provide methods for retrieving the data. ...similar to the previously-mentioned proposal, but has the potential of creating a simpler interface through the magic of Object Oriented abstraction.
• And about a million other approaches, some better than others. ;)