https://issues.apache.org/SpamAssassin/show_bug.cgi?id=5684
Andrew Kinnard <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] --- Comment #18 from Andrew Kinnard <[email protected]> 2010-11-16 14:23:36 UTC --- (In reply to comment #17) Brother, it seems you have a disaffinity for processing SPF records with SA (more than a functional [vs philosophical] objection to the patch's intent). I think that is different from having a relevant objection to the patch. Does is break anything or change existing functionality?...No. Does it force you to process SPF records with SA?...No. Does it harshly penalize domains who unintentionally set up SPF with a "+all"?...No, not unless you score the rule with reckless abandon. Does it address spam indirectly (through a mild perversion of other technology)?...Yes. So do lots of standard SA rules. Can it be bypassed (with a clever transmutation of "+all")?...Yes. Does that really matter?...No, because during the time we were seeing this spam, I never had ANY at ANY site that came through with a "+all" written as a CIDR in the SPF record. It's simple, effective, and addressed the problem at the time. So, the patch did what it was supposed to. You can object based on that, but you'd have to also take up arms over rules that look at rDNS and FCrDNS as well as a host of rules that don't examine anti-spam-specific technologies or filter based on email content. > Having "+all" can also be a sign of 1) A lazy admin., or 2) one who really > doesn't care*. Regardless, SPF is not a spam solution but a forgery solution. SA authors would disagree with you about the relevance of SPF to "spamminess" (or the SPF rules would not be in SA). > Granted, much spam is also forged, but so can non-spam be forged. Deferring > action to the data phase where SA gets the message is too late in the SMTP > transaction. ...according to your sensibilities. If I want to do a minor manipulation of SA scores based on a used-in-the-wild misconfiguration that was aimed at getting more spam delivered, it's going to have to be after mail is spooled. Otherwise the decision has to be binary. This is much the same quandry one faces when implementing RBLs: Do you let your mta handle it (in a binary fashion) at the connect phase, or do you let SA apply a more moderated RBL effect on judging a spooled email's spamminess? > * - Especially if another anti-forgery method (DK/DKIM or PGP signatures) is > always deployed in messages from that source, there should be no such > conclusion, implied or not, that the source may be "spammy" in nature just > because it has "+all" in its SPF record. True that it would be self-defeating for a spammer to identify him- or her-self by PGP or DKIM signing spam. However, I'm willing to bet that there are VERY few domains implementing PGP and/or DKIM that have a misconfigured SPF record; the expertise required to implement either of the two anti-forgery schemes far outweighs that required to generate a decent SPF record. In any case, the default score on this rule is very small, and should not push legitimate email into a false positive score. > However, I personally would deny such > a result (pass -> "+all") anyway at SMTP "MAIL FROM", thus such would never > reach SA to be evaluated. ...which is a binary method of responding to "+all" SPF records; you are denying email delivery based on the outcome of this one test -- it's all or nothing. You see it as superior, and I do not. My patch just provides another option, one you would not be forced to use even if the code were merged. > As far as statistics go as to how many sites have SPF records with "+all", > that > need not be done with a mail server. In fact, some work has already been done > - see http://spf-all.com/stats.html for details. The survey at that web site > identifies roughly a 10% infiltration of SPF across all domains sampled, and > within that 10%, 1/100 have "+all" terminated records (26k of 2.6M out of > 25.6M > domains sampled). A larger number of domains have SPF record errors than > "+all". ...and, in the settings for which this patch was created, we felt that penalizing these domains just a little was an acceptible price for that same little bit of extra protection from those domains whose emails were just eeking through under our spam threshold scores. (In reply to comment #16) > (In reply to comment #15) > > Consider: "v=spf1 a mx all". > > > > Clearly, if the "a" or "mx" mechanism is the reason for the passing result, > > there is nothing "funny" going on here, despite having a "+all" in the > > record. I don't consider that clear at all. > The mere fact of having a +all, whether or not it is the mechanism used to > pass > SPF, could be a spam sign anyway. I could imagine it being an indicator > similar > in impact to, say, FREEMAIL_FROM, and useful to SA at least as a component of > metarules. But this is just a postulate; I've no idea whether current usage > bears this out. > Passing SPF only by virtue of a +all (or similarly all-inclusive pattern) > could > be another spam sign; I'd expect, again without having checked the actual > data, > that it would be a more discriminant spam sign. > Adding the SPF data in a pseudo-header would be a nice first step towards > collecting some real world statistics here... Since SA rules don't function as binary switches, the capability introduced by this patch is totally optional; you can score this rule however you like, or not use the functionality at all. This patch was submitted because others incouraged me to do so. It was created in the context of me (a non-programmer with almost zero Perl experience) and one other SA user meeting in a forum and responding to a specific pattern of spam we were seeing at the time. The senders were using SPF records including "+all" in order to allow their Botnets to deliver their email while earning a SPF "Pass" and the associated negative SA score for SPF rules. We were just trying to "undo" the little "bump" they were giving themselves (and we felt the penalty on domains with admins lazy or incompetent enough to actually create an SPF record that is totally worthless was worth paying and unlikely to create false positives). -- Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.
