answering part of one of my own questions - I hope correctly.

   - *And in the end, how is a match on the griplist scored?  Let's say an
   IP is on the griplist as being a really bad IP.  What score does a message
   get?  Is that configurable? *

gripValancePB (default of 5) is added or subtracted from the message
score.  If the grip value is more than .7 the score gets added, if less
than .3, the score gets subtracted.

Under noGriplistUpload it says:

Check this to disable the Griplist upload. *The Griplist contains IPs and
their value between 0 and 1, lower is less spammy, higher is more spammy.
This value is called the grip value.*


*I feel like that description is in the wrong place.  *My suggestion: move
the bolded part of the GUI entry above to the griplist entry.  Or at least
also have it there.  If you've got an entry in griplist, you're using the
griplist, so I believe that's where the explanation should go, instead of
in the section where you decide to share and use a shared griplist.
(I still can't figure out if you do share and download the griplist it that
download replaces your local griplist or what)




On Sat, Oct 9, 2021 at 10:19 AM K Post <nntp.p...@gmail.com> wrote:

> Several related items here:
>
>    1. Bug? Rebuild process still uploading griplist, even if disabled,
>    due possibly to case error in code.
>
>    2. ASSP not checking for valid griplist, if an invalid folder name is
>    entered
>
>    3. On windows, Rebuild process
>    leaving \tmpDB\rebuildDB\BDB-error.txt handle open  (wider issue with
>    DBD-error.txt files getting stuck open on Windows?)
>
>    4. Griplist clarification request
>
>
> 1)  I've got noGriplistUpload and noGriplistDownload both checked in the
> GUI.  But I noticed that ,at the end of my rebuild log, it's still doing
> the upload
>
> Uploading Griplist via Direct Connection
>
>
> rebuildspamdb.pm has
>
> return if $main::noGripListUpload;
>
> before the upload happens, but I think there's a case mistake there.
>
>
> I believe it should be Griplist, with a lower case L.
>
>
> 2) In trying to figure out my ASSP on Windows crashes due to too many open
> files, I've started using Sysinternals Handle utility to look at open
> handles.  Yesterday I saw 1300+ handles open
> to d:\assp\tmpDB\Griplist\BDB-error.txt
>
> I believe that had something to do with me having an invalid griplist
> database name, "d/griplist" but the d folder didn't exist on my new server
> config!!  My fault there for sure, not sure how d/ prefixed it, but it
> appears ASSP didn't check to see that the folder existed.  Shame on me for
> missing my config file, but it might be good for ASSP to warn or create the
> folder if it doesn't exist.
>
> I cleared out the griplist database file to test and restarted. I don't
> see any more open griplist\dbd-error.txt handles, even though I'm getting
> many many bad SMTP servers connecting with early TLS.  Good.  I'll probably
> put the griplist database back (obviously with a valid filename!!)    See
> #3....
>
>
> 3) Windows (both 2012 and 2019) might not be closing Berkely error files
> correctly in general.
>
> When the new version started logging the new SSL errors, I >believe<
> that's when it started trying to access the non-existent "d/" folder config
> error in m assp.cfg.  Every time an early TLS line was caught, BerkeleyDB
> would keep the error file open.  Strangely, the error file was 0kb.
>
> Now that I've cleared out the griplist entry, I don't get those
> /tmpdb/griplist/dbd-error.txt open handles.  However, after my rebuild over
> night, I see and open handle to:
>
> tmpDB\rebuildDB\BDB-error.txt
>
> about 9+ hours after rebuild.
>
> Is that normal?  Might Windows not be closing handles correctly in general?
>
> 4) While I'm at it, could some clarification be provided as to the
> function of the griplist?  (and please correct me if anything I say here is
> incorrect!!)  I've searched like crazy over the last couple of days, but
> can't find the answers I'm looking for.
>
> The griplist is an ip scoring database correct?  I know it was originally
> called the grey-ip-list, 15+ years ago, but then greylisting became common
> language for delaying, so the original grayiplist started being called the
> "griplist" to avoid confusion.
>
> Note: the gui still says:
>
> GreyIPlist Database (griplist)
> The file with the current Grey-IP-List database -- make this blank if you
> don't use it.
>
> If I'm understanding griplist correctly, I think the gui should be
> reworded.  Maybe some explanation added too??
>
> There's also the optional upload and download concept of the griplist.
> This appears to send the local griplist to sourceforge, it gets processed
> by whatever you've got running on the backend, and then I can (also
> optionally) download another griplist which is based on all ASSP user
> data.  If you don't upload, you can't download, and that's fair - you need
> to contribute to benefit from the group.
>
> The charity that I work for has a pretty poorly thought out privacy policy
> that requires me to jump through all kinds of hoops when sharing >any<
> information.  It's frustrating for sure. That means I cannot upload our
> griplist without petitioning an internal committee.  I'm thinking I want to
> do that, but need to fully understand the griplist first.
>
>
>    - If we don't upload/download, the griplist is stlil maintained
>    locally, just only with my data right?
>    - If I get approval to share the ip data and download the griplist,
>    that downloaded griplist is merged with my local griplist?
>    - And in the end, how is a match on the griplist scored?  Let's say an
>    IP is on the griplist as being a really bad IP.  What score does a message
>    get?  Is that configurable?
>
>
> As always, thank you
> Ken
>
>
>
>
>
_______________________________________________
Assp-test mailing list
Assp-test@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/assp-test

Reply via email to