How to Detect Spam Content in Documents Using C#

Enterprise endpoints accept file uploads from a wide range of sources, including vendors, customers, partners, and anonymous external users. The content within those documents is largely trusted by default, especially if it passes a virus and malware scan. The problem is that this doesn’t account for a different type of risk: documents that are free of malware but stuffed with spam content. That can mean anything from phishing attempts to unsolicited commercial material; some of it is dangerous, and some of it is just plain distracting.

Documents arrive looking legitimate, clear standard security checks, and then end up in front of a reviewer or downstream system carrying content they weren’t supposed to. Text-based spam detection doesn’t help here because the content isn’t arriving as email text: it’s arriving as a file, and evaluating what’s inside that file requires a different approach.

In this article, we’ll look at what it means to implement document-level spam detection in C#, and we’ll explore the challenges of building that capability in-house. Towards the end, we’ll walk through a dedicated API that handles spam classification across a wide range of document formats in a single request.

What Document-Level Spam Detection Actually Covers

Before we get into the implementation side of things, we’ll first be a little more specific about what “spam” means in the context of a document file. We can break the problem down into four distinct content categories.

The most serious of these is phishing content: material designed to deceive a document reviewer into giving away credentials or authorizing a payment (or taking some other action under false pretenses). If a document impersonates a legitimate vendor (e.g., contains a fraudulent invoice with misleading payment instructions) or embeds a link to a credential harvesting site, it falls into this category regardless of whether it arrives as an email attachment or a direct file upload.

Another category is unsolicited sales content. To be sure, a document submitted through a legitimate intake channel that turns out to be a commercial solicitation is a different kind of problem than phishing, but it’s still content that has no business entering the document pipeline through that channel.

Promotional content is a third category. It’s treated as distinct from unsolicited sales, and it’s generally less severe. The distinction matters from our perspective as security policy enforcers: our organization might want to categorically flag unsolicited sales submissions while permitting promotional content from known partners.

We’ll call the fourth category “general spam.” By this, we mean any content that doesn’t fit neatly into the first three categories but that a fraud detection policy assesses as unsafe or unwanted based on the overall character of the document.

The Challenge of Building This In-House

Building a document spam-detection pipeline in C# requires several components and comes with an ongoing maintenance burden.

The starting point is text and content extraction. A typical enterprise environment deals with a broader range of relevant formats than most teams initially account for. Documents like PDF, Office formats, HTML, EML, MSG, and image-based documents all require different handling before any content analysis can happen. For example, image-based documents require OCR. Each format adds its own extraction complexity.

URL analysis is a separate problem layered on top of content analysis. These days, documents very frequently contain embedded links, and evaluating those links as part of a spam assessment requires either a reputation database integration (i.e., a database of known spam/phishing links) or a model capable of assessing URL characteristics directly. Ideally, it should involve both.

The spam classification layer itself is where most in-house approaches encounter the most friction. Spam detection/classification models need to be trained and versioned, and they need to be maintained against evolving patterns. They may degrade as the content they’re trained to catch changes, and retraining those models requires labeled data that most development teams don’t have on-demand access to. The policy layer also adds a dimension of its own: different workflows have tolerances for different content types, and building a flexible policy configuration system from scratch isn’t trivial work for engineers.

None of this is impossible; after all, we’re living through an “AI boom” where intelligent models seem to pop up every week. However, the total cost of actually building and maintaining a reliable document spam detection pipeline tends to exceed what most teams expect going in.

Document Spam Detection With a Web API

In a lot of cases, the effort required to build that pipeline outweighs the benefits of having complete control over it. With that in mind, one alternative worth considering is handling the extraction, URL analysis, and classification through a single API call rather than assembling those pieces independently.

Any well-designed spam-detection API designed for document container detection should accept a wide range of formats likely to appear in enterprise intake workflows. It should return a result with category-level granularity rather than just a pass/fail flag, and it should (ideally) give us some level of control over policies so we can tune them to the tolerance of our own workflow. As we outlined earlier, the difference between flagging phishing content and promotional material is meaningful, and a useful API should treat those as separate controls rather than collapsing them into a single spam verdict.

