First, I want to point out that the author of the email has misphrased what they want. They don't want "no license" but rather "a different license, just between you and me, without the requirements of the licenses you currently offer." With that out of the way, let's answer the question.
Whether or not this particular offer is a scam depends on the specifics of the case, but selling exceptions to the GPL is a business model that many software projects employ. Many companies want to use GPL-licensed software in their own software that they sell, but do not wish to disclose the full source code of their software to the buyers. Therefore, the author of a GPL component might choose to sell the right to be exempt from the GPL's requirements. Some examples of projects that follow this model include MySQL (GPL/commercial), Qt (GPL/LGPL/commercial), and MongoDB (formerly AGPL/commercial, though as of October 16, 2018 MongoDB has switched from the AGPL to a different homemade license).
However, since you offer the software under permissive MIT/X11 terms as well, this request is a little stranger. They already have the option to avoid copyleft source-sharing requirements. Still, it's not unheard of: importantly, the request mentions that the licenses you chose are on the organization's "license blacklist" rather than a specific problem with your license requirements. This is likely either a case of corporate paranoia or brittleness about open source, or they don't understand that they can choose the MIT license to avoid copyleft requirements.
To understand the first case, I found an article that deals with this problem from inside a company, How to Convince Your Manager to Use Open Source Software. A helpful bit of perspective from that article is:
Often, developers don't really know how their company acquires software. [...] At most large companies, there's a whole software procurement process.
[...] Examples of things that a procurement process normally covers are:
Price. Both up front and on-going costs are at issue. This includes the price of acquiring the software, installing and integrating it, and providing maintenance and support. [...]
Source Code Escrow. The procurement process usually addresses what will happen if the software company goes out of business. [...] While this isn't usually an issue for open source software, it is worth pointing out what you'll do if your contract with a provider of open source software ends or if the company goes out of business.
Support. Who is going to support this software? With the proprietary software procurement model, it's often obvious who is responsible for support; which means this issue is really more about the terms of support: 24x7, work hours, numbers to call, etc.
Obviously, not of these apply to your case, but I hope this might clarify why a company could be more likely to say "Let's talk to the owner of the library and buy a license," when the other option is, "Let's not talk to the owner of the library and assume everything is just fine."