> On 03 Oct 2014, at 11:26 , li...@rhsoft.net wrote:
>
>
> Am 03.10.2014 um 19:13 schrieb Philip Prindeville:
>> I don’t necessarily trust just the extension of the filename.
>>
>> I’d also look at the file’s magic (same as the OS does) as well as the
>> content-type.
>> Can’t be too thorough
Am 03.10.2014 um 19:13 schrieb Philip Prindeville:
> I don’t necessarily trust just the extension of the filename.
>
> I’d also look at the file’s magic (same as the OS does) as well as the
> content-type.
> Can’t be too thorough
that topic is not a matter of trusting
it's a matter of put diff
On Sep 18, 2014, at 7:45 AM, terrygalant.li...@fastest.cc wrote:
> I've been reading the discussion here and the various approaches to blocking
> extensions
>
> I'd gotten this from a friend awhile ago, and have been using it
>
> With
>
> postfix_header_checks = pcre:/path/to/custom_hea
Am 18.09.2014 um 15:45 schrieb terrygalant.li...@fastest.cc:
> I've been reading the discussion here and the various approaches to blocking
> extensions
>
> I'd gotten this from a friend awhile ago, and have been using it
>
> With
>
> postfix_header_checks = pcre:/path/to/custom_header_c
I've been reading the discussion here and the various approaches to blocking
extensions
I'd gotten this from a friend awhile ago, and have been using it
With
postfix_header_checks = pcre:/path/to/custom_header_checks
smtpd_sasl_authenticated_header = yes
cat /path/to/custom_hea
Am 17.09.2014 um 13:20 schrieb Wietse Venema:
> li...@rhsoft.net:
>> /^Content-(?:Disposition|Type):stuff/x REJECT 554 Attachment Blocked "$1"
>
> - What is $1 supposed to contain?
in fact the attachment name in the log as well
as in the REJET response (Thunderbird dialog)
excerpt from the logs
li...@rhsoft.net:
> /^Content-(?:Disposition|Type):stuff/x REJECT 554 Attachment Blocked "$1"
- What is $1 supposed to contain?
- Use "REJECT" or "554", not both.
Wietse
Am 17.09.2014 um 11:28 schrieb Christian Rößner:
> Am 17.09.2014 um 10:02 schrieb Christian Rößner
> :
>
>> /x REJECT blocked filename ${1}
>
> Missing indention here. Got it. Thanks
i attached once again my final (appearing to work)
config file - may somebody review if there
Am 17.09.2014 um 10:02 schrieb Christian Rößner
:
> /xREJECT blocked filename ${1}
Missing indention here. Got it. Thanks
Christian
--
Bachelor of Science Informatik
Erlenwiese 14, 36304 Alsfeld
T: +49 6631 78823400, F: +49 6631 78823409, M: +49 171 9905345
USt-IdNr.: DE225
Am 16.09.2014 um 21:42 schrieb Viktor Dukhovni :
> On Tue, Sep 16, 2014 at 09:28:11PM +0200, li...@rhsoft.net wrote:
>
>>># block windows executables PCRE
>>>/^\s*Content-(?:Disposition|Type): # Header label
>>> (?:.*?;)? \s* # Any prior attributes
>>> (?
*argh*
"regexp" versus "pcre"
i only replaced the regex without realite the different map type
that's why i posted "postconf -n" :-(
however, works now, thank you!
Am 17.09.2014 um 01:59 schrieb li...@rhsoft.net:
> Am 17.09.2014 um 01:42 schrieb Viktor Dukhovni:
>> On Wed, Sep 17, 2014 at 01:24
Am 17.09.2014 um 01:42 schrieb Viktor Dukhovni:
> On Wed, Sep 17, 2014 at 01:24:27AM +0200, li...@rhsoft.net wrote:
>
>> I still don't understand why "postmap" has a result but with
>> postfix Viktors rule don't catch the attachment and so finally
>> my one from the initial posting two lines belo
> On 16 Sep 2014, at 13:00 , Viktor Dukhovni wrote:
>
> On Tue, Sep 16, 2014 at 01:41:36PM -0500, Noel Jones wrote:
>
>> I've used the below for a few years with good results. It's better,
>> but surely not perfect.
>>
>>
>> # block windows executables PCRE
>> /^\s*Content-(Disposition|Type)
On Wed, Sep 17, 2014 at 01:24:27AM +0200, li...@rhsoft.net wrote:
> I still don't understand why "postmap" has a result but with
> postfix Viktors rule don't catch the attachment and so finally
> my one from the initial posting two lines below triggers
The live configuration must differ from the
Viktor Dukhovni:
> On Tue, Sep 16, 2014 at 07:14:51PM -0400, Wietse Venema wrote:
>
> > li...@rhsoft.net:
> > > >>> Content-Type: application/octet-stream;
> > > >>> name="test.exe"
> >
> > To test multiline headers, use "postmap -h -q"
>
> That's of course with "postmap -h -q -" when reading m
Am 17.09.2014 um 01:19 schrieb Viktor Dukhovni:
> On Tue, Sep 16, 2014 at 07:14:51PM -0400, Wietse Venema wrote:
>
>> li...@rhsoft.net:
>> Content-Type: application/octet-stream;
>> name="test.exe"
>>
>> To test multiline headers, use "postmap -h -q"
>
> That's of course with "postmap
On Tue, Sep 16, 2014 at 07:14:51PM -0400, Wietse Venema wrote:
> li...@rhsoft.net:
> > >>> Content-Type: application/octet-stream;
> > >>> name="test.exe"
>
> To test multiline headers, use "postmap -h -q"
That's of course with "postmap -h -q -" when reading messages (or
message headers) from a
li...@rhsoft.net:
> >>> Content-Type: application/octet-stream;
> >>> name="test.exe"
To test multiline headers, use "postmap -h -q"
Wietse
tember 16, 2014 9:38 PM
To: postfix-users@postfix.org
Subject: Re: FYI: blocking attachment extensions
Am 16.09.2014 um 20:34 schrieb Wietse Venema:
> li...@rhsoft.net:
>> (yes i know it's not 100% perfect in any case)
>>
>> but anybody using "mime_header_checks"
Am 17.09.2014 um 00:18 schrieb Philip Prindeville:
> MIMEDefang allows you to do all this, plus you can call Perl modules like
> File::Type on attachments to figure out if the file has been mistyped (i.e.
> the content-type disagrees with what the actual file header and/or file
> extension says
MIMEDefang allows you to do all this, plus you can call Perl modules like
File::Type on attachments to figure out if the file has been mistyped (i.e. the
content-type disagrees with what the actual file header and/or file extension
says it is).
-Philip
On Sep 16, 2014, at 12:04 PM, li...@rhso
On Tue, Sep 16, 2014 at 10:41:01PM +0200, li...@rhsoft.net wrote:
> > $ postmap -q 'Content-Type: name="test.exe"; charset=us-ascii'
> > pcre:/tmp/foo.pcre
> > REJECT 554 Attachment Blocked (Rule 0)
> >
> > You've not posted your test input or postmap -q invocation with output.
>
> I ju
Am 16.09.2014 um 22:28 schrieb Viktor Dukhovni:
> On Tue, Sep 16, 2014 at 10:15:03PM +0200, li...@rhsoft.net wrote:
>
>> I removed all comments AFAIK
>> that are 3 single lines without any break not added by the mail-client
>
> I've copied the rule below into my test file, and it works:
>
>
On Tue, Sep 16, 2014 at 10:15:03PM +0200, li...@rhsoft.net wrote:
> I removed all comments AFAIK
> that are 3 single lines without any break not added by the mail-client
I've copied the rule below into my test file, and it works:
$ postmap -q 'Content-Type: name="test.exe"; charset=us-ascii'
Am 16.09.2014 um 21:42 schrieb Viktor Dukhovni:
> On Tue, Sep 16, 2014 at 09:28:11PM +0200, li...@rhsoft.net wrote:
>
>>> # block windows executables PCRE
>>> /^\s*Content-(?:Disposition|Type): # Header label
>>> (?:.*?;)? \s* # Any prior attributes
>>>
Viktor Dukhovni:
> > interesting - none of both blocking a empty textfile renamed to "test.exe"
> > i have all 3 for now enabled and the 3rd one rejects (Thunderbird as MUA)
>
> That's because Postfix does not support in-line comments in PCRE
> patterns. The multi-line pattern is unfolded first,
On Tue, Sep 16, 2014 at 09:28:11PM +0200, li...@rhsoft.net wrote:
> > # block windows executables PCRE
> > /^\s*Content-(?:Disposition|Type): # Header label
> > (?:.*?;)? \s* # Any prior attributes
> > (?:file)?name\s*=\s*"?# name or
Am 16.09.2014 um 21:00 schrieb Viktor Dukhovni:
> On Tue, Sep 16, 2014 at 01:41:36PM -0500, Noel Jones wrote:
>
>> I've used the below for a few years with good results. It's better,
>> but surely not perfect.
>>
>> # block windows executables PCRE
>> /^\s*Content-(Disposition|Type).*name\s*=\s*
On Tue, Sep 16, 2014 at 01:41:36PM -0500, Noel Jones wrote:
> I've used the below for a few years with good results. It's better,
> but surely not perfect.
>
>
> # block windows executables PCRE
> /^\s*Content-(Disposition|Type).*name\s*=\s*"?(.*(\.|=2E)(
> ade|adp|bas|bat|chm|cmd|com|cpl|crt|
On 9/16/2014 1:04 PM, li...@rhsoft.net wrote:
> (yes i know it's not 100% perfect in any case)
>
> but anybody using "mime_header_checks" by one of the similar howtos out
> there should review the configuration - without \" at the end of the
> regex this is prone to false positives
>
> two exampl
Am 16.09.2014 um 20:34 schrieb Wietse Venema:
> li...@rhsoft.net:
>> (yes i know it's not 100% perfect in any case)
>>
>> but anybody using "mime_header_checks" by one of the similar howtos out
>> there should review the configuration - without \" at the end of the
>> regex this is prone to false p
li...@rhsoft.net:
> (yes i know it's not 100% perfect in any case)
>
> but anybody using "mime_header_checks" by one of the similar howtos out
> there should review the configuration - without \" at the end of the
> regex this is prone to false positives
Caution: MIME allows names in this context
32 matches
Mail list logo
