Re: Attachments with no Content-Type mime header

2017-08-17 Thread Rupert Gallagher
What is the problem that you wish to solve? The purpose of SA is to flag SPAM. In this case, you already have all the information you need, because subtype specification is MANDATORY. There are no default subtypes. SA must flag the email, because it is not compliant to RFC 822. Sent from Proto

SVN rules to sa-update?

2017-08-17 Thread George Patterson
We have noted that there was an update into SVN for 20_meta_tests.cf that we'd like to amend on our mail servers https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7411 namely changing: header __MOZILLA_MUA X-Mailer =~ /\bMozilla\b/to header __MOZILLA_MUAUser-Agent =~ /^mozilla\b/i Just

Re: Attachments with no Content-Type mime header

2017-08-17 Thread Paul Stead
This. With no Content-Type the type gets set to “text/plain” by default – should have maybe said this earlier, too On 17/08/2017, 15:53, "RW" wrote: Have you ruled-out the possibility that the mime-type for such parts is set to the default mime type of text/plain? -- Paul Stead Syste

Re: Attachments with no Content-Type mime header

2017-08-17 Thread RW
On Thu, 17 Aug 2017 08:41:57 + (UTC) Pedro David Marco wrote: > Thanks Paul... > it is weird... > the documentation says:  > >- find_parts() > > - Used to search the tree for specific MIME parts. An array of > matching Node objects (pointers into the tree) is returned. The >

Re: Attachments with no Content-Type mime header

2017-08-17 Thread Pedro David Marco
Thanks Paul... it is weird... the documentation says:  - find_parts() - Used to search the tree for specific MIME parts. An array of matching Node objects (pointers into the tree) is returned. The parameters that can be passed in are (in order, all scalars): - Regexp - Used