https://issues.apache.org/SpamAssassin/show_bug.cgi?id=5684
--- Comment #21 from Andrew Kinnard <[email protected]> 2010-11-17 11:42:52 UTC --- (In reply to comment #20) > Actually, no. I let the following SPF results into SA for scoring...passing > SPF records based on "+all"... > are taken care of during the SMTP "MAIL FROM" state... Fair enough, but, as I said before, we didn't want to respond to +all SPF matches in a binary fashion; so, it goes to SA. > SPF "pass" receives a negative SA score? Interesting, but misguided. > If per SPF, I know that a message is forged and therefore will be rejected, > why > should I continue to process it?... You don't have to; you have the OPTION. See below about "philosophical objections". > With your patch, you could be scoring a "+all" when SPF returns failure or > other states if such strange SPF strings direct such an outcome. So what? If there is a +all SPF record AND an SPF failure, I'm going to be highly suspicious of that email. We wanted to consider email from any domain with a +all as slightly suspect (regardless of other factors). > Does that > make sense? Should "+all" be a factor when another mechanism produces the > result? I say no... Ok...how does that make the patch's functionality irrelevant for others (e.g., amavisd-new users)? > - and that's why I look for "+all" (or a wide CIDR match) > only when the SPF result is pass - because that is the result beneficial to > spammers and their trickery. Fantastic! Thank you for posting your MIMEdefang solution; it IS, in fact, a technically superior solution for MIMEdefang users who have the intent it serves. > Not all forged messages need be spam...SPF is an anti-forgery solution, not > an anti-spam one... This is a philosophical objection of the type I pointed out earlier. It is really irrelevant to the discussion unless you want to debate (elsewhere) whether SA should consider information not originally intended to be used in the fight against UCE and spam. I am sure you know that many SA rules are derived from statistical analysis of email traffic and may leverage information that is, from a philosophical standpoint, neutral (e.g., HTML formatting); so, you'd have a lot of arguing to do. And, for the most part, those arguments have been had and solved with SA's ability to score rules as you wish. >Also, your "+all" check in SPF will undoubtedly be used as > an override to the SPF "pass" result with a positive SA score so as to cause > message rejection... That was exactly the intent. As I stated earlier: That would only create false positives if the user scored this rule recklessly. > ...so why defer that to the SMTP message eom state when such > information is available earlier? Because we didn't use MIMEdefang then, and this patch fit our purposes. > You are correct that I consider the forged state as binary in nature. You misread (or I miscommunicated) my statement: I intended to point out your disaffinity for processing this particular piece of SPF record information in SA and your affinity for treating email from MTAs passing SPF via +all as fit for outright rejection before spooling. > Why shouldn't it be? The characteristic itself is binary... I agree, but we weren't trying to answer a question about forgery with the patch. The question we were asking was: does this domain have a "+all" in their SPF record?...that's all. We were not considering this in a determination about forgery but (as a very small factor) in a determination about spamminess. You don't have to like that, but it doesn't violate any guidelines about SA rules, nor did it result in any real problems in practice. > Since you asked -- I consider these operations as: > FCrDNS: Binary. I reject failures before the "HELO" state. > DNSBLs: I consider 4 of them as binary and reject immediately. I score the > rest because they have some false positives and are thus not as reliable. I take a completely opposite approach. I prefer all these handled more "gently" (than an MTA can do) by SA. For most of my sites, placing these checks at the MTA would result in too many false positives in a very real, immediate and business-impacting way. Have you ever argued with the "other" email admin about how they need to fix their PTR record(s)? Have you ever explained to your client that all email from a major ISP got bounced yesterday because a here-to-for reliable RBL listed the provider's MTAs? Yeah, that usually doesn't go well. Business owners don't care WHY you had a false positive, just that there WAS one and that it disrupted business. So, again, I feel like this is the crux of your objection (i.e., preference for pre- or post-spool processing of certain information). That's not an objection to the patch, it is stating that you don't like its function handled post-spool and that you wouldn't use it. Yes, the patch can be improved. Yes, it is not "pure" in its use of certain tech not as originally intended. However, it does what we intended it to do, and that intent is an acceptible goal within the framework of what SA already does. > I don't disagree with the overall intent of your patch. You seem to AEB your continued assertion that we shouldn't consider SPF information in a determination of spamminess and therefore (and for efficiency reasons) should be handled by SA (post-spool). > I clearly disagree > with the implementation of that intent. The only functional criticism has been that it's less efficient than pre-spool SPF parsing and has a very small chance of contributing to a false positive from SA. Both of these shortcomings we found to be acceptible, and the first is a design/engineering choice, not a shortcoming but a trade-off for desired functionality. > I also note that your solution may > cause the score to be altered when "+all" is present but UNUSED in determining > the SPF result and call that inappropriate to the "corrective measure" of > adding this functionality in this manner. We found that not only acceptible but intended by design. > My solution may be a bit more > strict, but it also generates a proper RFC 5451 answer (the > "Authentication-Results:" header), and only penalizes those SPF results where > "+all" is the determining mechanism, plus the bonus of it's not fooled by CIDR > equivalents. ...and in those ways it IS superior (if you use MIMEdefang and have a different intent than we did [i.e., a small positive score in SA for domains with an SPF record including "+all"...we WANTED that]). Also, any rejection from SA would have been based on an accumulated score; so, the patch should NOT return any RFC 5451 answer (even if it could, because the mail wouldn't have been rejected for any ONE reason). That RFC 5451 answer is appropriate for your solution but not this one. -- Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.
