anti-spam false positive ... egad, that was annoying to track down ...
anti-spam false positive ... egad, that was annoying to track down ... So ... got posting failure(s), e.g. (slightly trimmed): ----- Forwarded message from MAILER-DAEMON ----- ----- The following addresses had permanent fatal errors ----- <balug-announce@temp.balug.org> (reason: 550-Rejected message body text: URL link to prohibited file:) ----- Transcript of session follows ----- ... while talking to mx.temp.balug.org.:
DATA <<< 550-Rejected message body text: URL link to prohibited file: <<< 550-http://search.cpan.org/~oalders/WWW-Mechanize-1.86/lib/WWW/Mechanize.pm <<< 550-. <<< 550-[EximConfig-2.5-temp.balug.org-Body-Reject] <<< 550-. <<< 550-.Verify: verified-32928-balug-announce@temp.balug.org <<< 550-Contact: postmaster@temp.balug.org <<< 550-. <<< 550-Sorry, your message has been rejected because <<< 550-its body text/content is prohibited for the <<< 550-above reason. <<< 550-. <<< 550-We apologise if you have sent a legitimate <<< 550-message and it has been blocked. If this is <<< 550-the case, please re-send adding verified-32928- <<< 550-to the beginning of the E-mail address of each <<< 550-recipient. If you do this, your message will <<< 550-get through these restrictions. <<< 550-. <<< 550-If your message has been incorrectly blocked, <<< 550-please let us know at the above contact address. <<< 550 . 554 5.0.0 Service unavailable ----- End forwarded message -----
/var/log/exmi4/rejectlog: rejected after DATA: Message body matched in /etc/exim4/eximconfig/reject/body (URL link to prohibited file: http://search.cpan.org/~oalders/WWW-Mechanize-1.86/lib/WWW/Mechanize.pm) well ... misleading diagnostic ... not at all triggered from /etc/exim4/eximconfig/reject/body ... in fact fully commenting out everything in there (and config reloaded and such) - and it was still getting rejected in exact same manner Anyway, dug backwards from the diagnostic message, etc. ... eventually traced it back to: $ cat /etc/exim4/eximconfig/accept/attachment_executable_body # List of executable file types that will be excluded from blocking in # http:// URL links present in body text. For example, extensions used # by server-side scripting. # For blocked executables, see: reject/attachment_executable_inbound eml|js|pl|pm $ Had to add the pm in there for it to not reject body containing URL ending in .pm Also found it was inconsistent in rejecting such a URL ... somewhat different manners of emailing/encoding - and sometimes it wouldn't reject it. The verified- addresses also seem not-so-useful. Thus far every time I've tried such, messages still fail in exact same manner.
Quoting Michael Paoli (Michael.Paoli@cal.berkeley.edu):
anti-spam false positive ... egad, that was annoying to track down ...
So ... got posting failure(s), e.g. (slightly trimmed):
I don't think much of the 'verified' thing. Can't recall whether I ever tested it. (BTW, my current MTA doesn't use EximConfig's rulesets, because this system was put together in a hurry.) Occasionally, you will find rules that are poorly thought out or misbegotten. Then, you'll need to decide whether to remove or fix them.
Yes, ... a pretty good rule set, albeit quite aggressive. Did already tweak fair bit on configuration earlier ... I'm sure there will be occasional items (notably false positives) that come up. Fortunately thus far they've been pretty few, but yes, will need to deal with those - at least as feasible and appropriate. But overall, at least thus far, I've been quite pleased with it. I do also quite like the greylisting - which I also did tweak (to initial delay of only 2 minutes - much more tolerable / less annoying, for legitimate email that encounters such). I like being able to add domains that are (almost?) entirely spam to such, so that they seem to (thus far) entirely thwart the spam, ... but should a legitimate email ever come from such a domain - well, then it generally would/should actually make it through ... just with a wee bit more delay is all. But yeah, some of the other email addresses (and ISPs, etc.) I have ... sometimes I look over the spam for sending domains, and for those I've never ever yet seen any non-spam use of, rather than block 'em outright, I just tighten the screws a bit more so spam from such is more probable to not make it through, while leaving it still at least reasonable for legitimate email (should there ever be such from such a domain) to reasonably make it through. Another thing I notice ... seems the spammers are learning a bit ... and/or some of eximconfig's database tracking - the (attempted) spam volumes seem to be trending down from earlier ... probably started out as "ooh, fresh meat, let's see if we can spam there" - or so the spambots would behave ... but weeks later, perhaps more like: "uh, ... that's a harder target ... let's not spend quite as much resource trying on that one". Whether it's the spambots, or eximconfig (notably with database bits), seems one or both are learning ... at least some reasonable bit (or ... maybe as statistical fluke, or unrelated correlation? ... who knows. I don't exactly have huge volumes of data to compare and review and do trend analysis on ... at least yet).
From: "Rick Moen" <rick@linuxmafia.com> Subject: Re: [BALUG-Admin] anti-spam false positive ... egad, that was annoying to track down ... Date: Wed, 16 Aug 2017 10:25:25 -0700
Quoting Michael Paoli (Michael.Paoli@cal.berkeley.edu):
anti-spam false positive ... egad, that was annoying to track down ...
So ... got posting failure(s), e.g. (slightly trimmed):
I don't think much of the 'verified' thing. Can't recall whether I ever tested it. (BTW, my current MTA doesn't use EximConfig's rulesets, because this system was put together in a hurry.)
Occasionally, you will find rules that are poorly thought out or misbegotten. Then, you'll need to decide whether to remove or fix them.
Quoting Michael Paoli (Michael.Paoli@cal.berkeley.edu):
Yes, ... a pretty good rule set, albeit quite aggressive. Did already tweak fair bit on configuration earlier ... I'm sure there will be occasional items (notably false positives) that come up. Fortunately thus far they've been pretty few, but yes, will need to deal with those - at least as feasible and appropriate.
The same is true of SpamAssassin's rulesets. And there's a point about that, that I'll return to below.
But yeah, some of the other email addresses (and ISPs, etc.) I have ... sometimes I look over the spam for sending domains, and for those I've never ever yet seen any non-spam use of, rather than block 'em outright, I just tighten the screws a bit more so spam from such is more probable to not make it through, while leaving it still at least reasonable for legitimate email (should there ever be such from such a domain) to reasonably make it through.
Quite a lot of the newer TLDs seem to never originate any non-spam e-mail, I notice.
Another thing I notice ... seems the spammers are learning a bit
Well, yes, but:
... and/or some of eximconfig's database tracking - the (attempted) spam volumes seem to be trending down from earlier ... probably started out as "ooh, fresh meat, let's see if we can spam there" - or so the spambots would behave ... but weeks later, perhaps more like: "uh, ... that's a harder target ... let's not spend quite as much resource trying on that one".
My best guess is that this will prove to be, in part, a perceptual illusion on your end. What's definitely true is that an IP that gets newly deployed as an MTA host sees a ramp-up of spam delivery attempts as its presence on spammers' lists of known MTA IPs gets sent around. The part that I greatly _doubt_, based on everything I've read about spammers, is any IP-specific learning effort. Why do I say this? Because spammers' byword is always 'We do lots of dumb things, but we make it up in volume.' After all, they're mostly using stolen machine resources (malware-driven host compromise) and stolen bandwidth, so they don't perceive a payoff from concentrating on specific target IPs. This is why even simple spam defences tend to work pretty well, even ones that are easily defeated with human attention, because spammers don't lavish human attention on any specific target. It's more remunerative to just hammmer IP space. Which brings me to my point: Although spammers themselves are characteristically really stupid, the people who construct their toolsets are not. And among the many things the latter people do is test mass-mailings against standard antispam toolsets, e.g., a bog-standard, uncustomised installation of SpamAssassin. If the normal spamicity cutoff score in SpamAsssassin is 5.0 (which IIRC it is), then spam toolset makers provide point'n'drool methods for their slackjawed customers to ensure that spam they sent out measures no higher than 4.8. _Therefore_, local tweaks to the SpamAssassin rulesets are A Good Thing. You want your setup to be absolutely _not_ the same as everyone else's. Diversity of target, avoidance of an antispam monoculture, is a positive benefit. I've tweaked a number of the constituent SA rules, and also lowered the cutoff score to 4.0 after testing. But you[-generic] need to also remember to occasionally check for significan false positives (as I'm sure you do), because things can change. I vaguely recall that I messed up by not putting custom SA ruleset weightings into a site-specific local.cf file, which means one day I'll need to go find all the local tweaks I made in /usr/share/spamassassin/* files, where they are at risk of getting overwritten by upgrades.
participants (2)
-
Michael Paoli
-
Rick Moen