<div dir="ltr">Yes, really. ufdbGuard, like squidGuard before it, is a URL Filter that filters known unwanted URLs. A content filter, like DansGuardian and E2Guardian are content filters which examine the content of web pages looking for unwanted things.<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Aug 16, 2015 at 6:10 PM, Yuri Voinov <span dir="ltr"><<a href="mailto:yvoinov@gmail.com" target="_blank">yvoinov@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  
    
  
  <div text="#000000" bgcolor="#FFFFFF"><span class="">
    <br>
    -----BEGIN PGP SIGNED MESSAGE----- <br>
    Hash: SHA256 <br>
     <br></span>
    O, really?<br>
    <br>
    17.08.15 4:03, Stanford Prescott пишет:<br>
    <span style="white-space:pre-wrap"><span class="">> ufdbGuard is not a content
      filter.<br>
      ><br>
      > On Sun, Aug 16, 2015 at 4:07 PM, Yuri Voinov
      <a href="mailto:yvoinov@gmail.com" target="_blank"><yvoinov@gmail.com></a> wrote:<br>
      ><br>
      >><br></span><div><div class="h5">
      > ufdbguard does.<br>
      ><br>
      > 16.08.15 20:27, Stanford Prescott пишет:<br>
      ><br>
      > >>> I have SquidClamAV implemented with the
      Smoothwall Express 3.1 firewall.<br>
      > It<br>
      > >>> works well and fast with ssl-bump, although the
      majority of our users<br>
      > only<br>
      > >>> have relatively small networks with smaller
      loads.<br>
      > >>><br>
      > >>> FYI, E2Guardian has replaced the DansGuardian
      project and is currently<br>
      > well<br>
      > >>> maintained. E2Guardian can do content filtering
      for SSL but only in<br>
      > >>> explicit mode, It currently does not support
      intercept (transparent) mode<br>
      > >>> for SSLBump.<br>
      > >>><br>
      > >>> On Fri, Aug 14, 2015 at 10:51 AM, Alex Rousskov
      <<br>
      > >>> <a href="mailto:rousskov@measurement-factory.com" target="_blank">rousskov@measurement-factory.com</a>> wrote:<br>
      > >>><br>
      > >>>> On 08/13/2015 10:31 PM, Amos Jeffries wrote:<br>
      > >>>>> AFAICS it<br>
      > >>>>> is the backend AV library only scanning
      disk objects that causes the<br>
      > >>>>> whole issue. Otherwise the eCAP could be
      much, much faster.<br>
      > >>>><br>
      > >>>> The situation is more nuanced: eCAP supports
      asynchronous adapters. It<br>
      > >>>> is possible to write a ClamAV adapter that
      writes messages to disk and<br>
      > >>>> analyses them without blocking Squid. Doing
      so should eliminate most<br>
      > >>>> overheads between Squid and ClamAV.<br>
      > >>>><br>
      > >>>> Factory ClamAV adapter can run in
      asynchronous mode, but threads are<br>
      > >>>> only used for _analysis_ of written files.
      We have not optimized the<br>
      > >>>> file writing part (yet?). Hopefully, using a
      RAM-based file system can<br>
      > >>>> mitigate a large part of that performance
      damage (as well as address<br>
      > >>>> some of the security concerns related to
      disk storage?).<br>
      > >>>><br>
      > >>>> A bigger performance problem, AFAICT, is
      that ClamAV does not support<br>
      > >>>> incremental analysis. It waits for the
      entire file to be downloaded<br>
      > >>>> first. This breaks the message delivery
      pipeline and increases<br>
      > >>>> user-perceived response time. This problem
      cannot be solved outside the<br>
      > >>>> ClamAV library.<br>
      > >>>><br>
      > >>>><br>
      > >>>> Cheers,<br>
      > >>>><br>
      > >>>> Alex.<br>
      > >>>><br>
      > >>>>
      _______________________________________________<br>
      > >>>> squid-users mailing list<br>
      > >>>> <a href="mailto:squid-users@lists.squid-cache.org" target="_blank">squid-users@lists.squid-cache.org</a><br>
      > >>>>
      <a href="http://lists.squid-cache.org/listinfo/squid-users" target="_blank">http://lists.squid-cache.org/listinfo/squid-users</a><br>
      > >>>><br>
      > >>><br>
      > >>><br>
      > >>><br>
      > >>> _______________________________________________<br>
      > >>> squid-users mailing list<br>
      > >>> <a href="mailto:squid-users@lists.squid-cache.org" target="_blank">squid-users@lists.squid-cache.org</a><br>
      > >>>
      <a href="http://lists.squid-cache.org/listinfo/squid-users" target="_blank">http://lists.squid-cache.org/listinfo/squid-users</a><br>
      ><br>
      >><br>
      >><br>
      >> _______________________________________________<br>
      >> squid-users mailing list<br>
      >> <a href="mailto:squid-users@lists.squid-cache.org" target="_blank">squid-users@lists.squid-cache.org</a><br>
      >> <a href="http://lists.squid-cache.org/listinfo/squid-users" target="_blank">http://lists.squid-cache.org/listinfo/squid-users</a><br>
      >><br>
      >><br>
      ></div></div></span><div><div class="h5"><br>
    <br>
    -----BEGIN PGP SIGNATURE-----
<br>
    Version: GnuPG v2
<br>
     <br></div></div>
    iQEcBAEBCAAGBQJV0QpsAAoJENNXIZxhPexG24gIAMNuWsyfn/QkXWTXROZEJYL1
<br>
    0frhC+w22fjV8svGjTrZEtSKY4LTHiHEjp99bPBEpPdoCURifUq20m018qRoIcEA
<br>
    XZfadD+s47bT7FvZbc2W58BQZUsWvotQRMNDPE+Mf0e38ev6PXsj16SaHmWytdx2
<br>
    Z9H0y5qlgJwwbUyfps4uQn1wF16Qlf2Fw5TGRUbBrij+rjPYzDSXTXxtfT+4j/3V
<br>
    4lZ0bN0HSFfvJrbfcpPoMCnSlRyJOm/b6Rxqv7v733OtrY/41EW1+HE1HOmW0em3
<br>
    rwpAV1KgWrwMZYHcIBE147itXlz1RGQutX01auiiSvm/hO3h78rl6aSawmanOAM=
<br>
    =GgTR
<br>
    -----END PGP SIGNATURE-----
<br>
    <br>
  </div>

</blockquote></div><br></div>