Re: DNS Terminology

[listsb-spamassassin]

> On Sep 23, 2016, at 17.34, Lindsay Haisley  wrote:
> 
> On Fri, 2016-09-23 at 17:10 -0400, btb wrote:
>> On 2016.09.23 16.16, Lindsay Haisley wrote:
>>> 
>>> On Fri, 2016-09-23 at 18:43 +0100, RW wrote:
 
 Right, but the question here is why isn't a forwarding server also a
 recursive server? Why is the use of iteration the defining feature of
 a recursive server and not the support for recursion.
>>> http://serverfault.com/questions/661821/what-s-the-difference-between-recursion-and-forwarding-in-bind
>> this is bad information.  it's unfortunate it has a green check mark 
>> next to it.  at least it only has a 6 though.
> 
> What do you think is bad about it? I've been working with DNS for 20
> years and this is about as straightforward an explanation of the
> difference as I can think of, and jibes with my understanding. Am I
> misinformed?

it suffers from the same deficiencies highlighted in my earlier message.  
namely, conflating the services provided with the work done in order to provide 
those services.

> 
> says pretty much the same thing. Is this also bad information?

yes.  

> Or how about
> ?
> 
> What this article defines as a "caching" name server is rather the same
> as a recursive server, but the definition of a forwarding server is the
> same - basically a proxy server.

this page is perhaps a bit better, but still suffers from terminology 
conflation.

consider that, to do the work described as "forwarding" in many of these 
references, the nameserver must perform a recursive query [e.g. it must perform 
a query with the rd bit set].

