This is all quite helpful and unsurprisingly, quite logical.
My uncertainty here is not due to a lack of experience or understanding of
and/or logic, rather a lack of documentation/gui explanation. I've been in
your shoes before, when you write the code it's hard to document because
some things that are obvious to you as the developer might not be obvious
to the user. There's matching, not matching, ors, and ands involved
here. Your logic is sounds, but it's still not explained in the gui.
For example: how block and block-in are combined. You said block and good
are OR'ed together, and that's fine, but it doesn't explain how block and
block-in are combined. You've now explained it here, but to the user who
is only looking at the GUI, knowing that if a block rule says exe-bin
(which will block anything that's detected as executable) is defined along
with a block-in of :MSOM (allowing office macro files) that for inbound
mail exe-bin will be blocked unless it's an MSOM.
If I may, I'd suggest some GUI language refinements:
original:
good => goodAttachRegex - good attachment for incoming and outgoing mails
change to
good => goodAttachRegex - good attachment for incoming and outgoing
mails. *All
good rules will explicitly block all other detected file types.*
original:
good, good-out and good-in - and also - block, block-out and block-in -
will be logical OR combined according to the mail flow.
change to:
Based on mail direction, block and block-in or block-out will be combined
into one logical rule as will good with good-in or good-out. Exceptions to
executable blocking (:MSOM for example) are honored when combining a block
/ good rules. The resulting good and block rules will be logical OR
combined.
Block if
a block rule matches
OR
a good rule does not match (regardless of any block rules, if a good rule
exists and does not match the file type, the attachment will be blocked)
On Sat, Sep 2, 2017 at 7:23 AM, Thomas Eckardt <thomas.ecka...@thockar.com>
wrote:
> The next assp release as well as ASSP_AFC 4.61 will have a "-+" directive
> available - for example:
>
> block=>-+doc
>
> These exlusion directives will be processed at runtime (attachment check)
> - and will do the overwrite sender <> recipient - means here, 'doc' will be
> remove from the resuting attachment blocking regular expression for this
> mail (sender + recipient).
>
> It is not my problem if someone builds weak attachment checks - but for
> those who know what they do, it should be possible to do.
>
> Yes - and the GUI will get some more explanation. :)
>
> Thomas
>
>
>
>
>
>
>
>
> Von: Thomas Eckardt <thomas.ecka...@thockar.com>
> An: ASSP development mailing list <assp-test@lists.sourceforge.net>
> Datum: 02.09.2017 11:54
> Betreff: Re: [Assp-test] fixes in assp 2.5.6 build 17243
> ------------------------------
>
>
>
> 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* <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* <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* <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* <du...@localdomain.com> <
> *sen...@senderdomain.org* <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* <http://domain.com/>=>~~commonRule
> [IT]=>~~devRule
> *u...@domain.com* <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* <http://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*
> <http://sdm.link/slashdot>
> _______________________________________________
> Assp-test mailing list
> *Assp-test@lists.sourceforge.net* <Assp-test@lists.sourceforge.net>
> *https://lists.sourceforge.net/lists/listinfo/assp-test*
> <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*
> <http://sdm.link/slashdot>_______________________________________________
> Assp-test mailing list
> Assp-test@lists.sourceforge.net
> *https://lists.sourceforge.net/lists/listinfo/assp-test*
> <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*
> <http://sdm.link/slashdot>_______________________________________________
> Assp-test mailing list
> Assp-test@lists.sourceforge.net
> *https://lists.sourceforge.net/lists/listinfo/assp-test*
> <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
>
>
------------------------------------------------------------------------------
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
