Thank you for the "input" and suggestions.
>Would it be possible to specify sender and recipient pairs?
I'll think about this.
>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.
This is the development test list - I expect, that every thread is read by
everyone.
>I definitely don't understand the good and blocked syntax of the current
address can be sender and/or recipient (both local and/or foreign)
block = block-in + block-out
block-in - for incoming mails
block-out for outgoing mails
same for good
rule:
block if
the mail and flow direction matches a defined block rule
or
the mail and flow direction NOT matches a defined good rule
just simple - isn't it?
from the GUI
..At least one of the above option must be defined in a line - a maximum
of all (six) could be defined, if this makes sense.....
This should and it is confusing (means read again) .... 'all six' makes
never sense!!!!
>URL blocking
????? to prevent misunderstandings - this discussion is about attachment
blocking
to block URL's use URIBL or spamBombs
Thomas
Von: K Post <nntp.p...@gmail.com>
An: ASSP development mailing list <assp-test@lists.sourceforge.net>
Datum: 21.08.2017 18:17
Betreff: Re: [Assp-test] More PDF Javascript catches
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> 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>
An: ASSP development mailing list <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
_______________________________________________
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
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