on the digital ocean page, it's stated "This configuration will force the 
server to recursively seek answers from other DNS servers when a client issues 
a query".  this is incorrect.  the configuration described will result in 
[there's no forcing here :) ] the server performing *iterative* queries.  that 
is, working through the dns hierarchy, following delegations [often called 
"referrals"] as necessary, in order to find the answer.  these queries do not 
have the rd bit set, and as such, are not recursive queries.

the techexams page suffers from this same misconception.  recursion occurs if 
the client sends a "recursion desired" query [rd bit set], and the server 
answers with a "recursion allowed" response [ra bit set].  at that point, 
recursion has now occurred, regardless of what the server might have done 
behind the scenes [it might be a client too!]  what the poster on that page 
described as recursion occurring, is, in fact, iteration occurring.

a reference to the bind config exemplified on the digital ocean page might help 
as well.  the "recursion" setting controls whether or not recursion is allowed 
[e.g. whether or not recursive service is offered/provided to clients querying 
the server].  it does not control whether or not the nameserver performs 
recursion in order to provide the answer.  further emphasis of this can be 
found in the accompanying "allow-recursion" and "allow-recursion-on" settings, 
which further fine tune this behavior.

in any case, hopefully this discussion has run its course here.  it's an 
interesting topic, and one worth exploring for the sake of those in search of 
accuracy, but would be a better fit for a mailing list like oarc's 
dns-operations or such.

Re: Customized header (add_header) doesn't work

[listsb-spamassassin]

> On Dec 19, 2015, at 04.35, Reindl Harald  wrote:
> 
> 
> 
> Am 19.12.2015 um 04:08 schrieb listsb-spamassas...@bitrate.net:
>> On Dec 17, 2015, at 13.16, Alfredo Saldanha  
>> wrote:
>>> 
>>> My second SA is a Zimbra server.
>>> I use Zimbra SA only to drop the message in junk folder.
>>> I don't want to clean at the Zimbra server, it is default behavior.
>> 
>> for what it's worth, if you were to use amavis rather than a milter, you 
>> could just deliver mail directly from amavis to the zimbra mailbox server 
>> [bypassing the zimbra mta which you don't need in term of this] via lmtp 
>> [typically port 7025]
> 
> how idoes a transport "lmtp:[host]:7025" depend on "use amavis rather than a 
> milter"

you're making assumptions.  no one said it did.  zimbra's mailbox server 
depends upon use of amavis for "it just works" integration.

> milter rejects high scored spam and the rest takes the configured transport 
> which exists anyways and points now to the zimbra mta

correct, that is how a milter works, be it irrelevant to the point.

Re: Customized header (add_header) doesn't work

[listsb-spamassassin]

On Dec 17, 2015, at 13.16, Alfredo Saldanha  wrote:
> 
> My second SA is a Zimbra server.
> I use Zimbra SA only to drop the message in junk folder.
> I don't want to clean at the Zimbra server, it is default behavior.

for what it's worth, if you were to use amavis rather than a milter, you could 
just deliver mail directly from amavis to the zimbra mailbox server [bypassing 
the zimbra mta which you don't need in term of this] via lmtp [typically port 
7025], and it would just work.  none of the attempting to trick one instance of 
spamassassin with another instance of spamassasin.  additionally, depending on 
how you're using your existing postfix server, you likely don't even need the 
zimbra mta at all.

-ben

Re: sa-compile seems to not clean up after itself

[listsb-spamassassin]

 On Feb 12, 2015, at 14.09, Kevin A. McGrail kmcgr...@pccc.com wrote:
 
 On 2/11/2015 7:25 PM, listsb-spamassas...@bitrate.net wrote:
 i hope another solicitation for this help request is ok.
 
 It's ok.
 
 Overall, I agree.  I tested on a devel box and running sa-compile does have 
 an rm line but did leave these files listed below.
 
 Because /tmp is a considered auto cleaning, I consider it a very low priority 
 but either re2c or the process in sa-compile is leaving files behind and you 
 should open a ticket with bugzilla, please.

yes, certainly - we just do housekeeping in the cron job which runs sa-compile 
for now, and that's just fine.

https://issues.apache.org/SpamAssassin/show_bug.cgi?id=7138

-ben

Re: sa-compile seems to not clean up after itself

[listsb-spamassassin]

i hope another solicitation for this help request is ok.

 On Feb 04, 2015, at 09.19, btb listsb-spamassas...@bitrate.net wrote:
 
 hi-
 
 i happened to notice a bunch of old files in /tmp/, related to spamassassin.  
 after a bit of testing, it looks like sa-compile isn't cleaning up after 
 itself?
 
 ls -alH /tmp/
 total 44
 drwxrwxrwt  2 root root 36864 Feb  3 17:18 .
 drwxr-xr-x 22 root root  4096 Dec 25 00:34 ..
 
 sa-compile --quiet
 
 l /tmp
 total 60K
 -rw--- 1 root root  131 Feb  4 09:09 .spamassassin315050WnT59tmp
 -rw--- 1 root root 2.7K Feb  4 09:10 .spamassassin31505283bEDtmp
 -rw--- 1 root root 1.3K Feb  4 09:09 .spamassassin31505arXK9ytmp
 -rw--- 1 root root  528 Feb  4 09:09 .spamassassin31505aZnGbDtmp
 -rw--- 1 root root 1.4K Feb  4 09:09 .spamassassin31505CzdUbftmp
 -rw--- 1 root root  839 Feb  4 09:09 .spamassassin31505DPLUxbtmp
 -rw--- 1 root root 3.1K Feb  4 09:10 .spamassassin31505dSWwz5tmp
 -rw--- 1 root root  341 Feb  4 09:10 .spamassassin31505foYv8Ptmp
 -rw--- 1 root root   97 Feb  4 09:09 .spamassassin31505iM2hTCtmp
 -rw--- 1 root root  715 Feb  4 09:09 .spamassassin31505jYeOoltmp
 -rw--- 1 root root 2.6K Feb  4 09:09 .spamassassin31505mpa4T2tmp
 -rw--- 1 root root   45 Feb  4 09:09 .spamassassin31505RfvOddtmp
 -rw--- 1 root root 2.8K Feb  4 09:10 .spamassassin31505TZTv3Ntmp
 -rw--- 1 root root  124 Feb  4 09:09 .spamassassin31505uJAibhtmp
 -rw--- 1 root root 2.8K Feb  4 09:10 .spamassassin31505vf0B0Wtmp
 
 is this expected behavior?  if i'm correctly interpreting the man page [e.g. 
 --keep-tmps], they should be deleted?
 
 -ben

Re: dealing with mail not yet listed in network tests

[listsb-spamassassin]

 On Nov 14, 2014, at 11.41, Reindl Harald h.rei...@thelounge.net wrote:
 
 Am 14.11.2014 um 17:11 schrieb listsb-spamassas...@bitrate.net:
 one characteristic that appears to be pretty consistent is the age of the 
 domain name that a given message references [from header, envelope sender, 
 ptr record for remote mailservers referenced in received headers, etc].  
 quite often, the domain names are very recently registered.  in many 
 instances, the very same day the messages are received.  is there a 
 rule/ruleset out there that adds points to a score based on domain name age? 
  the newer the domain, the higher the score is pushed up?
 
 that's URIBL_RHS_DOB
 http://wiki.apache.org/spamassassin/Rules/URIBL_RHS_DOB
 
 sadly it turned out to be not that relieable for a very high score

revisiting this - am i doing this right?

dig yournewgrabbagspecials.rocks.dob.sibl.support-intelligence.net a

;  DiG 9.9.5-3-Ubuntu  
yournewgrabbagspecials.rocks.dob.sibl.support-intelligence.net a
;; global options: +cmd
;; Got answer:
;; -HEADER- opcode: QUERY, status: NXDOMAIN, id: 21192
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;yournewgrabbagspecials.rocks.dob.sibl.support-intelligence.net.IN A

;; AUTHORITY SECTION:
dob.sibl.support-intelligence.net. 3159 IN SOA  a.support-intelligence.net. 
zone.support-intelligence.com. 20141220 3600 14400 604800 3600

;; Query time: 0 msec
;; SERVER: 192.168.1.60#53(192.168.1.60)
;; WHEN: Sat Dec 20 18:11:06 EST 2014
;; MSG SIZE  rcvd: 158

spam from creative gtlds

[listsb-spamassassin]

this was discussed a while back, in the context of tlds with names of colors 
[red, blue, pink, etc].  recently, i'm getting spam from the rocks tld [i can 
share further detail if it's of interest].  what ultimately happened with the 
color tlds, in terms of spamassassin?  was there a ruleset modified/added?  did 
someone have a test ruleset?  the archives i've been reading seem to be not 
quite clear on an outcome/consensus.  i think the thread ended up shifting 
gears and became a discussion about separation of code and rules.

additionally, any thoughts on this latest spamming tld and a proper method for 
scoring?

-ben

Re: possible false positive with FORGED_YAHOO_RCVD?

[listsb-spamassassin]

 On Nov 30, 2014, at 15.42, Benny Pedersen m...@junc.eu wrote:
 
 On 30. nov. 2014 21.12.06 listsb-spamassas...@bitrate.net wrote:
 
 http://dpaste.com/3XTYV0V.txt
 
 Is trusted_networks and internal_networks correct both for ipv4 and ipv6 ?
 
 Does it match settings in amavisd ?
 
 Both sa and amavisd need to know ALL your own ips including all non routeble 
 :)

