> On 2/10/2012 9:20 PM, email builder wrote: >> Wonder if I can delete the older one > Sure. Worst case just run sa-update again if you delete the wrong one.
OK, thank you. I'll report back if it causes any problems but I can't imagine it would. >> Hm, well is there a file or somewhere to look and see what rules are >> active? > Do you mean something like: With my configuration, what rules might possibly > be > triggered? yes > That's an interesting question. Perhaps we could use a spamassassin > parameter to run, parse config and dump all possible rules that would run > (with > scores) based on all plugins, etc. that are believed to be configured. If > that > is what you want, please open a bug at > https://issues.apache.org/SpamAssassin/ > assuming no one knows a way this can occur now. OK it's a feature request then huh? I added it: https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6757 >>> I believe for SPF you *should* be doing the detecting at your MTA >>> (mail server software) and inserting a header for spamassassin to use: >>> Received-SPF. (Because SPF is supposed to use the "envelope >>> from", >>> which is not necessarily included in a header.) >> I see. That makes sense. Is there a wiki page suggesting solutions for >> this? Anyone know of tips for doing this in postfix? Or during amavis >> processing? > Interesting thought though while the envelope sender is not in a header per > se, > it is in the From line for mbox format email, I believe. If you are using > procmail for delivery, for example, there shouldn't be an issue. Actually, you're right - it seems as long as the envelope info is available you would not need to add a new header, no? That depends if the SA SPF rules know how to check the envelope or if they only look for a "Received-SPF" header. Anyone know the details in that regard? I use maildrop for delivery out of postfix (and SA runs from maildrop). Postfix passes what I think is the envelope sender to maildrop by "-f ${sender}" (I'll double check but I think that's accurate). I'm uncertain if the envelope info gets to SA, though, as my maildrop call to SA is: xfilter "/usr/bin/spamc -u $LOGNAME" I'd rather not add a header if not necessary. Second choice is to do it using amavis, as adding a policy server just for this to be pretty extreme. >> Me too. I sent emails to myself from Yahoo and Gmail and got these in my > X-Spam-Status: >> >> Gmail: DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU >> Yahoo: DKIM_ADSP_CUSTOM_MED,DKIM_SIGNED,T_DKIM_INVALID >> >> (that last one is interesting - not sure how the message gets altered to > break the signature, especially if Gmail works fine (running SA from > Maildrop)) > Chasing down DKIM errors can be interesting to say the least. I found a bug > in > Sendmail, for example, where it canonicalized the email address in the To: > Header which was case-sensitive on the signing so DKIM validation failed. > > Have you looked at the received headers to confirm it is in fact a valid > Yahoo! > email? >> >>> I believe SPF tests are also enabled by default, but won't do quite > the >>> right thing unless you're inserting the Received-SPF header at your > MTA. >> Well I guess so because I see no SPF hits and I think at least Gmail uses > SPF. I'd appreciate any tips on getting those headers inserted. > Gmail does publish SPF. > > Check your *.pre files and see if you have loadplugin > Mail::SpamAssassin::Plugin::SPF > > Also make sure you have Mail::SPF. This command can help determine that: > > perl -e 'if (require Mail::SPF) { print "Mail::SPF Version is: > $Mail::SPF::VERSION\n"; exit 0;} else {exit 1;}' || echo > 'Mail::SPF Not Present!' > Mail::SPF Version is: v2.005 > > > Regards, > KAM >
