[sniffer] Re: Adding Message Sniffer to Zimbra
On 2015-02-10 01:20, Daniel Bayerdorffer wrote: > But there are no headers in the messages showing snf's results. I can see > that the snf4sa.cf has it set to add them though. > > # Header line containing the results from SNFServer. > add_header all SNF-Result _SNFRESULTTAG_ > add_header all MessageSniffer-Scan-Result _SNFMESSAGESNIFFERSCANRESULT_ > add_header all MessageSniffer-Rules _SNFMESSAGESNIFFERRULES_ > add_header all GBUdb-Analysis _SNFGBUDBANALYSIS_ > > Do you have any more suggestions? Unfortunately, some implementations of SA are hiding these headers. We've seen this a few times recently. There doesn't seem to be a way around it outside of hacking SA itself. (A few people have done that,... but it was ugly). If you want to be able to more easily associate SNF logs with messages you might consider changing SNF's message identifier to use the Message ID. http://www.armresearch.com/Documentation/QA/ltidentifiergt-2021367617.jsp _M -- Pete McNeil Chief Scientist ARM Research Labs, LLC www.armresearch.com 866-770-1044 x7010 twitter/codedweller # This message is sent to you because you are subscribed to the mailing list . This list is for discussing Message Sniffer, Anti-spam, Anti-Malware, and related email topics. For More information see http://www.armresearch.com To unsubscribe, E-mail to: To switch to the DIGEST mode, E-mail to To switch to the INDEX mode, E-mail to Send administrative queries to
[sniffer] milter and smtp auth
Hi all, We are using SNFMilter for some time now. Many (most) of our users are working from outside our LAN. They connect to Port 25 of our server for mailrelay after a successful SMTP AUTH. Sometimes we see false positives from some of the users although they have been authenticated correctly. Is there a way to tell SNFMilter to whitelist authenticated users? As far as I know it is easy for a milter to see if a client was successfully authenticated through SMTP Auth. Here is a old thread pointing out how to recognize a authenticated Client: http://lists.roaringpenguin.com/pipermail/mimedefang/2005-October/028522.html This is mimedefang specific of course, but the Macro "auth_type" is generic for the Milter protocol. Thanx and regards Thomas # This message is sent to you because you are subscribed to the mailing list . This list is for discussing Message Sniffer, Anti-spam, Anti-Malware, and related email topics. For More information see http://www.armresearch.com To unsubscribe, E-mail to: To switch to the DIGEST mode, E-mail to To switch to the INDEX mode, E-mail to Send administrative queries to
[sniffer] Re: milter and smtp auth
On 2015-02-10 11:23, Thomas Klaube wrote: > Sometimes we see false positives from some of the users although > they have been authenticated correctly. Is there a way to tell > SNFMilter to whitelist authenticated users? There is no such mechanism in Message Sniffer at this time. I might also point out that white-listing mechanisms generally lead to abuse. For example, much of the worst malware these days infects a machine, gain's authentication through email and other systems, and then uses the authenticated accounts to spread itself further -- this vector takes advantage of social hacking (trust of known friends/peers) and hard security hacking (by gaining access to secured accounts the old fashioned way, by stealing the keys). We don't get many requests for this kind of thing -- I'm pretty sure this is the first time I've heard this one. SNFMilter is distributed as source code so you certainly could code this modification yourself if you need it for your system, or you might use a different milter to force acceptance of messages that you've whitelisted either by list or by behavior. Please if you do find a false positive do report it to us so that we can adjust the filters appropriately... much better to get the filtering right than to make holes in it. For reference: http://www.armresearch.com/Support/falsePositives.jsp Best, _M -- Pete McNeil Chief Scientist ARM Research Labs, LLC www.armresearch.com 866-770-1044 x7010 twitter/codedweller # This message is sent to you because you are subscribed to the mailing list . This list is for discussing Message Sniffer, Anti-spam, Anti-Malware, and related email topics. For More information see http://www.armresearch.com To unsubscribe, E-mail to: To switch to the DIGEST mode, E-mail to To switch to the INDEX mode, E-mail to Send administrative queries to
[sniffer] Re: Adding Message Sniffer to Zimbra
Hi Pete, I implemented the identifier option. Thanks for the advice. I've also finally seen an email where spamassassin is acknowledging some input from SNF. X-Spam-Status: Yes, score=14.214 tagged_above=-10 required=6.6 tests=[BAYES_95=3, KB_DATE_CONTAINS_TAB=2.751, RCVD_IN_BL_SPAMCOP_NET=1.347, RCVD_IN_BRBL_LASTEXT=1.449, RCVD_IN_XBL=0.375, RDNS_NONE=0.793, SNF4SA=4.000, TAB_IN_FROM=0.499] autolearn=no autolearn_force=no That is mostly what I'm looking for, but the identifier option will be helpful for debugging. Thanks again for all your help! Daniel - Original Message - From: "Pete McNeil" To: "Message Sniffer Community" Sent: Tuesday, February 10, 2015 9:20:31 AM Subject: [sniffer] Re: Adding Message Sniffer to Zimbra Unfortunately, some implementations of SA are hiding these headers. We've seen this a few times recently. There doesn't seem to be a way around it outside of hacking SA itself. (A few people have done that,... but it was ugly). If you want to be able to more easily associate SNF logs with messages you might consider changing SNF's message identifier to use the Message ID. http://www.armresearch.com/Documentation/QA/ltidentifiergt-2021367617.jsp # This message is sent to you because you are subscribed to the mailing list . This list is for discussing Message Sniffer, Anti-spam, Anti-Malware, and related email topics. For More information see http://www.armresearch.com To unsubscribe, E-mail to: To switch to the DIGEST mode, E-mail to To switch to the INDEX mode, E-mail to Send administrative queries to
[sniffer] Re: Adding Message Sniffer to Zimbra
Hi Linda (and the Sniffer community), I just wanted to let everyone know what I ended up doing to work with Zimbra. I copied the snf4sa.pm and snf4sa.cf files to the /opt/zimbra/data/spamassassin/localrules directory per this Zimbra wiki article https://wiki.zimbra.com/wiki/SpamAssassin_Customizations The spamassassin implementation in Zimbra blocks SNF Headers from being added to emails. So I took Pete's advice and turned on the option in the /etc/snf-server/SNFServer.xml file http://www.armresearch.com/Documentation/QA/ltidentifiergt-2021367617.jsp Everything appears to be working great! Thanks, Daniel From: Daniel Bayerdorffer [mailto:dani...@numberall.com] Sent: Wednesday, February 04, 2015 10:08 AM To: Linda Pagillo; Message Sniffer Community Subject: Re: [sniffer] Re: Adding Message Sniffer to Zimbra Hi Linda, Thank you for the useful advice! I will be working on this next week, and I'll let you know how it turns out. I also found some useful information on Zimbra's Wiki. https://wiki.zimbra.com/wiki/SpamAssassin_Customizations I'm looking forward to the reduction in spam! Thanks, Daniel From: "Linda Pagillo" < linda.pagi...@mailsbestfriend.com > To: "Daniel Bayerdorffer" < dani...@numberall.com > Sent: Tuesday, February 3, 2015 5:40:34 PM Subject: [sniffer] Re: Adding Message Sniffer to Zimbra Hi Daniel. I was hanging out in the Message Sniffer Community forums and saw that you had a question about Message Sniffer and Zimbra. I have actually set up a Zimbra/Postfix/SpamAssassin server with the SNF4SA plug-in. When I set it up, I simply added the lines for the SNF4SA to SpamAssassin’s local.cf file and it has been working without issue since. However, we have not upgraded the Zimbra server, so I’m not sure if those settings would be overwritten if we did. To avoid that, you could create a file called something like aaalocal.cf and add the SNF4SA lines to that file. That would prevent the settings from being overwritten if a Zimbra upgrade did overwrite the local.cf. I hope this helps. Thanks! Linda Pagillo Mail's Best Friend Email: linda.pagi...@mailsbestfriend.com Web: www.mailsbestfriend.com Office: 703.988.3605 x7016
[sniffer] Re: milter and smtp auth
Ursprüngliche Mail - > Von: "Pete McNeil" > An: "Message Sniffer Community" > Gesendet: Dienstag, 10. Februar 2015 17:40:02 > Betreff: [sniffer] Re: milter and smtp auth > > > There is no such mechanism in Message Sniffer at this time. > > I might also point out that white-listing mechanisms generally lead to > abuse. I tend to agree that white-listing is usually not the best solution But please consider this case: one of our users tries to relay mail through our servers and is originating from a Dial-up IP address with very bad reputation (maybe within "truncate") but is correctly authenticated. Would you agree that such mails should not be marked as spam or even discarded (at least not based on IP address reputation)? > SNFMilter is distributed as source code so you certainly could code this > modification yourself if you need it for your system, or you might use a > different milter to force acceptance of messages that you've whitelisted > either by list or by behavior. I will consider this option. > Please if you do find a false positive do report it to us so that we can > adjust the filters appropriately... much better to get the filtering > right than to make holes in it. This is what we do. But we receive quite many false positives alerts from our users, and it is a time consuming task to report all the false-positives. Very often we are not sure, whether these false positiv reports improve filter quality... Regards Thomas # This message is sent to you because you are subscribed to the mailing list . This list is for discussing Message Sniffer, Anti-spam, Anti-Malware, and related email topics. For More information see http://www.armresearch.com To unsubscribe, E-mail to: To switch to the DIGEST mode, E-mail to To switch to the INDEX mode, E-mail to Send administrative queries to
[sniffer] Re: milter and smtp auth
On 2015-02-10 14:53, Thomas Klaube wrote: >> I might also point out that white-listing mechanisms generally lead to >> > abuse. > I tend to agree that white-listing is usually not the best solution > > But please consider this case: one of our users tries to relay mail > through our servers and is originating from a Dial-up IP address with > very bad reputation (maybe within "truncate") but is correctly authenticated. > Would you agree that such mails should not be marked as spam or even > discarded (at least not based on IP address reputation)? > My answer in this case is - it depends. Some systems I know of would consider this too high a risk as you've described it. Others would completely agree that any authenticated system should automatically be white-listed. Unfortunately for the latter group this often costs them a lot in clean-up consulting fees when customers get infected. (we see that a lot lately). Since this is a policy based decision, you could take advantage of the GBUdb drilldown feature and teach your SNF to "trust" the IPs that this customer might use. What would happen then is that SNF would not be able to identify the source IP and so only the pattern matching engine would apply. http://www.armresearch.com/Documentation/QA/ltdrilldowngt--468945561.jsp Effectively you'd be telling SNF not to worry about the IP address for this customer (or for that matter any of the IPs used for dialup by the customer's provider)... only pay attention to pattern matches. That's still making a hole,... but it's your hole and you know why you made it. It's also a pretty small one because if some known spam or malware comes from there it will still get tagged -- maybe not as efficiently -- but it will still get tagged. Hope this helps, _M -- Pete McNeil Chief Scientist ARM Research Labs, LLC www.armresearch.com 866-770-1044 x7010 twitter/codedweller # This message is sent to you because you are subscribed to the mailing list . This list is for discussing Message Sniffer, Anti-spam, Anti-Malware, and related email topics. For More information see http://www.armresearch.com To unsubscribe, E-mail to: To switch to the DIGEST mode, E-mail to To switch to the INDEX mode, E-mail to Send administrative queries to
