AH!! It's literally the longest *match criteria or regex* that is checked
against the sender and recipient addresses vs which matching address is
actually longer?
So if I understand correctly, it's as if the UserAttach rules are sorted
first by length of the left most parameter of each rule with the longest
first and checked in that order. As soon as one match hits (including mail
direction), processing stops. (and then AFC does this again for zip rules?)
If the rules are (numbered for reference)
1 * => block => aaa
2 *@domain.com => block => bbb
3 *n...@domain.com => block => ccc
4 specificn...@domain.com => block => ddd
5 oneaddressofanouts...@sender.com => block => eee
Regardless of the length of the sender or recipient, the above rules would
be evaluated against each (And direction of mail) first starting with rule
5 for matches.
oneaddressofanouts...@sender.com
which regex matches rule 1 and 5, but rule's 5 regex match criteria is
longer so that would be found first
sends and email to
onereallyreallyreallylongaddr...@domain.com
which is a longer address than the sender, but that doesn't matter,
*only eee will be blocked*
because the number of characters in the criteria in rule 5 is longer than
those of rules 1 and 2.
Yes? Do I finally understand?
On Wed, Sep 6, 2017 at 3:14 AM, Thomas Eckardt <thomas.ecka...@thockar.com>
wrote:
> >*If they're not combined, which rule below would be enforced for
> noex...@seconddomain.com (batches both lines).*
> >*@SecondDomain.com => block => doc
> >NoExcel@* => block => xls
>
> This example is a very special case.
>
> Simply count the characters - the longest match will be used. The logic in
> the match lookup assumes - than longer a matchrule (user/domain name) is,
> than more specific it is.
> If two entries have the same length, an alphabetical sort is used.
>
> the exact logic is:
>
> - do we have an exact match for the lower cased email address - some thing
> like: lc 'u...@domain.com' eq lc 'u...@domain.com' - return this match
> - search the *longest* entry (user/domain) - *count *the characters
> - sort the entries* by alphabet* in *descending order* - by
> fillup all other entries to the size of the longest by adding spaces
> to the left hand side
> - find a match - top to bottom - return on first match
>
> the sorted entries (top to bottom) may look like:
>
> full_n...@any-domain.com
> full_nam*@any-domain.com
> afulln...@any-domain.com
> cull_n...@any-domain.com
> bfulln...@any-domain.com
> *fulln...@any-domain.com
> *x...@seconddomain.com
> *@SecondDomain.com
> NoExcel*@*
> NoExcel@*
> *
>
>
>
> For *noex...@seconddomain.com* - *@SecondDomain.com is the first match -
> NoExcel*@** will not be reached - NoExcel@** will be never ever reached
>
> For *noex...@other.com <noex...@other.com>* - *NoExcel*@** is the first
> match -*NoExcel@** will be never ever reached
>
> For bfulln...@any-domain.com - bfulln...@any-domain.com is the first match
>
> For ufulln...@any-domain.com - *fulln...@any-domain.com is the first match
>
> for bfulln...@1.any-domain.com - * is the first match
>
>
> In the example tree above, the entry 'NoExcel@*' may be removed - there
> is no such email address, that will reach and match this entry.
>
>
> Thomas
>
>
>
>
>
>
>
>
>
>
>
> Von: K Post <nntp.p...@gmail.com>
> An: ASSP development mailing list <assp-test@lists.sourceforge.net>
> Datum: 05.09.2017 19:42
> Betreff: [Assp-test] Questions on new UserAttach functionality,
> strategy in lieu of using Level defined Attachment Blocking
> ------------------------------
>
>
>
> You've said that the Level definitions for attachment blocking because of
> 1000's of v1 installations and lots of old v2 installations. These old
> software users don't know what they're missing!!!!
>
> I'm wondering, if I wanted to ignore level definitions in my installation,
> I could l*eave them blank* and the use rules in UserAttach right? I'm
> thinking of doing something like:
>
> [[ NOTE TO READERS, I'm using this rough example as a question for Thomas,
> the below is not a proposed solution for anyone to blindly follow ]
>
> # basic blocks - what was previously my Level1
> ~BasicBlocks => bin|exe\-bin|url|ade|adp|asx|
> bas|bat|dot|dotx|xlt|xlts|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
>
> # file types that are used to inspect zip files
> # look in zips for these bad files too bin type removed to allow
> formatted excel with printer settings through
> ~ZipBlocks => exe\-bin|url|ade|adp|asx|bas|bat|dot|dotx|xlt|xlts|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
>
> OR instead could I do this, using the ~BasicBlocks template to define the
> ZipBlocks template and remove bin with the -- switch. *Can one template
> be defined using another template* ???????
> ~ZipBlocks => ~BasicBlocks|--bin
>
> # Generic Block
> # applies to everyone *unless a more specific match is found* *right?? *
> *Or would this get added to other matches which could be a problem and
> makes this line a terrible idea (since I could remove a type for a specific
> internal recipient, but the external sender would still match this rule)*
> * => block => ~BasicBlocks
>
> # inspect zip files for everyone
> zip:* => block => ~ZipBlocks
>
> # let this one user send any zip file regardless of what's in it. Can
> also be an encrypted ZIP which AFC ordinarily blocks automatically
> *zip:encryptedzipsendero...@domain.com*
> <zip%3aencryptedzipsendero...@domain.com> => good-out => .*|crypt\-zip
> The above line ignores the zip:* => block => ~ZipBlocks rule for
> *encryptedzipsendero...@damain.com* <encryptedzipsendero...@damain.com>
> right?
>
>
> # let this one user get or send dot files, using -- exception
> *dotfileso...@domain.com* <dotfileso...@domain.com> => block =>
> ~BasicBlocks|--dot
> OR could I skip the ~BasicBlocks template here because the generic block
> above (* => block => ~BasicBlocks) is already applied, so something like:
> *dotfileso...@domain.com* <dotfileso...@domain.com> => block => --dot
> ????
>
>
> # let this one user get office macro files from anyone - even though this
> is an exception, I'm not using
> # the -- syntax since :MSOM is a special kind of exception removing this
> special type from the generic exe-bin
> *officemacroo...@domain.com* <officemacroo...@domain.com> => block =>
> ~BasicBlocks|:MSOM
>
>
> # rules are combined, so noex...@seconddomain.com would be able to get
> all attachments except for doc or xlst, but o...@seconddomain.com couldn't
> get doc but could Excel, and noex...@thirddomain.com coudln't get excel,
> but could get doc *right???? If they are combined, wouldn't the generic
> rule from above (* => block => ~BasicBlocks) also be applied? If they're
> not combined, which rule below would be enforced for
> noex...@seconddomain.com (batches both lines).*
> *@SecondDomain.com => block => doc
> NoExcel@* => block => xls
>
>
> I know some of my questions relate for functionality that hasn't changed
> in recent releases, but I've never used wildcard address matching in
> UserAttach, so I don't know practically what happens.
>
> 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