after getting sidetracked briefly, i'm back to this.  what settings in amavis 
need to match 
trusted_networks/internal_networks? [hopefully not too off topic a question]

-ben

Re: different results when using --debug

[listsb-spamassassin]

 On Dec 08, 2014, at 19.28, Mark Martinec mark.martinec...@ijs.si wrote:
 
 Actually, looking at a diff of DBM.pm between 3.4.0 and 3.4.1
 I can see the taint bug has already been fixed by r1608413:
 
 @@ -814,3 +816,3 @@
   my @vars = $self-get_storage_variables();
 -  dbg(bayes: DB journal sync: last sync: .$vars[7],'bayes','-1');
 +  dbg(bayes: DB journal sync: last sync: %s, $vars[7]);
 
 The extra parameters shouldn't have been in that dbg call.
 
 See:
  Bug 7065 - Debug Mode breaks Bayes but only if DBM storage is used
  https://issues.apache.org/SpamAssassin/show_bug.cgi?id=7065

i've manually grafted that patch onto my 3.4.0, and it seems to do the trick, 
thanks. i now see bayes results [and more consistent results overall] when 
using --debug.

there is still a slight variation in scoring, however:

without --debug:
Content analysis details:   (19.6 points, 5.0 required)
[...]
-3.8 AWLAWL: adjust score towards average for this sender

with --debug:
Content analysis details:   (19.5 points, 5.0 required)
[...]
-3.7 AWLAWL: adjust score towards average for this sender

all other scoring is consistent.  it's a trivial variation in this instance, 
but does it mean something additional may not be working as intended?  or just 
something else i need to learn?

-ben

message sent to list yesterday

[listsb-spamassassin]

hi-

i sent a message to the list yesterday, but have not yet seen it appear.  can 
someone check?  my logs indicate successful delivery to mx1.us.apache.org:

