This is simply terrific. You keep making ASAP better! The rebuild config efficiency improvements are especially appreciated. Thanks so much as usual for spending what must have been a long time thinking about and making all of these changes.
SURPRISE, I have questions and comments: *Fix to emailing report with attached .msg report not working?* *(if email reports need to be zipped, ignore this)* I just tested, sending a zip of a .msg has the analyze report works correctly. Sending just the .msg attachment with 21293 give the previous errors. *Sending just the .msg with this new 21302 unfortunately is worse and isn't working*. I'm now getting: found a possible MIME header start in the middle of the mail - the analyze may be wrong [CR][LF]<br /> • Subject: FW: test of report message[CR][LF]<br /> and even less info is shown in the emailed analyze report than before I had ReportLog set to debug. The .eml file that goes to debug is attached to this reply. *Clarification on the need now(?) to compress Emailed reports from Outlook* You wrote: "Notice: always compress (e.g. zip) reported emails before they are sent to assp!" The GUI says " It is also possible to send MS-outlook '.msg' files (possibly zipped)." Is it now required? I've always done "Forward as Attachment" in Outlook to report which attaches the current message as a .msg formatted file (I previously incorrectly wrote .eml) and seems to work (except for the analyze big that you're attempting to squash). The vast majority of our staff do the same, but requiring them to first save the .msg, then zip, then attach to report might be asking too much. While attached Outlook .msg files are binary, I don't >>think<< they're compressed. The .msg files always have made it to the corpus saved as plain text files which seems right. It was only the analyze report that was failing. *MaxBytesReports* The gui talks about MaxBytesReports. Any mail sent or forwarded by local/authenticated users to this username will be interpreted as a spam report. Multiple attachments get truncated to MaxBytesReports. Do not put the full address here, just the user part. For example: asspspam . Use a fake domain like @assp.local or @ assp-nospam.org when you send the email- so the full address would be then asspspam@assp.local. You can sent multiple mails as attachments and/or zipped file(s). Each attached email-file must have the extension defined in "maillogExt". In this case only the attachments will be processed. To use this multi-attachment-feature an installed Email::MIME module in PERL is needed. It is also possible to send MS-outlook '.msg' files (possibly zipped). To use this MS-outlook-feature in addition an installed Email::Outlook::Message module in PERL is needed. I don't see MaxBytesReports any where else in the code. Is this supposed to be MaxBytes? Also, GUI correction " You can sent multiple mails as attachments and/or zipped file(s)" should be "send" *Finding DKIM matches during rebuild:* AddDKIMHeader needs to be on right? Since it looks like the code is looking for the X-ASSP-DKIMIdentity line, I think you should add a comment for the hidden DoRBWhite parameter and others * that AddDKIMHeader in the GUI needs to be on for this to work. * Speed -> more configuration choices necessary? Great point about slowness in rebuild if this is all on and the recommendation of potentially only turning it on periodically. Since we're now doing more checks, does it make sense to have additional hidden parameters to give more granular control? I feel like I'll always want to check for whitelisted in spam no matter how it matches, but other might only want to consider DKIMWLAddress, while others don't want DKIMWLAddresses and only matches to the actual whitelist. How about letting DoRBWhite be configured with different values like we have for DoNoFrom? Match: 0: nothing 1: whiteRe 2: npRe 4: whiteListedDomains 8: noProcessingDomains 16: whiteListedIPs 32: noProcessingIPs 64: DKIMWLAddresses 128: DKIMNPAddresses and have those summed up? Too complicated for not enough value? Dunno, thinking out loud here. I'm cool with everything on, but maybe there are others who would prefer to more granularly configure? related: GUI mistake. the AddDKIMHeader description still says that it adds X-ASSP-DKIM: instead of "X-ASSP-DKIMidentity *DoRBBlack removal of deny matches -- curiosity:* For the new DoRBBlack, why is it checking denySMTPConnectionsFromAlways and denySMTPConnectionsFrom? Aren't additions made to that list after we've collected what we've wanted (good or bad) from those IP's / emails which would be good to have in the corpus? *NWLI* I'd like to rewrite the NWLI description at the bottom of the GUI, but I need clarification first. I'm sure NWLI functionality works in the code, it's just not explained well in the GUI. I see the revised language, but I'm still not sure that I follow. When you say "optional to use '+'" do you mean something N and N+ are functionally identical? If that's true, why bother having the + as an option at all? If there's a difference between having a plus and not, please explain. For starters, you have "So the line ~Heuristics|Email~=>50:>N-W-LI could be read as: take the regex with a weight of 50, never score noprocessing mails, never score whitelisted mails, score local mails and mails from ISP's." But if it's ANDed together, it would really mean score 50 to a mail that matches Heuristics|Email when that mail is NOT noprocessing, is NOT whitelisted, IS local AND IS ALSO is an ISP mail. To me, the way you have it written implies that it would score 50 if it's either local OR ISP as long as it's neither whitelisted nor noprocessing. Also, parameters are separated everywhere else that I see by => but the third parameter here needs to be :> My lousy eyes missed that until just now. Why the the inconsistency? *Other thanks, notes, and reqests* - Thanks for adding that explanation bit into the GUI and the icon! Also, this: Info: file D:/assp/IP-Lists/IPS-facebookmail.com.cfg is now stored encrypted, because it is used in secured config Groups Excellent - The ReportLog addition will be really helpful, even if just for periodic reviews of user submitted reclassifications vs ones I've done through the GUI. *Could we have it use the same file extension as we use for the corpus?* (maillogExt) - In the code, in some places X-Assp- headers are referenced, others have X-ASSP- All of the compares I've seen appear to be case insensitive, but you might consider standardizing so that type-a personalities can be calmed :) On Fri, Oct 29, 2021 at 10:31 AM Thomas Eckardt <thomas.ecka...@thockar.com> wrote: > Hi all, > > fixed in assp 2.6.6 *SPAM-Evaporator* build 21302: > > - Improved email address detection in the emailinterface list reports > (whitelistadd , whitelistremove, ....). > > - The change time for include files used in the 'Groups' feature were not > recorded in workers. This caused unexpected configuration reloads in the > workers, until > assp was restarted. > > - Any change made for 'Groups' caused a reload for all configuration > parameters where a group was used, even the related group was not changed. > A configuration reload is now > only done for changed groups and there related configuration parameters. > > - Unexpected results were produced by the analyzer, if emails were sent as > (not zipped) attachment to the emailinterface for analyzing - using outlook > as mail client (+exchange). > Notice: always compress (e.g. zip) reported emails before they are sent > to assp! > > > changed: > > - If the hidden parameter 'DoRBWhite' is set, the rebuildspamdb process > searches for matches in > whiteRe, npRe, whiteListedDomains, noProcessingDomains, whiteListedIPs, > noProcessingIPs, DKIMWLAddresses and DKIMNPAddresses - > and removes those mails from the assp/spam folder. > > > - 'ReportLog','Enable Report logging' > 'If set to diagnostic, each received report mail will be stored in the > assp/debug folder.' > This makes it more easy to track down report problems, based on the > data sent by the mail client to assp. > > - The GUI description for the NWLI enhancement (for regular expressions) > was updated. The code was changed to get the NWLI results exactly like > descriped in the GUI. > > - A hint (and context help) about encryped configuration parameters and > files was added to GUI. > > > added: > > The set hidden parameter > DoRBBlack = 0; # (0/1) check blacklisted mails on > rebuildspamdb (default 0 - 1 = skip rebuild for notspam if black) > removes all mails in the assp/notspam folder, which matches : > noBlockingIPs, denySMTPConnectionsFromAlways, denySMTPConnectionsFrom and > blackListedDomains > > Notice: if all of DoRBWhite, DoRBBlack and DoRBRed are enabled, the > rebuild process will take ~12 times (or very much) longer than without > setting these switches. > Don't be confused. If .eml files were corrected by spam/ham > reports, assp will process them correctly. But it may help to maintain the > corpus from time to time. > > > > Thomas > > 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! > ******************************************************* > > _______________________________________________ > Assp-test mailing list > Assp-test@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/assp-test >
_______________________________________________ Assp-test mailing list Assp-test@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/assp-test
