As always, I appreciate your responses, but there's no need to be
patronizing. And so say that you've perfectly explained everything is the
GUI is a bit silly, I wouldn't be asking if you had done a better job
there, or you're just calling me an idiot. To say that you can't help if
anyone is "not able to understand" what you wrote, is pretty narrow
minded. Assuming my competency, maybe what you wrote just need CLEAR
CLARIFICATION. * I'm hoping that my question #2 below might show you how
there's room for interpretation of the GUI doc.*
Whatever the case, please know that *my goal is to obtain a better
understanding, get attachment filtering done the way my users need, and
hopefully help the ASSP community at the same time. * I know you're busy,
bright, and the only reason that I have any hope of time for my family at
the end of the day, but still, this is a place for discussion.
I think part of the problem here is translation. Maybe the German to
English in your head translation covers everything, but to native English
speakers isn't not quite clear? Once I understand this all, I bet I can
write it just as concisely but more clearly - and if you'll accept that,
I'd be more than happy to have that in the gui. If you recall, I've done
this for other sections over the years for you too.
1) [asked before but not addressed] If in level 1, .dll is listed,
shouldn't we expect a zip file that contains a .dll file to be rejected if
the AFC plugin is enabled? I'm not seeing that behavior (nothing matching
in UserAttach)
2) [ example of different interpretations being possible] You've said "if
there is a matching entry" in UserAttach. When you say match, do you mean
just matching the sender or receiver, or do you mean matching BOTH a
sender/receiver AND the direction of the rule?
Example in UserAttach:
[email protected] => good-in => .exe
If an .exe file comes inbound, I know they can get it
Level 1 is ignored, so that means that anything else can ALSO come *inbound*
(I think)
but is Level 1 also ignored for OUTBOUND email? I ask this because I don't
know if a "match" in userattach needs to *match both the user and the
direction or just the user. *
Does only having a good-in rule for a user allow all other attachment types
OUT because all levels are now ignored in either direction? If that's the
case, we'd need to copy the level definitions to each line in userattach
for them to be effective. Might we be able to have a variable definition
in UserAttach to make maintenance easier or a flag to include them with
userattach rules being additive for block and subtractive for allow (only
if this is easy for you to implement). For an admin with a dozen
exceptions, if I decide to change level1 to block some new sort of
attachment, I'd need to edit 12 lines of UserAttach too (right?(.
On Fri, Feb 19, 2016 at 12:15 AM, Thomas Eckardt <[email protected]
> wrote:
> >I have read the GUI, over and over, and over and over.
>
> reading is step one - think about is step two - leads in to understand,
> step three :):):)
>
> again:
>
> If there is a matching entry found in UserAttach - the entry is used and
> ALL level definitions are ignored.
>
> >From what I'm reading they're OR'ed together but is the action to
> allow or block.
>
> ASSP is a spam filter to BLOCK bad attachment. Blocking has and had the
> higher priority.
>
> This is the simple logic behind
>
> BLOCK IF
> (has blockrule and extension matches blockrule)
> or
> (has goodrule and extension not matches good rule)
>
> The used rules are 'OR' combined from the recipient and the sender, if
> both matches a rule.
>
> All these facts are perfecltly technical described in the GUI! Yes the
> description is short, but it exactly points out all required facts.
>
> If anybody is not able to understand
>
> "If the user name matches for a sender or recipient and a (in/out) regex
> definition is found in this file"
> and
> "all level definition are overwritten for this mail"
> and
> "will be logical OR combined according to the mail flow"
>
> I can not help. Use the old way (level definitions).
>
>
> Thomas
>
>
>
> Von: K Post <[email protected]>
> An: ASSP development mailing list <[email protected]>
> Datum: 19.02.2016 05:32
> Betreff: Re: [Assp-test] AFC Plugin, UserAttach. Encrypted zip
>
>
>
> I'm sorry to irritate you, really I am, but I have read the GUI, over and
> over, and over and over. Seeing it here doesn't help. To me - very
> technical, English speaker, decades of experience - the GUI is not clear.
> Maybe if I had a better understanding of the intent of your writing / how
> ASSP works here I could help to re-write (just) the description for this
> section.
>
> "No rule, no check" is a start for complete understanding, but the gui
> also
> says " If the user name matches for a sender or recipient and a (in/out)
> regex definition is found in this file, *all level definition are
> overwritten* for this mail." I'm not sure if what you wrote in the
> email
> and the gui contradict each other or not. For an example of my confusion,
> if there is a good-*out* rule only for a user and no good-in, bad-in, or
> bad-out , does that mean that the level 1 block rules are overwritten and
> that user may only send the attachment types specified in good-out, but
> may
> not receive ANY attachments, or are is attachment type now accepted
> because
> there wasn't a good-in or bad-in specified for that user?
>
> What if the receiving user has .doc allowed but the sending user has .doc
> blocked? From what I'm reading they're OR'ed together but is the action
> to
> allow or block. Block the attachment if it's a .doc OR allow it if it's a
> .doc Which has priority?
>
> And last for now, given the level 1 line that I provided, shouldn't a zip
> containing a DLL file be removed from the email? It's not.
>
> Thanks again.
>
> On Thu, Feb 18, 2016 at 12:15 AM, Thomas Eckardt
> <[email protected]
> > wrote:
>
> > THE GUI!
> > If the user name matches for a sender or recipient and a (in/out)
> regex
> > definition is found in this file, all level definition are overwritten
> for
> > this mail.
> > good, good-out and good-in - and also - block, block-out and block-in
> -
> > will be logical OR combined according to the mail flow.
> >
> > >If so, what does a blank good-in and bad-in rule do? Everything is
> good,
> > >but everything is bad? Which wins?
> >
> > No rule - no check.
> >
> >
> > If I define a zip: line for a specific user but not a non-zip: line,
> will
> > the level 1,2,3,4 blocks still be effective?
> >
> > yes - zip: (as written in the doc) is an extension provided by AFC.
> >
> > Thomas
> >
> >
> >
> > Von: K Post <[email protected]>
> > An: ASSP development mailing list <[email protected]>
> > Datum: 18.02.2016 01:56
> > Betreff: Re: [Assp-test] AFC Plugin, UserAttach. Encrypted zip
> >
> >
> >
> > Here's my pertinent settings:
> >
> > DoBlockExes block
> > BlockExec (external) Level 2
> > BlockWLExes Level 1
> > BlockNPExecs Level 1
> >
> > BaddAttachLevel1
> >
> >
>
> 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
> >
> > Levels2, 3, 4 are currently blank
> >
> > In UserAttach I have only this:
> >
> > zip: [email protected] => good-out => *|crypt\-zip
> >
> > DoASSP_AFC enabled
> > ASSP_AFCblockEncryptedZip is checked
> >
> > No matter if the documentation is clear, I find the options to be a bit
> > convoluted and the way I understand it doesn't match what I see
> happening.
> >
> > Here's what happening for me
> >
> > 1) No user may send or receive encrypted zip files except
> > [email protected] [as expected]
> > 2) If I didn't have the *|crypt\-zip and instead just had crypt\-zip,
> > allowed@ourdomain could not send non-encrypted zip files [as expected]
> > 3) files that match level 1 (but aren't zipped) are blocked for all
> users
> > [as expected]
> >
> > 4) The [email protected] user, the one who is in the UserAttach
> file,
> > CAN receive zip files (just not encrypted) despite what you've
> explained.
> > I thought you said that if the line isn't fully defined, everything else
> > would be a block. [*not as expected*]
> > 5) all users >can< receive zip files that contain dll files as an
> example.
> > I though that they'd be disallowed as dll is in level 1 [*not as
> > expected*]
> >
> > 6) I didn't test [email protected] and other non-zip attachments.
> What
> > would you expect to happen?
> >
> >
> > *So, let me please restate my questions, maybe more clearly?*
> > Based on my settings, does it look like I'm doing something wrong? Is
> it
> > working as expected, but I just don't understand?
> >
> > If there isn't a FULLY definted UserAttach line for a user and there's
> > only
> > say a good-out, are you saying that bad-out, bad-in, and good-in will be
> > considered to be blank?
> > If so, what does a blank good-in and bad-in rule do? Everything is
> good,
> > but everything is bad? Which wins?
> >
> > If I define a zip: line for a specific user but not a non-zip: line,
> will
> > the level 1,2,3,4 blocks still be effective?
> >
> >
> > On Wed, Feb 17, 2016 at 12:40 PM, Thomas Eckardt
> > <[email protected]
> > > wrote:
> >
> > > The doc is clear. If a user entry is made and matches - all level
> > > definitions are skipped!
> > > Yes, zip: definitions have to be made explicite.
> > > If you want to act AFC the same way for regular attachments and zip
> file
> > > content, you'll need two identical definitions - one without and one
> > with
> > > the leading zip:
> > >
> > > Thomas
> > >
> > >
> > >
> > >
> > >
> > > Von: K Post <[email protected]>
> > > An: ASSP development mailing list
> <[email protected]>
> > > Datum: 17.02.2016 16:39
> > > Betreff: Re: [Assp-test] AFC Plugin, UserAttach. Encrypted zip
> > >
> > >
> > >
> > > and a followup, even though I've got both exe-bin and dll listed in
> > level
> > > 1, it seems that zip files that include those extensions are still
> > allowed
> > > through to / from all users.
> > >
> > > Is there a way to have AFC block attachments for all (not counting
> > > UserAttach exceptions) if any level 1,2,3 file is inside a zip? I'm
> > not
> > > talking encrypted, just a regular zip.
> > >
> > > On Wed, Feb 17, 2016 at 9:55 AM, K Post <[email protected]> wrote:
> > >
> > > > sorry, hit send by mistake....
> > > >
> > > > If I put a line like
> > > >
> > > > zip: theuser@ourdomain => => good-out => crypt\-zip
> > > >
> > > > 1) that will allow the encrypted zips right?
> > > >
> > > > 2) Will that block the person from being able to send zips that are
> > NOT
> > > > encrypted? If so, how do we allow encrypted zips and any other zip
> > to
> > > go
> > > > EXCEPT those that contain something prohibited by Level 1?
> > > >
> > > > 3) The description's unclear to me - if you have a line in the user
> > > > attach file but only specify what IS allowed and don't have a block
> > bit
> > > to
> > > > the line, does that remove all blocks from Level 1 etc?
> > > >
> > > > 4) If I wanted different attachment handling for a person and
> > different
> > > > zip handling for that same person, am I correct in saying that I'd
> use
> > 2
> > > > lines in userattach, one normal, and one prefixed with zip?
> > > >
> > > > THANK YOU
> > > >
> > > >
> > > >
> > > > On Wed, Feb 17, 2016 at 9:49 AM, K Post <[email protected]> wrote:
> > > >
> > > >>
> > > >> I've read and reread the gui, but still am not completely clear.
> > > >>
> > > >> Attachment blocking works well. We don't allow, in or out, the
> > > standard
> > > >> stuff: exe, etc.
> > > >>
> > > >> I've got ASSP_AFCblockEncryptedZIP checked, and that works well
> too.
> > > >>
> > > >> My problem is that I've got 2 users who need to be able to send
> > > encrypted
> > > >> zip files, but not receive them. All other restrictions, in and
> out,
> > > for
> > > >> those users should be the standard.
> > > >>
> > > >> I assume I use UserAttach for this. If I understand correctly, if
> I
> > > had
> > > >> a regular line in UserAttach, that will override everything else in
> > the
> > > >> attachment blocking section.
> > > >>
> > > >> If I put a line like
> > > >>
> > > >> zip: theuser@ourdomain => => good-out => crypt\-zip
> > > >>
> > > >> 1) that will allow the encrypted zips right?
> > > >>
> > > >> 2) Will that block the person from being able to send zips that are
> > NOT
> > > >> encrypted?
> > > >>
> > > >
> > > >
> > >
> > >
> >
> >
>
> ------------------------------------------------------------------------------
> > > Site24x7 APM Insight: Get Deep Visibility into Application Performance
> > > APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
> > > Monitor end-to-end web transactions and take corrective actions now
> > > Troubleshoot faster and improve end-user experience. Signup Now!
> > > http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
> > > _______________________________________________
> > > Assp-test mailing list
> > > [email protected]
> > > 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!
> > > *******************************************************
> > >
> > >
> > >
> > >
> >
> >
>
> ------------------------------------------------------------------------------
> > > Site24x7 APM Insight: Get Deep Visibility into Application Performance
> > > APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
> > > Monitor end-to-end web transactions and take corrective actions now
> > > Troubleshoot faster and improve end-user experience. Signup Now!
> > > http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
> > > _______________________________________________
> > > Assp-test mailing list
> > > [email protected]
> > > https://lists.sourceforge.net/lists/listinfo/assp-test
> > >
> > >
> >
> >
>
> ------------------------------------------------------------------------------
> > Site24x7 APM Insight: Get Deep Visibility into Application Performance
> > APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
> > Monitor end-to-end web transactions and take corrective actions now
> > Troubleshoot faster and improve end-user experience. Signup Now!
> > http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
> > _______________________________________________
> > Assp-test mailing list
> > [email protected]
> > 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!
> > *******************************************************
> >
> >
> >
> >
>
> ------------------------------------------------------------------------------
> > Site24x7 APM Insight: Get Deep Visibility into Application Performance
> > APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
> > Monitor end-to-end web transactions and take corrective actions now
> > Troubleshoot faster and improve end-user experience. Signup Now!
> > http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
> > _______________________________________________
> > Assp-test mailing list
> > [email protected]
> > https://lists.sourceforge.net/lists/listinfo/assp-test
> >
> >
>
> ------------------------------------------------------------------------------
> Site24x7 APM Insight: Get Deep Visibility into Application Performance
> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
> Monitor end-to-end web transactions and take corrective actions now
> Troubleshoot faster and improve end-user experience. Signup Now!
> http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
> _______________________________________________
> Assp-test mailing list
> [email protected]
> 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!
> *******************************************************
>
>
>
> ------------------------------------------------------------------------------
> Site24x7 APM Insight: Get Deep Visibility into Application Performance
> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
> Monitor end-to-end web transactions and take corrective actions now
> Troubleshoot faster and improve end-user experience. Signup Now!
> http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
> _______________________________________________
> Assp-test mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/assp-test
>
>
------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
_______________________________________________
Assp-test mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/assp-test
