I'm sorry for the confusion, but forget this part
---------------------------------
Because of the new (--ext) option, it is now possible to build envelope
sender based exceptions for every attachment extension and content - like:
zip:supp...@vendor-domain.com=>block=>--encrypt
Which allows encryped zip files from and to this software vendor support
address - even this is not allowed for the envelope recipient per rule.
---------------------------------
I just saw, that I've implemented the less weak code.
--encrypt will work for supp...@vendor-domain.com - but will not overwrite
the recipient rules at runtime
In case the collon exceptions :ELF:WIN .... and so on, will work like
expected.
The -- exceptions are processed at configuration time (separatly for each
entry - block=>, block-in=>, ....) - the collon exceptions at runtime
(attachment check).
Thomas
Von: Thomas Eckardt <thomas.ecka...@thockar.com>
An: ASSP development mailing list <assp-test@lists.sourceforge.net>
Datum: 02.09.2017 10:17
Betreff: Re: [Assp-test] fixes in assp 2.5.6 build 17243
>You sure do work fast!
The logic and several code parts were finished before I asked for
suggestions. :)
1)
>*@Domain.com=>block=>~~commonRule
>specificu...@domain.com=>block=>doc
>so specificu...@domain.com would have all of the ~~commonRule blocks and
also .doc being blocked?
NO! You have to define
specificu...@domain.com=>block=>doc|~~commonRule
Inheritance is not implemented yet. So, still the (single) longest
matching entry is used for the first envelope recipient and the envelope
sender - nothing changed for this behavior.
I'm not sure if it is wise to implement inheritance. I've done several
extensive tests - and they have shown, that I'm unable to say, where a
resulting rule comes from. For example:
groups of domain and user definitions are used in UserAttach (and possibly
elsewhere in ASSP)
[domains]=>anyRule
[users]=>otherRule
i...@sub.dom.com=>block=>~ITBlock| .....
some entries in line 1 may inherit from others in line 1 (and/or possibly
others)
some entries in line 2 may inherit from line 1 and/or line 2 (and/or
possibly others)
the last line may inherit from 1 and 2 OR 1 or 2 OR neither (and/or
possibly others) - but you can't see it. You would have to watch the
maillog.txt after setting AttachmentLog to verbose (BTW: a good idea every
time you configure UserAttach).
This is a really simple example with three rule definition lines. What if
there are (let's say) 20 of such group lines and an admin makes changes
for a group (possibly in a totaly different relation - means assp config
parameter)
Now think about the definition and processing of 'inherit from (learn)'
and 'inherit to (teach)', which should be configurable by disable them
(-i) , (-I) and (-iI).
The complexity will race up to a state, where nobody will understand how
and why the resulting attachment rules are build.
To race up the complexity to an unknown very high state, take the lines
above for the envelope sender again - and combine all results!
In worst case, an unexpected executable exception rule will take place for
a user or group of users and unwanted mails will be delivered to them.
2)
**********************
I hope, I have to explain this the last time - this is somehow childish
Ken
**********************
For incoming mails, block and block-in are combined - for outgoing mails,
block and block-out are combined at runtime (when else - only at runtime
we knew the mail flow direction)!
The same applies to good ....!
''block-in=>:MSOM" makes the exception for incoming mails
"block-out=>:CSC" makes the exception for outgoing mails
"block=>:ELF" makes the exception for all mails
example:
u...@localdomain.com is the first envelope recipient and got the following
rule
block=>exe-bin|:ELF,block-in=>:MSOM|zip,block-out=>:CSC|gz
resulting regex for incoming mail at runtime for u...@localdomain.com
reject attachments if there extension matches : exe-bin|:ELF|:MSOM|zip
resulting regex for outgoing mail at runtime for u...@localdomain.com
reject attachments if there extension matches : exe-bin|:ELF|:CSC|gz
The same is done for the evelope sender - the result (sender-rules) is
added (logical OR - a pipe in regex) to the mail attachment rule at
runtime
resulting regex for incoming mail at runtime
reject attachments if there extension matches : exe-bin|:ELF|:MSOM|zip
|in-sender-rules....
resulting regex for outgoing mail at runtime
reject attachments if there extension matches : exe-bin|:ELF|:CSC|gz
|out-sender-rules....
This was the case all the time and the GUI describes this behavior
exactly!
This set of regular expression ...... Separate entries with a any of '=>
, ; space'. Separate multiple regex entries with pipe '|'
.....
good => goodAttachRegex - good attachment for incoming and outgoing mails
good-out => goodoutRegex - good attachment for outgoing mails
good-in => goodinRegex - good attachment for incoming mails
block => blockAttachRegex - bad attachment for incoming and outgoing mails
block-out => blockoutRegex - bad attachment for outgoing mails
block-in => blockinRegex - bad attachment for incoming mails
......
The defined blocking rules for the sender and the first envelope recipient
are combined together using an OR logic.
good, good-out and good-in - and also - block, block-out and block-in -
will be logical OR combined according to the mail flow.
.....
I can't explain the functionality anyhow better than this.
To get nearly everything explained:
Because of the new (--ext) option, it is now possible to build envelope
sender based exceptions for every attachment extension and content - like:
zip:supp...@vendor-domain.com=>block=>--encrypt
Which allows encryped zip files from and to this software vendor support
address - even this is not allowed for the envelope recipient per rule.
This can be done separately or in addition to the already working
i...@sender-domain.com=>block-in=>:JSPDF
zip:i...@sender-domain.com=>block-in=>:JSPDF
Which allows PDF with JAVA script from this sender - plain and compressed
- even this is not allowed for the envelope recipient per rule
BE CAREFULL !!!
Such external sender/recipient based exception rules are very nice and
makes your work much more easy!
Before you define such an sender based exception rule - YOU HAVE TO make
sure, that the sender address can't be faked! (eg. SPF strict, DKIM)
> ASSP is smart enough to let this through?
Yes - at the moment I can't think about any impossible rule combination.
3)
Only three easy lines of code were needed for this implementation. So I've
done it.
Thomas
Von: K Post <nntp.p...@gmail.com>
An: ASSP development mailing list <assp-test@lists.sourceforge.net>
Datum: 02.09.2017 01:37
Betreff: Re: [Assp-test] fixes in assp 2.5.6 build 17243
You sure do work fast! Questions and commends on the UserAttach
functionality:
1) You had previously mentioned inheritance, but I don't see reference to
that here. That's fine, but say you've got something like
*@Domain.com=>block=>~~commonRule
specificu...@domain.com=>block=>doc
I know you said that ASSP will combine rules, but I didn't know if that
was only when multiple rules were on a single line or if it's also when a
user matches multiple lines. So does ASSP and these rules together so
specificu...@domain.com would have all of the ~~commonRule blocks and also
.doc being blocked?
2) In your example, you have:
~~commonRule=>block=>~executables|~scripts|xls,block-in=>:MSOM,block-out=>:CSC
and executables is defined as
~executables => cmd|com|cpl|exe|exe\-bin|lnk|pif
That block-in rule of :MSOM removes office macros from exe-bin (which is
sadly very useful for select users in our org). What I don't understand
is how the block rule is combines with the block-in rule.
If the user gets an office macro file, that would match the block rule for
exe-bin. But there's also a rule in that same line for :MSOM. ASSP is
smart enough to let this through?
3) I'm so excited that you implemented the -- (double minus) feature to
remove extensions from the definitions. This is going to be great!
THANK YOU
Ken
On Thu, Aug 31, 2017 at 9:48 AM, Thomas Eckardt <
thomas.ecka...@thockar.com> wrote:
Hi all,
fixed in assp 2.5.6 build 17243:
- if two email addresses were defined in the from: header tag - like:
from: du...@localdomain.com <sen...@senderdomain.org>
the first address was used by assp instead of the right second. This
made spam detection difficult and caused the DKIM check to fail.
added:
- 'UserAttach' got an enhancement - it is now possible to define and use
regular expression templates as well as rule templates
- the GUI is changed
.....
block=> rules cause specific file types to be blocked (but does not
block the others).
good=> rules block all file types except for those specified in the
rule.
....
It is possible to define templates (see the preceding single tilde ~ )
for extension regular expression and to use them in any entry at any place
(except other extension regular expression templates) - like:
~executables => cmd|com|cpl|exe|exe\-bin|lnk|pif
~scripts => js|pl|ps1?|sh|vb[es]?|wms|ws[cfh]
us...@domain.tld => block => ~executables|~scripts|mht|ms[cipt] ,
block-in =>:MSOM , block-out => :CERTPDF
[allDomains] => block => ~executables|:CSC
Extension regular expression template names have to start with a single
tilde. Allowed name characters are A-Z, a-z, 0-9 and underscrore.
It is also possible to define rule templates and to use them in
combination with any other rule definitions or rule templates.
Rule templates starts with two tilde (~~template). Allowed name
characters are A-Z, a-z, 0-9 and underscrore. For example:
~~commonRule=>block=>~executables|~scripts|xls,block-in=>:MSOM,block-out=>:CSC
~~devRule=>~~commonRule=>block-out=>:WIN|:ELF
~~allowALL=>good=>*
*@domain.com=>~~commonRule
[IT]=>~~devRule
u...@domain.com
=>~~commonRule,~~anySecondRule,~~anyOtherRule=>block=>~anyExt,block-in=>~otherExt|xls|--doc
Notice the leading -- in front of the --doc regular expression in the
last example. The -- removes all occurences of this regular expression
from the resulting entry,
here from block-in.
ASSP will resolve all extension regular expression templates and all
rule tempates and will combine them all in to one resulting user
attachment rule.
ASSP will throw a warning, if a rule template is define multipe times -
like: *@domain.com=~~commonRule,~~devRule - here ~~devRule already
contains ~~commonRule
It may happen, that the resulting attachment rule contains one or more
extension reglar expressions multiple times - this is harmless, but try to
prevent it.
....
Thomas
DISCLAIMER:
*******************************************************
This email and any files transmitted with it may be confidential, legally
privileged and protected in law and are intended solely for the use of the
individual to whom it is addressed.
This email was multiple times scanned for viruses. There should be no
known virus in this email!
*******************************************************
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Assp-test mailing list
Assp-test@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/assp-test
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Assp-test mailing list
Assp-test@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/assp-test
DISCLAIMER:
*******************************************************
This email and any files transmitted with it may be confidential, legally
privileged and protected in law and are intended solely for the use of the
individual to whom it is addressed.
This email was multiple times scanned for viruses. There should be no
known virus in this email!
*******************************************************
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Assp-test mailing list
Assp-test@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/assp-test
DISCLAIMER:
*******************************************************
This email and any files transmitted with it may be confidential, legally
privileged and protected in law and are intended solely for the use of the
individual to whom it is addressed.
This email was multiple times scanned for viruses. There should be no
known virus in this email!
*******************************************************
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Assp-test mailing list
Assp-test@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/assp-test