Dec  3 17:48:24 mta postfix/smtp[10226]: 3jtFgN6Dfmz9s2b: 
to=users@spamassassin.apache.org, relay=mx1.us.apache.org[140.211.11.136]:25, 
delay=56, delays=0.45/0.02/30/25, dsn=2.0.0, status=sent (250 Queued! 
547f92fe.40...@bitrate.net (Queue-Id: 70BD3358))

thanks
-ben

Re: message sent to list yesterday

[listsb-spamassassin]

 On Dec 04, 2014, at 12.18, Joe Quinn jqu...@pccc.com wrote:
 
 On 12/4/2014 11:17 AM, listsb-spamassas...@bitrate.net wrote:
 hi-
 
 i sent a message to the list yesterday, but have not yet seen it appear.  
 can someone check?  my logs indicate successful delivery to 
 mx1.us.apache.org:
 
 Dec  3 17:48:24 mta postfix/smtp[10226]: 3jtFgN6Dfmz9s2b: 
 to=users@spamassassin.apache.org, 
 relay=mx1.us.apache.org[140.211.11.136]:25, delay=56, 
 delays=0.45/0.02/30/25, dsn=2.0.0, status=sent (250 Queued! 
 547f92fe.40...@bitrate.net (Queue-Id: 70BD3358))
 
 thanks
 -ben
 I see a message from you at 5:47 PM yesterday (UTC-05:00) which includes the 
 output of some commands like sa-learn --dump magic.
 http://spamassassin.1065346.n5.nabble.com/different-results-when-using-debug-td113494.html
 
 Is that the email you were looking for?

thanks, that's it.  sorry, i should have thought to check other places beyond 
my mail client.  i guess i just didn't get the return copy of that particular 
message.

-ben

different results when using --debug

[listsb-spamassassin]

i was testing with a sample message, and noticed that when running manually 
with --debug, there seem to be numerous differences in the results, such as 
scores for the same tests differing, visual ordering of results differing [is 
this significant?], and bayes not being listed when using --debug.  am i doing 
something wrong?  are my expectations misguided?  i'm doing these tests as the 
user named amavis, which the amavis software runs as.

spamassassin --test-mode --debug  message3.txt 
Dec  2 23:32:41.224 [27222] dbg: logger: adding facilities: all
Dec  2 23:32:41.224 [27222] dbg: logger: logging level is DBG
Dec  2 23:32:41.224 [27222] dbg: generic: SpamAssassin version 3.4.0
Dec  2 23:32:41.224 [27222] dbg: generic: Perl 5.020001, PREFIX=/usr, 
DEF_RULES_DIR=/usr/share/spamassassin, LOCAL_RULES_DIR=/etc/spamassassin, 
LOCAL_STATE_DIR=/var/lib/spamassassin
Dec  2 23:32:41.224 [27222] dbg: config: timing enabled
Dec  2 23:32:41.225 [27222] dbg: config: score set 0 chosen.
Dec  2 23:32:41.226 [27222] dbg: util: running in taint mode? yes
[...]
Content analysis details:   (10.7 points, 5.0 required)

 pts rule name  description
 -- --
 1.7 URIBL_BLACKContains an URL listed in the URIBL blacklist
[URIs: ialloansystems.com]
 1.7 URIBL_WS_SURBL Contains an URL listed in the WS SURBL blocklist
[URIs: ialloansystems.com]
 1.6 RCVD_IN_BRBL_LASTEXT   RBL: No description available.
[94.73.46.5 listed in bb.barracudacentral.org]
-0.0 SPF_PASS   SPF: sender matches SPF record
-0.0 T_RP_MATCHES_RCVD  Envelope sender domain matches handover relay
domain
-0.0 SPF_HELO_PASS  SPF: HELO matches SPF record
 0.4 RAZOR2_CF_RANGE_51_100 Razor2 gives confidence level above 50%
