MIME Type Mismatch for WAV Resulting in MIME_BAD Spam Header

Questions
1

Your question

This isn’t a Stalwart issue per se, so I’m framing it as a question/discussion.

After tracing down why I was receiving MIME_BAD -1.00 for my VoIP voicemails, I’ve discovered that:

  1. FreeSWITCH is sending WAV as audio/x-wave
  2. Infer crate is reporting the attachment as audio/x-wav
  3. Stalwart is taking this mismatch and marking the message with MIME_BAD

Arguments could be made for all 3 parties to adjust their behavior, but since there is no definitive type for WAV, which one of the four used types would you standardize on?

I don’t know if it’s reasonable to ask Stalwart to have an alias/mapping function to recognize the four WAV MIME types and be able to say “audio/x-wave == audio/x-wav” and score it as such, or if Infer should be asked to adjust their system somehow. Even if they did, they’d have to fashion a new way to output since as I see it they can only return one type at present (I could be wrong here).

Not to mention I don’t know what Exchange, Proofpoint, Perception Point, or any of the other numerous scanning systems think about it, so where do you even start to argue about “right” and “wrong” types.

Thoughts appreciated!

I understand that topics in this category are triaged by a bot first but a human reply will follow up. If I’d prefer a human-only reply, I’ll add the no-ai tag to my topic.

on

2

I confirmed the mechanism from the source: Stalwart’s MIME_BAD check compares the declared Content-Type header against what the infer crate detects from the file’s magic bytes, and if they don’t match exactly (string equality), it tags MIME_BAD. There is currently no alias/equivalence table for known-synonymous MIME types (like audio/x-wav vs audio/x-wave vs audio/wav vs audio/vnd.wave) in that comparison, so any legitimate sender using a less-common alias will trigger the mismatch.

Since this is a scoring behavior rather than a bug, the practical workaround today is to adjust the score for that tag rather than fix the alias mapping. You can do this via the SpamTag object (WebUI: Settings › Spam Filter › Tag Scores, or via JMAP), setting MIME_BAD’s score lower or to zero, or writing a milter/sieve rule to specifically discount it for your voicemail sender if you want to keep the rest of the mismatch detection intact.

On the “which of the four WAV types is correct” question there’s no ground truth in the docs or code, this is a pragmatic limitation of exact-string matching between infer’s magic-byte detection and the declared header, not a policy stance Stalwart takes.

This is an automated reply from the Stalwart Help Bot. Other community members may follow up if this answer is incomplete or wrong.

3

Fixed in v0.16.19 (yet to be released).

4

Thanks for a fix, may I ask which path you decided on? Will it recognize all the types as good, or will it ignore alias types and be neutral?

5

I can confirm the voicemails are now being marked as MIME_GOOD, I am still curious what fix was implemented though.

6

The fix consisted of creating a list of MIME type compatible aliases.