Any experiences with Spamassassin's Phishing Plugin? It was released in September 2018, it hasn't received the wide acclaim I would expect - I am curious what experiences the Proxmox community has had with with this innovation.
Spamassassin's Phishing Plugin
- Thread starter KatyComputer
- Start date
I just stumbled on heutger's post where he describes implementing this plugin. Well worth the read. Thank you.
Not a single hit - perhaps that's why no one is using it. When I get some time, I need to run a test - assign it a very low score and manually adjust the feeds.
OTOH Invaluement has been remarkably effective, the only real problem is its propensity to ding Infusionsoft emails. If it was just my emails, I would say "Great", but clients frequently want that junk, so I maintain a file filled with directives like this:
def_whitelist_auth *@infusionmail.com
OTOH Invaluement has been remarkably effective, the only real problem is its propensity to ding Infusionsoft emails. If it was just my emails, I would say "Great", but clients frequently want that junk, so I maintain a file filled with directives like this:
def_whitelist_auth *@infusionmail.com
But I believe, it's not taking too much cpu power or hdd space to leave it off. For sure, Phishtank as well as Openphish (explicit in the free access) provide "well known" phishing, but good phishing should not be well known but take time to get listed there, so it's a "just in case" measurement. Everyone can improve by providing phishing links to the feeds. ;-)
Invaluement is really great, but I don't use it for kicking, just for scoring, as they are sometimes a bit too hard. However, you still can directly write to the list owner, he is always open for suggestions and input. Maybe he will consider to split the zone into separate responses for spam and what you also would define as junk or bulk. So everyone then can decide, what they really want to block and what they don't want.
For the record, the PHISHING plugin works, but it hasn't caught anything in the several days we have had it in place.
Surprising, but true. I tested the plugin by adding a url to /etc/mail/spamassassin/openphish-feed.txt, then sent myself a message from Yahoo, the "phish" was logged:
Surprising, but true. I tested the plugin by adding a url to /etc/mail/spamassassin/openphish-feed.txt, then sent myself a message from Yahoo, the "phish" was logged:
Code:
grep -ris "URI_PHISHING" /var/log
/var/log/mail.log:Oct 25 09:43:59 stl-mx pmg-smtp-filter[11897]: 1AA2F5DB30A2D3C576: SA score=0/5 time=1.847 bayes=0.00 autolearn=no autolearn_force=no hits=AWL(-0.502),BAYES_00(-1.9),DCC_REPUT_13_19(-0.1),DKIM_SIGNED(0.1),DKIM_VALID(-0.1),DKIM_VALID_AU(-0.1),DKIM_VALID_EF(-0.1),ENV_AND_HDR_SPF_MATCH(-0.5),FREEMAIL_FROM(0.001),HTML_MESSAGE(0.001),KAM_SHORT(0.001),RCVD_IN_DNSWL_NONE(-0.0001),SPF_HELO_NONE(0.001),SPF_PASS(-0.001),T_KAM_HTML_FONT_INVALID(0.01),URI_PHISHING(1.4),USER_IN_DEF_DKIM_WL(-7.5),USER_IN_DEF_SPF_WL(-7.5)
/var/log/syslog:Oct 25 09:43:59 stl-mx pmg-smtp-filter[11897]: 1AA2F5DB30A2D3C576: SA score=0/5 time=1.847 bayes=0.00 autolearn=no autolearn_force=no hits=AWL(-0.502),BAYES_00(-1.9),DCC_REPUT_13_19(-0.1),DKIM_SIGNED(0.1),DKIM_VALID(-0.1),DKIM_VALID_AU(-0.1),DKIM_VALID_EF(-0.1),ENV_AND_HDR_SPF_MATCH(-0.5),FREEMAIL_FROM(0.001),HTML_MESSAGE(0.001),KAM_SHORT(0.001),RCVD_IN_DNSWL_NONE(-0.0001),SPF_HELO_NONE(0.001),SPF_PASS(-0.001),T_KAM_HTML_FONT_INVALID(0.01),URI_PHISHING(1.4),USER_IN_DEF_DKIM_WL(-7.5),USER_IN_DEF_SPF_WL(-7.5)
/var/log/mail.info:Oct 25 09:43:59 stl-mx pmg-smtp-filter[11897]: 1AA2F5DB30A2D3C576: SA score=0/5 time=1.847 bayes=0.00 autolearn=no autolearn_force=no hits=AWL(-0.502),BAYES_00(-1.9),DCC_REPUT_13_19(-0.1),DKIM_SIGNED(0.1),DKIM_VALID(-0.1),DKIM_VALID_AU(-0.1),DKIM_VALID_EF(-0.1),ENV_AND_HDR_SPF_MATCH(-0.5),FREEMAIL_FROM(0.001),HTML_MESSAGE(0.001),KAM_SHORT(0.001),RCVD_IN_DNSWL_NONE(-0.0001),SPF_HELO_NONE(0.001),SPF_PASS(-0.001),T_KAM_HTML_FONT_INVALID(0.01),URI_PHISHING(1.4),USER_IN_DEF_DKIM_WL(-7.5),USER_IN_DEF_SPF_WL(-7.5)KatyComputer,
This is Rob McEwen, CEO of invaluement. I stumbled across this thread while doing a search on recent "mentions" of invaluement on Google, and this thread was near the top. For the most part, we already had almost all of InfusionSoft's IP space whitelisted - but there was this one problematic /24 block where: (1) they didn't identify it as having its own IP whois record - which is unusual for an ESP this large. Instead, it was showing up in generic Google Cloud IP space. (2) they were mistakenly NOT setting a proper PTR record for many of the IPs in this block from which they were sending email. This caused us to NOT properly identify this as their space. The particular subnet to which I'm referring is: 35.227.130.0/24 - and I think you'll find a strong correlation to THIS block, and the occasional false positives you were seeing? If so, this should be fixed now.
Meanwhile, related to this, over the past couple of years, it has become a HUGE problem that many of these large ESPs are starting to get a "we're too big to blacklist" mentality and are NOT doing as good of a job as they used to with preventing spammers from using their system. And this is frustrating end users and email hosting companies as more and more spams sent from these ESPs get into the inbox. Meanwhile, these ESPs are literally laughing all the way to bank with loads of cash they are making from these spammers - but they're slowly destroying email and undermining their legit non-spamming customers as they do this!
InfusionSoft (now called "Keap") is actually one of the better ESPs and doesn't do as much of this as many others. But this is a strong trend across the board, and, sadly, ESPs doing this correctly are starting to feel like an idiot as they lose market share to competitors who really don't care much anymore.
SOLUTION? At invaluement we're working on addition to our system that will enable use to surgically-target the bad-apple spammy customers of ESPs, yet without blacklisting the domains and IP addresses that would cause too much of the collateral damage that happened in this situation that you mentioned. I'm hoping to have a beta release of this within weeks from now!
I hope this helps and please let me know if our whitelisting of 35.227.130.0/24 solved most or all of your problem? If not, please email me any other IPs of Keap (formerly InfusionSoft) that you are seeing that are continuing to get blacklisted at invaluement.
Thanks!
Rob McEwen, CEO of invaluement.com
Last edited:
Thanks for this detailed explanation. We are seeing spam from large ESPs such as Sendgrid & Mailgun. This week-end, I added Spamhaus' Domain Block List (DBL) to the mix, it helped snare spam from a number of newly visible domains (dormant domains registered years ago) as well as newly registered domains.
DBL is especially useful for its unique approach to listing the domains in the FROM address and the domain at the end of the PTR record - which is different from what invaluement is currently doing. That is definitely helpful. Also, what I had described will be a very different approach that will block other spams from ESPs that both DBL and Spamhaus' Zen list are not even trying (or able!) to block. But these will ALL complement each other nicely - just as invaluement's current lists and Spamhaus' lists also complement each other well since they each block much spam that the other misses.
Thanks again for the feedback.
I continue to see quite a few domains without a SPF record, a "~all" or perhaps an ip:0.0.0.0/0 SPF record, hopefully, DBL & SURBLs will force these organizations to be a bit more responsible.
OTOH, we see situations like Office 365 servers that cannot be bothered with valid rDNS records, because their situation is "too complicated".
OTOH, we see situations like Office 365 servers that cannot be bothered with valid rDNS records, because their situation is "too complicated".
If there is not actually a spamming component to this - then I'm hoping they don't. That would get them off-mission and cause the same kind of false positives that you weren't pleased with regarding invaluement blocking occasional Infusionsoft (Keap) messages. (which should be solved now - please let me know if you're still seeing that?) Generally speaking, DNSBLs are going to get little praise and massive criticism if/when they ever cause false positives as a part of trying to order any enforce standards that are extra-curricular to the spam problem.
(except it was actual spam that had been triggering those Infusionsoft blacklistings - but the false positives will have the same pain/issues)