From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <pmg-devel-bounces@lists.proxmox.com> Received: from firstgate.proxmox.com (firstgate.proxmox.com [212.224.123.68]) by lore.proxmox.com (Postfix) with ESMTPS id A82161FF15C for <inbox@lore.proxmox.com>; Wed, 19 Feb 2025 13:22:23 +0100 (CET) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id DE23C2836E; Wed, 19 Feb 2025 13:22:19 +0100 (CET) Date: Wed, 19 Feb 2025 13:22:15 +0100 From: Stoiko Ivanov <s.ivanov@proxmox.com> To: Friedrich Weber <f.weber@proxmox.com> Message-ID: <Z7XM99cpDqek_1vf@rosa.proxmox.com> References: <20250218135416.54504-1-s.ivanov@proxmox.com> <20250218135416.54504-3-s.ivanov@proxmox.com> <ab5bd9b1-cb08-4b77-8e1b-64eab07ac191@proxmox.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <ab5bd9b1-cb08-4b77-8e1b-64eab07ac191@proxmox.com> X-SPAM-LEVEL: Spam detection results: 0 AWL 0.067 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DMARC_MISSING 0.1 Missing DMARC policy KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record Subject: Re: [pmg-devel] [PATCH pmg-api v2 2/2] ruledb: content-type: add flag for matching only based on magic/content X-BeenThere: pmg-devel@lists.proxmox.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Proxmox Mail Gateway development discussion <pmg-devel.lists.proxmox.com> List-Unsubscribe: <https://lists.proxmox.com/cgi-bin/mailman/options/pmg-devel>, <mailto:pmg-devel-request@lists.proxmox.com?subject=unsubscribe> List-Archive: <http://lists.proxmox.com/pipermail/pmg-devel/> List-Post: <mailto:pmg-devel@lists.proxmox.com> List-Help: <mailto:pmg-devel-request@lists.proxmox.com?subject=help> List-Subscribe: <https://lists.proxmox.com/cgi-bin/mailman/listinfo/pmg-devel>, <mailto:pmg-devel-request@lists.proxmox.com?subject=subscribe> Cc: pmg-devel@lists.proxmox.com Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: pmg-devel-bounces@lists.proxmox.com Sender: "pmg-devel" <pmg-devel-bounces@lists.proxmox.com> On Tue, Feb 18, 2025 at 06:18:13PM +0100, Friedrich Weber wrote: > On 18/02/2025 14:54, Stoiko Ivanov wrote: > > our current content-type matching is sensibly quite cautious in > > matching if any available information indicates a potential match: > > * mime-type detection based on file contents > > * mime-type detection based on file suffix > > * content-type header > > > > Sometimes this can lead to surprises (e.g. when a MUA sets the > > filetype of a pdf to application/octet-stream (the default type if no > > information is available), or a filter for zip-files matching > > docx-files. > > > > This change gives users the option to restrict matching only on the > > content as detected by xdg_mime_get_mime_type_for_data. > > > > This is a fix for the intial request in #2691 and addresses the > > suggestion from Friedrich from: > > https://bugzilla.proxmox.com/show_bug.cgi?id=5618#c2 > > > Thanks for tackling this! I think having a flag like only-content makes > sense. > > I tested this a bit and there seems to be one issue, steps to reproduce: > > - add a What object with a Content Type Filter for application/pdf, > enable the new "Ignore header information" flag > > - create a rule that blocks incoming mails matching this What object > > - send an email with a random 1K blob as attachment that sets > Content-Type: application/pdf and some non-descriptive filename for the > attachment: > > swaks --from [...] --to [...] --server [...] --attach-type > application/pdf --attach-name foo.bin --attach <(dd if=/dev/urandom > bs=1k count=1) > > The email is blocked by the rule. But I would expect it to be accepted, > because the `xdg_mime_get_mime_type_for_data` shouldn't recognize the > random blob as PDF, and the user-provided Content-Type application/pdf > should be ignored. > > I think the email is accepted because the magic ct [1] defaults to the > user-provided Content-Type and since `xdg_mime_get_mime_type_for_data` > returns application/octet-stream, we're keep it at the user-provided > Content-Type. I guess it would be nicer if the magic wouldn't default to > the user-provided Content-Type if "Ignore header information" is > enabled, but I'm not sure how easily this can be done. > > [1] > https://git.proxmox.com/?p=pmg-api.git;a=blob;f=src/PMG/Utils.pm;h=0b8945f245;hb=6bbc222#l623 Thanks big-time for the testing, issue-finding and analysis of the cause! reworked the content-type finding in Utils.pm - after quickly checking where we rely on that information: https://lore.proxmox.com/pmg-devel/20250219121851.110090-1-s.ivanov@proxmox.com/T/#t >..snip.. _______________________________________________ pmg-devel mailing list pmg-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pmg-devel