We’ll walk through one such API we can implement in our C# project, which hits on most of these needs. We’ll first install the SDK via NuGet:

NuGet\Install-Package Cloudmersive.APIClient.NETCore.Spam -Version 1.0.1

And then we’ll import the required namespaces:

using System;
using System.Diagnostics;
using Cloudmersive.APIClient.NETCore.Spam.Api;
using Cloudmersive.APIClient.NETCore.Spam.Client;
using Cloudmersive.APIClient.NETCore.Spam.Model;

After that, the request structure is straightforward, which is exactly what we want if we’re making code changes to our application. In the example code below, we control classification behavior through header parameters with the input file passed as a stream:

namespace Example
{
    public class SpamDetectFileAdvancedPostExample
    {
        public void main()
        {
            // Configure API key authorization: Apikey
            Configuration.Default.AddApiKey("Apikey", "YOUR_API_KEY");
            
            

            var apiInstance = new SpamDetectionApi();
            var model = model_example;  // string | Optional: Specify which AI model to use.  Possible choices are Normal and Advanced.  Default is Advanced. (optional)  (default to Advanced)
            var preprocessing = preprocessing_example;  // string | Optional: Specify which preprocessing to Use.  Possible choices are None, Compatability and Auto.  Default is Auto. (optional)  (default to Auto)
            var allowPhishing = true;  // bool? | True if phishing should be allowed, false otherwise (optional)  (default to false)
            var allowUnsolicitedSales = true;  // bool? | True if unsolicited sales should be allowed, false otherwise (optional)  (default to false)
            var allowPromotionalContent = true;  // bool? | True if promotional content should be allowed, false otherwise (optional)  (default to true)
            var customPolicyId = customPolicyId_example;  // string | Apply a Custom Policy for Spam Enforcement by providing the ID; to create a Custom Policy, navigate to the Cloudmersive Management Portal and select Custom Policies.  Requires Managed Instance or Private Cloud (optional) 
            var inputFile = new System.IO.FileStream("C:\\temp\\inputfile", System.IO.FileMode.Open); // System.IO.Stream |  (optional) 

            try
            {
                // Perform advanced AI spam detection and classification against input text file.
                SpamDetectionAdvancedResponse result = apiInstance.SpamDetectFileAdvancedPost(model, preprocessing, allowPhishing, allowUnsolicitedSales, allowPromotionalContent, customPolicyId, inputFile);
                Debug.WriteLine(result);
            }
            catch (Exception e)
            {
                Debug.Print("Exception when calling SpamDetectionApi.SpamDetectFileAdvancedPost: " + e.Message );
            }
        }
    }
}

It’s worth noting that we can set the underlying model to Advanced or Normal mode, and we can preprocess documents for better results.  The three allow flags implement the concept of spam categories as actionable policies in our code; we can set those according to our own tolerance.

Our response comes back like the model below:

{
  "CleanResult": true,
  "SpamRiskLevel": 0,
  "ContainsSpam": true,
  "ContainsUnsolicitedSales": true,
  "ContainsPromotionalContent": true,
  "ContainsPhishingAttempt": true,
  "AnalysisRationale": "string"
}

We get a top-level clean result, a numeric risk score (i.e., how likely is it that this was spam?), some individual Boolean flags for each content category, and a plain-language rationale from the model which gives human reviewers in the pipeline something actionable to work with (rather than just a number).

Conclusion

In this article, we looked at the problem of spam content arriving inside document files rather than as email text, and we outlined the components required for an in-house detection approach. We then suggested a web API as a practical alternative for teams where building and maintaining that pipeline isn’t the right use of engineering resources.  

For enterprise workflows that accept documents from external sources, adding document-level spam classification/detection at the intake step is a good way to extend spam coverage to a surface that text-based tooling doesn’t reach.