[cf: 100]
 2.0 PYZOR_CHECKListed in Pyzor (http://pyzor.sf.net/)
 2.4 RAZOR2_CF_RANGE_E8_51_100 Razor2 gives engine 8 confidence level
above 50%
[cf: 100]
 1.7 RAZOR2_CHECK   Listed in Razor2 (http://razor.sf.net/)
 0.0 DIGEST_MULTIPLEMessage hits more than one network digest check
-0.8 AWLAWL: From: address is in the auto white-list

Dec  2 23:32:44.364 [27222] dbg: check: tagrun - tag DKIMDOMAIN is still 
blocking action 0
Dec  2 23:32:44.366 [27222] dbg: plugin: 
Mail::SpamAssassin::Plugin::MIMEHeader=HASH(0x2cb2be0) implements 
'finish_tests', priority 0
Dec  2 23:32:44.366 [27222] dbg: plugin: 
Mail::SpamAssassin::Plugin::Check=HASH(0x2cb2e80) implements 'finish_tests', 
priority 0
Dec  2 23:32:44.388 [27222] dbg: netset: cache trusted_networks hits/attempts: 
10/11, 90.9 %
Dec  2 23:32:44.397 [27222] dbg: bayes: untie-ing

spamassassin --test-mode  message3.txt 
Received: from localhost by mfa.example.com
with SpamAssassin (version 3.4.0);
Tue, 02 Dec 2014 23:34:52 -0500
[...]
Content analysis details:   (8.9 points, 5.0 required)

 pts rule name  description
 -- --
 1.4 RCVD_IN_BRBL_LASTEXT   RBL: No description available.
[94.73.46.5 listed in bb.barracudacentral.org]
 1.7 URIBL_BLACKContains an URL listed in the URIBL blacklist
[URIs: ialloansystems.com]
 1.6 URIBL_WS_SURBL Contains an URL listed in the WS SURBL blocklist
[URIs: ialloansystems.com]
-0.0 SPF_PASS   SPF: sender matches SPF record
-0.0 SPF_HELO_PASS  SPF: HELO matches SPF record
-0.0 T_RP_MATCHES_RCVD  Envelope sender domain matches handover relay
domain
-1.9 BAYES_00   BODY: Bayes spam probability is 0 to 1%
[score: 0.]
 0.5 RAZOR2_CF_RANGE_51_100 Razor2 gives confidence level above 50%
[cf: 100]
 1.4 PYZOR_CHECKListed in Pyzor (http://pyzor.sf.net/)
 1.9 RAZOR2_CF_RANGE_E8_51_100 Razor2 gives engine 8 confidence level
above 50%
[cf: 100]
 0.9 RAZOR2_CHECK   Listed in Razor2 (http://razor.sf.net/)
 0.3 DIGEST_MULTIPLEMessage hits more than one network digest check
 1.1 AWLAWL: From: address is in the auto white-list

possible false positive with FORGED_YAHOO_RCVD?

[listsb-spamassassin]

hi-

a message from yahoo seems to have matched FORGED_YAHOO_RCVD, which from my 
perspective, the message is not forged [see below pastebin - i hope i've not 
removed anything of importance during anonymization].  i noted that dkim 
authentication appears to have failed, which, while of interest for other 
reasons, doesn't seem to be the culprit here [in my cursory look at 
check_for_forged_yahoo_received_headers, i didn't see any references to dkim]?  
was this a false positive, or am i ignorant?

http://dpaste.com/3XTYV0V.txt

-ben

Re: dealing with mail not yet listed in network tests

[listsb-spamassassin]

 On Nov 14, 2014, at 00.35, John Hardin jhar...@impsec.org wrote:
 
 On Thu, 13 Nov 2014, listsb-spamassas...@bitrate.net wrote:
 
 all of the emotional postulative opining aside, one possibility i have been 
 considering is having postfix delay relay of messages to the content filter 
 for a few minutes, as it seems that when these messages reach us, they're 
 only minutes away from being matched by network tests [this is what i asked 
 postfix-users about].  i'm interested to hear from folks on this list 
 regarding this idea, as well as possible alternatives to dealing with this 
 phenomenon.
 
 It's called greylisting and many people (including myself) have good results 
 with it.

yeah, i'm very familiar with greylisting.  it's something i've used in the 
past, and for a time, it worked reasonably well.  for me, that time has passed. 
 i've dealt with all topics that come up when greylisting is discussed; user 
expectations, political interests, scalability, reliability of remote systems, 
purist arguments, etc, etc.  the the problems it causes outweigh its benefits 
at this point, from my experience, and so i no longer use it.

in any case, delaying the relay of messages is different than delaying the 
acceptance of messages, the latter has numerous advantages in managing the 
activity, as it's done within a controlled environment.

that said, i do use postscreen, and i do use after 220 tests, and this does 
help some.  ultimately though, mail gets through.

one characteristic that appears to be pretty consistent is the age of the 
domain name that a given message references [from header, envelope sender, ptr 
record for remote mailservers referenced in received headers, etc].  quite 
often, the domain names are very recently registered.  in many instances, the 
very same day the messages are received.  is there a rule/ruleset out there 
that adds points to a score based on domain name age?  the newer the domain, 
the higher the score is pushed up?

-ben

dealing with mail not yet listed in network tests

[listsb-spamassassin]

hi-

i've recently asked about essentially this same topic on the postfix-users 
mailing list, so apologies to those subjected to the repetition.

the topic came up for me a couple of weeks ago when i asked about duplicate 
spam that was scoring low the first time it was received:

https://mail-archives.apache.org/mod_mbox/spamassassin-users/201411.mbox/%3C5458FFE3.10404%40bitrate.net%3E

understanding now what's going on, i've been thinking a bit about this, while 
the frequency of this trend seems to be continuing to increase.  as a possibly 
meaningless anecdote, it's almost as though something changed overnight, and 
suddenly, our spam volume has increased dramatically.  much of it is still 
detected by spamassassin, but it's sort of surprising to me how much seems to 
now be making it through postscreen and other postfix restrictions [e.g. very 
low or absent listings in dnsbls] and through to amavis/spamassassin.  if i 
didn't know better, i might wonder if suddenly the dnsbls we're using had begun 
lagging behind.

all of the emotional postulative opining aside, one possibility i have been 
considering is having postfix delay relay of messages to the content filter for 
a few minutes, as it seems that when these messages reach us, they're only 
minutes away from being matched by network tests [this is what i asked 
postfix-users about].  i'm interested to hear from folks on this list regarding 
this idea, as well as possible alternatives to dealing with this phenomenon.  i 
believe amavis/spamassassin are operating properly, and the messages are scored 
quite accurately once network tests include matches - it's just this brief 
interlude which has begun to become somewhat frustrating.

not wanting to assume which configuration elements might be relevant here, i 
haven't included anything, but if there are doubts as to the competence of my 
configuration, i'd happily provide anything which might reveal deficiencies.

thanks
-ben

Re: Valid TLDs (was: Re: Custom rule not hitting suddenly?)

[listsb-spamassassin]

On Sep 8, 2014, at 21.45, Karsten Bräckelmann guent...@rudersport.de wrote:

 Some discussion of the underlying issue.
 
 On Tue, 2014-09-09 at 02:59 +0200, Karsten Bräckelmann wrote:
 At the time of the 3.3.2 release, the .club TLD simply didn't exist. It
 has been accepted by IANA just recently. Of course I was conveniently
 using a trunk checkout for testing and kind of shrugged off that TLD in
 question.
 
 FWIW, this is not actually a 3.3.x issue. It's the same with 3.4.0. Yes,
 that is a *recent* TLD addition... *sigh*
 
 Unlike the util_rb_[23]tld options, the set of valid TLDs is actually
 hard-coded. It would not be a problem to make that an option, too.
 Which, on the plus side, would make it possible to propagate new TLDs
 via sa-update. Not only 3.3.x would benefit from that, but also 3.4.0
 instances. Plus, it would be generally faster anyway.
 
 There is one down side: A new dependency on Regexp::List [1]. The RE
 pre-compile one-time upstart penalty should be negligible.
 
 The question is: Is it worth it?  WILL it be worth it?

pardon my possible technical ignorance here - could this potentially be a 
network test, rather than a list propagated by sa-update?  e.g. query dns for 
existence of delegation?

-ben

Re: sanitizing/normalizing messages for feeding sa-learn

[listsb-spamassassin]

On Aug 27, 2014, at 18.13, Quanah Gibson-Mount qua...@zimbra.com wrote:

 --On Wednesday, August 27, 2014 6:06 PM -0400 btb 
 listsb-spamassas...@bitrate.net wrote:
 
 hi-
 
 we have a system [zimbra] where users can select a message in the mua
 interface and click a spam or not spam button.  this generates a message
 [containing the selected message] which is ultimately delivered to a
 mailbox.  i intend on retrieving these messages via imap and feeding
 sa-learn, but they've been a bit adulterated by the time they're
 retrieved, and i believe some cleanup is probably necessary prior to
 feeding sa-learn.
 
 That seems rather convoluted, given that Zimbra already trains its SA 
 database automatically on a nightly basis based on the messages user submit 
 via marking things as Spam.  Are you running your own SA outside of Zimbra?

yes, our mx/mta/msa/content filtering infrastructure is completely separate 
from zimbra.

-ben