Re: False positive with scoring I don't understand On Mon, 2008-02-18 at 13:12 -0800, Tim Alberts wrote: > Thank you again everyone for responding. >  > I do have the per user settings and it prompts the question that I don't  > see an answer for yet.  What happens with the command  > 'spamassassin --remove-addr-from-whitelist' with per user settings?  I  > assumed running the command as root, it would filter down through each  > user AWL.  Thinking more about it I guess it stands to reason that it  > doesn't because spamassassin doesn't know about all the users. >  > So is the solution to log in as each user and issue the command to clear  > the marked address from each account?  How should it be handled in this  > situation. Yes. With per user conf and AWL DB, each user (affected) must fix their own AWL. Just like you removed the corrupt AWL DBs for exactly these users, you could have just removed the email address in question from them. > Note:  For now, I have deleted the autowhitelist file from the selected  > users that are communicating with the marked email address.   > Unfortunately again, I won't know if it worked until the customer emails  > again. Fortunately, this is not true. :) As one of the affected users, just run any mail from that email address through SA again:   spamassassin < saved-raw-mail  | less Check the resulting X-Spam headers. Instead of 'spamassassin', you can use 'spamc' too, if you generally do that anyway. Just be sure to do that as the affected users, with their correct environment [1]. If you again re-run such mail through spamassassin, you will see a sane AWL score, unless the overall score is identical to the previous one.   guenther [1] 'su' vs 'su -' caveat if you su from root --  char *t="\\10pse\\0r\\0dtu\\0.@ghno\\x4e\\xc8\\x79\\xf4\\xab\\x51\\x8a\\x10\\xf4\\xf4\\xc4"; main(){ char h,m=h=*t++,*x=t+2*h,c,i,l=*x,s=0; for (i=0;i>=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}} >From udcat@mail-abuse.org  Sat Apr 26 15:48:51 2008 Message: 4 Date: Fri, 15 Feb 2008 11:27:29 -0800 From: Douglas Otis  Subject: Re: [ietf-dkim] NEW ISSUE: SSP-02: Policy Scope To: Charles Lindsey  Cc: DKIM  Message-ID: <3CF7C83F-CD48-4840-9D71-C3EED72E4C4F@mail-abuse.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes On Feb 15, 2008, at 4:50 AM, Charles Lindsey wrote: > On Thu, 14 Feb 2008 19:08:41 -0000, Douglas Otis  abuse.org> wrote: > >> On Feb 14, 2008, at 3:26 AM, Charles Lindsey wrote: >>> If you want to indicate that information, then propose a new tag   >>> within the SSP record for the purpose. But the default should be   >>> that the SSP applies to all modes of transport. Otherwise the Bad   >>> Guys will just send mail like the following: >>> >>> Received: by bar.com from foo.com by SMTP ... >>> Received: by foo.com from ebay.com by UUCP ... >>> From: zevuvqao@ebay.com >>> [NO DKIM signature] >> >> Agreed.  This issue does not appear to have been entered into the   >> RT tracking, but both you and Jim have suggested this alternative   >> solution.  Here is a more formalized suggestion for a tag added to   >> the policy record. >> >> s= Policy Scope (plain-text; OPTIONAL; default is "SMTP").  A colon- >> > No! The default must be '*'. The concern regarding defaults was addressed in Take #3.  This version   includes a means to exclude policy.     *  matches against all unlisted transport protocols     !  disavows protocol use     -  excludes protocol from policy assertions I suspect the default should be "s=SMTP" where this would be the same   as "s=SMTP:-*".  When the domain exchanges no communication   whatsoever, "s=!*" could be used.  When only SMTP messages are used,   then "s=SMTP:!*" would make this assertion. > But you have to make it clear that verifiers can only discern the   > protocol used by the originating site by carefull examination of   > Received headers (and believable ones at that). So I am still very   > dubious about adding this feature. Trace headers can not be included within DKIM signatures.  This   limitation means DKIM policy applied against messages arriving over   SMTP may affect messages passing though third-party protocol gateways   bridging other protocols into SMTP.   When messages arrive over   different protocols within the same administrative domain,   Authentication-Results headers could be used to indicate which   protocol transmitted the message into the administrative domain, where   these messages are placed into a common mailbox.  It would be wrong to   assume this is always the case. See: http://www3.tools.ietf.org/html/draft-kucherawy-sender-auth-header-11 The significant value in the Authentication-Results header is that it   can be filtered at border MTAs.  By adding a ptype of   "Transport=" to this header, a gateway can thereby indicate   which transport protocol introduced the message.  Unless this   information is conveyed to the recipient by some mechanism when the   mailbox normally serves as a repository SMTP messages, it would be   better to apply policy that pertains to SMTP.  This may mean a DKIM   policy of "all" may cause some third-party gateway related messages to   be refused or placed within a different folder as a result. A policy scope mechanism allows other transports to apply policy in   accordance with the domains assertion of protocol support, and whether   the DKIM specific assertion should be applied.  As such, an a DKIM/  SMTP policy of "all" would not affect messages sent over NNTP with a   policy scope of "s=SMTP" for example.  As other forms of message   exchange implement DKIM, the scope of DKIM specific policies   assertions becomes more critical.  When the NTTP message is translated   into message carried by SMTP, then SMTP policy may negatively affect   the categorization of the NNTP message when these are not being signed. This WG is largely comprised of those primarily focused upon SMTP.  As   such, DKIM policy is being considered only from the aspect of SMTP.    While DKIM could be implemented by other types x822 message exchange,   few would expect all of these communications to simultaneously   implement DKIM.  There are a few choices to resolve this potential   issue. a) Stipulate the *SP policy record applies to messages arriving over   SMTP (require different policy domain labels for each protocol). b) Provide a scope parameter within the policy record.  From a maintenance and overhead standpoint, option "b" could be the   best solution.  In Take #3, to make this friendly to gateways change: When a protocol has been disavowed, any further DKIM related   transactions should cease. with: When all protocols has been disavowed, any further DKIM related   transactions should cease. This last statement provides a means to protect specific domains and   their parent domain from an inordinate amount of DNS traffic when an   existing domain is spoofed in a spam campaign.  The policy scope   parameter allows other types of message spoofing to be mitigated with   as DKIM becomes implemented for each respective transport.  The fact   that a protocol can be bridged into SMTP should not inhibit the use of   "all" for SMTP, or for other protocols to assume that "all" only   applies to SMTP.  For DKIM to offer it greatest protections, a means   to scope the policy is essential.  Pick "a" or "b". -Doug ------------------------------ _______________________________________________ NOTE WELL: This list operates according to  End of ietf-dkim Digest, Vol 107, Issue 10 ******************************************