Wow wee!!! This is terrific news!!
I'm wondering if you should pose your question as a new thread so that
others who typically ignore threads that they're not originally a part of
could chime in.
I like the idea of inheritance being turned on by default and using the
(-i) switch to turn it off for a given rule. I would ask that as rules get
further down the inheritance chain that they take precedence.
So if
policy1 is
~policyname => block => exe\-bin|url|ade|adp|asx|
and
* => policy1
userexecpt...@domain.com => block => exe\-bin|:MSOM
then userexcept...@domain.com would have url, ade, adp, asx blocked along
with exe's blocked EXCEPT for ms office macros even though policy1 is
inherited (which blocks office macros)
I'm not sure that I have a use for the whitelisted / no processing flags,
but that might become useful. I'd also ask here that if you implement
this, to be sure to make it clear that it's an OR of the type of matches,
vs a sender needing to be whitelisted and no processing in your (-i wl np)
example.
Other thoughts:
- Would it be possible to specify sender and recipient pairs?
That way we could let one user get a certain type of attachment from one
other outside user
(from: u...@outside-domain.com)ouru...@domain.com=> exe\-bin|:MSOM
- Good / Block and inheritance
I definitely don't understand the good and blocked syntax of the current
UserAttach implementation. I think that could use some clarification in
the gui. If you're reworking the UserAttach concept, maybe we could change
this?
If policy1 is defined as above, and we want to remove URL blocking for a
user, how would we do that?
* => policy1
allowurlu...@domain.com => good => URL
Would that add URL to good, thereby negating the block inherited from
policy1
Does adding good to the user make it so that URL is the ONLY type that
person can receive?
* => policy1
(-i)allowurlu...@domain.com => block => policy1|-URL
in this above example, that user has inheritance turned off, gets
policy1 and -URL removed from that list
or
* => policy1
allowurlu...@domain.com => block => -URL
Inheritance is on above, and URL is removed from that inherited list (I
think I like this syntax the best)
- We'd also need to consider the special case of zip's and encrypted
zips.
This functionality works well now. We'd just need to figure out a clean
way to keep the syntax clean.
Super excited to see where you take this. Happy to add input as needed.
THANK YOU
On Sat, Aug 19, 2017 at 4:25 AM, Thomas Eckardt <thomas.ecka...@thockar.com>
wrote:
> Hello everyone,
>
> the attachment level definitions are subject to be obsolet (removed) in a
> future release. Only 'UserAttach' will be available.
>
> I know, 'UserAttach' can currently be hard to manage - for example in
> large environments.
> What are my plans for this?
>
> - named policies (templates) can be defined - like: ~policyname => block
> => bla|blaa , .......
> - policies can be used any where - like : zip:a...@domain.com =>
> %policyname%
> - policies can be joined - like: :a...@domain.com => %policy1%|%policy2%
>
> Where I'm not sure - is it useable to implement a configurable inheritance
> functionality.
>
> * => policy1
> *@domain.com => policy2|policy3
> us...@domain.com => policy4
> (-i)us...@domain.com => policy4
> (-i)*@otherdomain.com => policy2|policy5
> us...@otherdomain.com => policy6
>
> If per default inheritance is enabled. The resulting configurations for
> each of the above lines would be:
>
> * => policy1
> *@domain.com => policy1|policy2|policy3
> us...@domain.com => policy1|policy2|policy3|policy4
> us...@domain.com => policy4
> *@otherdomain.com => policy2|policy5
> us...@otherdomain.com => policy2|policy5|policy6
>
> Or is it more practicable to have the inheritance switched off per default
> and it must be enabled for each line in question (i) ? (I prever the first
> variant - inheritance on per default)
>
> * => policy1
> (i)*@domain.com => policy2|policy3
> (i)us...@domain.com => policy4
> us...@domain.com => policy4
> *@otherdomain.com => policy2|policy5
> (i)us...@otherdomain.com => policy6
>
>
> And the last question - should it be possible to define dependencies for
> the different assp mail flags (whitelisted and noprocessing). like:
>
> (-i wl np)*@otherdomain.com => policy2|policy5
>
> where (-i wl np) will be interpreted as : inheritance OFF, applies to
> whitelisted and noprocessing senders only
>
> Any suggestion on this?
>
> Thomas
>
>
> Von: K Post <nntp.p...@gmail.com>
> An: ASSP development mailing list <assp-test@lists.sourceforge.net>
> Datum: 14.08.2017 15:22
> Betreff: Re: [Assp-test] More PDF Javascript catches
> ------------------------------
>
>
>
> As always, I appreciate your input. I feared this was going to be your
> response. Most of these erroneously blocked mails come from big providers
> (like travel agency confirmation pdfs). I'm surprised that they have
> javascript, but they do. We've been adding exceptions, which isn't fun,
> but is okay.
>
> Do you think there's a way you could change UserAttach, or add another
> exception list, to let us use variables like %LEVEL2% to indicate all of
> the Level 2 defined types and then use + or - notation to add or remove
> types? That would let us change Level2 in the GUI and not have to then go
> through all of the UserAttach exceptions and update them too.
>
> So something like this:
>
> Our Level 1 is exe\-bin|url|ade|adp|asx|bas|bat|dot|dotx|xlt|xlts|bin|chm|
> cmd|com|cpl|crt|dbx|dll|exe|hlp|hta|htb|inf|ifs|isp|js|
> jse|lnk|mda|mdb|mde|mdz|mht|msc|msi|msp|mst|nch|pcd|pif|
> prf|ps1|reg|scf|scr|sct|shb|shs|vb|vbe|vbs|vba|wms|wsc|
> wsh|rar|dotm|docm|xlsm|pptm
> Our Level 2 is (exe\-bin|url|ade|adp|asx|bas|
> bat|dot|dotx|xlt|xlts|bin|chm|cmd|com|cpl|crt|dbx|dll|exe|
> hlp|hta|htb|inf|ifs|isp|js|jse|lnk|mda|mdb|mde|mdz|mht|
> msc|msi|msp|mst|nch|pcd|pif|prf|ps1|reg|scf|scr|sct|shb|
> shs|vb|vbe|vbs|vba|wms|wsc|wsh|rar|dotm|docm|xlsm|pptm).zip
>
> This user needs to ALLOW office macros
> ouru...@ourcharity.org => block => *exe\-bin|:MSOM|*url|ade|adp|
> asx|bas|bat|dot|dotx|xlt|xlts|bin|chm|cmd|com|cpl|crt|dbx|
> dll|exe|hlp|hta|htb|inf|ifs|isp|js|jse|lnk|mda|mdb|mde|
> mdz|mht|msc|msi|msp|mst|nch|pcd|pif|prf|ps1|reg|scf|scr|
> sct|shb|shs|vb|vbe|vbs|vba|wms|wsc|wsh|rar|dotm|xlsm
>
> My proposal would be to instead have something like
> ouru...@ourcharity.org => block => %Leve2%|+:MSOM (add the :MSOM
> exception)
>
>
> Just a thought. Thanks
>
> On Thu, Aug 10, 2017 at 3:16 AM, Thomas Eckardt <
> *thomas.ecka...@thockar.com* <thomas.ecka...@thockar.com>> wrote:
> One line of bad JS code is enough to completely destroy an IT environment
> (petabytes of data and thousands of machines in some minutes).
> Such code can be encrypted, encoded and obviuscated in any not thinkable
> way.
>
> It is simply not possible to classify JS code or to know how any of the
> hundreds PDF viewers will act on such code.
>
> Accepting executable code from a sender is not a matter of classification
> - it is a matter of TRUST ! (I trust no one without human code verification)
>
> Define ':CERTPDF' and request the sender to sign there PDF files.
>
> For now, assp only checks that there is a certificated. In a future
> release the certificates may be verified and/or compared to a provided
> CERT-list.
>
>
>
> Thomas
>
>
>
>
>
> Von: K Post <*nntp.p...@gmail.com* <nntp.p...@gmail.com>>
> An: ASSP development mailing list <
> *assp-test@lists.sourceforge.net* <assp-test@lists.sourceforge.net>>
> Datum: 09.08.2017 15:54
> Betreff: [Assp-test] More PDF Javascript catches
> ------------------------------
>
>
>
>
>
> I really like the javascript detection in PDF files, but I've seen lots of
> false positives too.
>
> I keep meaning to report it. One file that just got caught has only 2
> lines of javascript
>
> 6 0 obj
> <</S/JavaScript/JS(this.zoom = 100;)>>
> endobj
>
>
> and
>
> 33 0 obj
> <</Dests 31 0 R/JavaScript 32 0 R>>
> endobj
>
> Is there anything more that could be done to be less aggressive but still
> give us good protection?
>
> Thanks! ----------------------------------------------------
> --------------------------
> 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>
>
>
>
>
> 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______
> _________________________________________
> 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
