SendGrid (Was: Re: Freshdesk (again))
Hello, On Fri, Jun 26, 2020 at 07:32:09PM -0600, Grant Taylor wrote: > I've got to say, between NANOG, SDLU, and SpamAssassin, I see a LOT of > complaints about Sendgrid. Also mailop. Have personally received phishing mails through SendGrid in the last 2 weeks in the name of citrix.com, microsoft.com and netflix.com. The Citrix one was to a hostmaster@ address. It's hard to comprehend how SendGrid could be doing a worse job of this, for so many months now. Yet their list of legit clients is large, so they remain unblockable for me. I just wish those clients knew how little SendGrid would do to prevent their other customers sending out phishing emails in their name. Cheers, Andy
Re: Freshdesk (again)
On 6/26/20 7:01 PM, Bill Cole wrote: I had a similar event 6/30 and poked them about it via both a public Tweet & a complaint to Sendgrid. Both entities responded *claiming* that they were looking into the problem. Assuming that yours also came via Sendgrid, it might help to add your complaint via ab...@sendgrid.com. I looked after your message and sure enough, the message did come via Sendgrid. I've got to say, between NANOG, SDLU, and SpamAssassin, I see a LOT of complaints about Sendgrid. They had their chance 2+ years ago and appear to have resumed the obnoxious practice. They need to be gone. Agreed. -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic Signature
Re: Freshdesk (again)
On 26 Jun 2020, at 20:44, Grant Taylor wrote: I received an automated email from Freshdesk about five minutes after my post to the SpamAssassin mailing list earlier this afternoon. I had a similar event 6/30 and poked them about it via both a public Tweet & a complaint to Sendgrid. Both entities responded *claiming* that they were looking into the problem. Assuming that yours also came via Sendgrid, it might help to add your complaint via ab...@sendgrid.com. I found an old thread about Freshdesk in the SpamAssassin Users archive [1]. This supports (confirms to me) that this is what happens. I object to this type of behavior and would like for whomever is doing it to be unsubscribed from the SpamAssassin Users mailing list on principal. Maybe give them one chance to come forward, admit the error of their ways, and to promise to cease and desist immediately. They had their chance 2+ years ago and appear to have resumed the obnoxious practice. They need to be gone.
Freshdesk (again)
I received an automated email from Freshdesk about five minutes after my post to the SpamAssassin mailing list earlier this afternoon. I found an old thread about Freshdesk in the SpamAssassin Users archive [1]. This supports (confirms to me) that this is what happens. I object to this type of behavior and would like for whomever is doing it to be unsubscribed from the SpamAssassin Users mailing list on principal. Maybe give them one chance to come forward, admit the error of their ways, and to promise to cease and desist immediately. [1] https://mail-archives.apache.org/mod_mbox/spamassassin-users/201710.mbox/thread -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic Signature
Re: White listing messages processed by a previous milter
On Sat, 2020-06-27 at 00:46 +0200, Marc Roos wrote: > > What would be the best practice to whitelist / not process, messages > that have already been processed by a previous milter. > If you've already whitelisted a message and want it to bypass SA, then you will, by definition, have total confidence that your milter does not generate FPs or FNs. In that case, why pass it through SA when it would be much simpler for the milter to pass it directly to your MTA for delivery without any further processing? I've been doing the opposite for years: in my case getmail collects incoming mail and passes it through SA, which sends it to a discrimination program which quarantines spam and passes non-spam to my internal MTA for delivery. After tuning SA to deal with my particular incoming mail stream, this has very few FNs or FPs (which are retrievable from quarantine). This works for my low volume mail stream: there's no reason why higher volume sites shouldn't use a full-monty MTA to feed the incoming stream through SA and a spam discriminator before passing the clean stream to a second MTA for delivery. Martin
Re: White listing messages processed by a previous milter
On 6/26/20 4:46 PM, Marc Roos wrote: What would be the best practice to whitelist / not process, messages that have already been processed by a previous milter. I'm confused. My knee jerk reaction is that's an MTA configuration issue. But I don't think it can be that simple. I can't think of a situation where the MTA would behave differently (under normal circumstances). I would expect that messages coming in a path would always flow through the same set of milters. Hence configuration issue. But, maybe you're in a situation where messages make it to a mailbox through different paths and the LDA is invoking SpamAssassin. Please help me understand the situation that you're asking about. The only thing that comes to mind is to do something similar to what you're saying, add an artificial header before SpamAssassin, that you can have SpamAssassin filter on. Then artificially lower the spam score, or see if there is a way to have SpamAssassin end early without any additional filtering. Normal circumstances allows for situations where a milter earlier in the chain might fail open. -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic Signature
White listing messages processed by a previous milter
What would be the best practice to whitelist / not process, messages that have already been processed by a previous milter. Maybe set a message header and whitelist on this message header?
Re: very slow scans
On 6/25/2020 4:13 PM, Paul wrote: > I'm running SA version 3.4.4 on a Synology NAS/server (which runs a > fairly limited Linux install) with 1G of RAM, using its basic > spamd/spamc setup. I have network tests and Bayes temporarily > disabled, and no custom rules, and my RAM and CPU are both under 15% > average. Everything else on the machine is quick and responsive. > > But it usually takes SpamAssassin over 100 seconds to scan a message, > sometimes 300 seconds or more. I added a Timing header which reports > that about 80% of that time is read_scoreonly_config. The nature of > the message doesn't seem to make a difference. > > It's been like this for a while, but I only just became impatient and > decided to fix it. > > Any tips on how to track this down? Thanks! Can you replicate the issue on the command line with spamassassin -t -D < email.msg and then with spamc? -- Kevin A. McGrail kmcgr...@apache.org Member, Apache Software Foundation Chair Emeritus Apache SpamAssassin Project https://www.linkedin.com/in/kmcgrail - 703.798.0171
Re: sa-update failing
Stephan, The type for the update record is a TXT not an A record, so dig -t txt 3.3.3.updates.spamassassin.org. I'm not sure if an update has failed for the past 2 days though so this is just a comment on how to check manually. ;; ANSWER SECTION: 3.3.3.updates.spamassassin.org. 3600 IN TXT "1879218" Regards, KAM On 6/26/2020 4:13 AM, Stephan Fourie wrote: > Hi everyone, > > Our SpamAssassin rules have not gotten any recent updates (looks like > past 2 days). When investigating, sa-update tries to connect to: > 2.4.3.updates.spamassassin.org > > When doing a DNS lookup on this hostname it appears to be a CNAME > which points to: 3.3.3.updates.spamassassin.org. When doing a lookup > for 3.3.3.updates.spamassassin.org it doesn't resolve, which I'm > leaning towards being the issue. Please see below lookup results: > > - > ;; QUESTION SECTION: > ;3.3.3.updates.spamassassin.org. IN A > > ;; AUTHORITY SECTION: > spamassassin.org. 1799 IN SOA ns2.pccc.com. > pmc.spamassassin.apache.org. 2020062505 7200 3600 604800 3600 > > ;; Query time: 265 msec > ;; SERVER: 8.8.8.8#53(8.8.8.8) > ;; WHEN: Fri Jun 26 10:10:28 SAST 2020 > ;; MSG SIZE rcvd: 131 > - > > Anyone else seeing the same issue? > > Thanks! > Stephan -- Kevin A. McGrail kmcgr...@apache.org Member, Apache Software Foundation Chair Emeritus Apache SpamAssassin Project https://www.linkedin.com/in/kmcgrail - 703.798.0171
Re: sa-update failing
It queries TXT records $ dig TXT 2.4.3.updates.spamassassin.org ;; ANSWER SECTION: 2.4.3.updates.spamassassin.org. 3424 IN CNAME 3.3.3.updates.spamassassin.org. 3.3.3.updates.spamassassin.org. 79 IN TXT "1879105" It is normal that updates might be stale for a few days sometimes. Use "sa-update -D" to debug and post relevant lines if you have an actual problem. On Fri, Jun 26, 2020 at 10:13:00AM +0200, Stephan Fourie wrote: > Hi everyone, > > Our SpamAssassin rules have not gotten any recent updates (looks like past 2 > days). When investigating, sa-update tries to connect to: > 2.4.3.updates.spamassassin.org > > When doing a DNS lookup on this hostname it appears to be a CNAME which points > to: 3.3.3.updates.spamassassin.org. When doing a lookup for > 3.3.3.updates.spamassassin.org it doesn't resolve, which I'm leaning towards > being the issue. Please see below lookup results: > > - > ;; QUESTION SECTION: > ;3.3.3.updates.spamassassin.org. IN A > > ;; AUTHORITY SECTION: > spamassassin.org. 1799 IN SOA ns2.pccc.com. > pmc.spamassassin.apache.org. 2020062505 7200 3600 604800 3600 > > ;; Query time: 265 msec > ;; SERVER: 8.8.8.8#53(8.8.8.8) > ;; WHEN: Fri Jun 26 10:10:28 SAST 2020 > ;; MSG SIZE rcvd: 131 > - > > Anyone else seeing the same issue? > > Thanks! > Stephan
sa-update failing
Hi everyone, Our SpamAssassin rules have not gotten any recent updates (looks like past 2 days). When investigating, sa-update tries to connect to: 2.4.3.updates.spamassassin.org When doing a DNS lookup on this hostname it appears to be a CNAME which points to: 3.3.3.updates.spamassassin.org. When doing a lookup for 3.3.3.updates.spamassassin.org it doesn't resolve, which I'm leaning towards being the issue. Please see below lookup results: - ;; QUESTION SECTION: ;3.3.3.updates.spamassassin.org. IN A ;; AUTHORITY SECTION: spamassassin.org. 1799 IN SOA ns2.pccc.com. pmc.spamassassin.apache.org. 2020062505 7200 3600 604800 3600 ;; Query time: 265 msec ;; SERVER: 8.8.8.8#53(8.8.8.8) ;; WHEN: Fri Jun 26 10:10:28 SAST 2020 ;; MSG SIZE rcvd: 131 - Anyone else seeing the same issue? Thanks! Stephan
