Re: Cron has been receiving this for months apparently.

[Kevin A. McGrail]

On 9/24/2018 6:08 PM, John wrote:
> Hi list,
>
> Cron has been receiving this for months apparently.
>
> /etc/cron.daily/spamassassin:
> error: unable to refresh mirrors file for
> channel updates.spamassassin.org ,
> using old file
> channel: could not find working mirror, channel failed
> sa-update failed for unknown reasons
>
> How do I sort this please?
Run sa-update -D and see if that has anything more useful in it.

Check if you have wget and/or curl.

There were old versions of curl that could not fetched the MIRRORED.BY
file on https.  We exempted it a few days ago since we didn't consider
it a risk.

Regards,
KAM

-- 
Kevin A. McGrail
VP Fundraising, Apache Software Foundation
Chair Emeritus Apache SpamAssassin Project
https://www.linkedin.com/in/kmcgrail - 703.798.0171

Cron has been receiving this for months apparently.

[John]

Hi list,

Cron has been receiving this for months apparently.

/etc/cron.daily/spamassassin:
error: unable to refresh mirrors file for channel updates.spamassassin.org,
using old file
channel: could not find working mirror, channel failed
sa-update failed for unknown reasons

How do I sort this please?

TIA

John

Re: Hints needed for spf rule

[Adam Katz]

 

On 2018-09-22 10:33 am, Kevin A. McGrail wrote: 

> On 9/22/2018 10:29 AM, Matus UHLAR - fantomas wrote:
> 
>> remove those ?'s: /^v=spf1 .*?all/ and /^v=spf1 .*+all/
> 
> Updated. I was trying to stop a greedy regex if someone was doing a
> weird spf but I am overthinking.

These SPF records are all effectively equivalent (the fourth is Sender
ID [1], we'll get to #5 later): 

v=spf1 +all
v=spf1 all
v=spf1 all 192.0.2.0/24
v=spf2.0/mfrom +all
v=spf1 1.2.3.0/1 128.4.5.0/2 192.6.7.8/3 -all

So therefore I propose regexps like /^v=spf[12].*[s+]allb/ and
/^v=spf[12].*s?allb/ (the latter should be very rare and a better
indication of a clueless admin than a spammer).

The fifth item above permits 0.0.0.0 to 223.255.255.255 and therefore
only multicast and the reserved Class E network are banned. To address
this, consider /^v=spf[12].*[0-9]/[0-7]b/. I haven't observed this sort
of workaround (yet), but it's the attackers' logical escalation in
response to this. (I conservatively chose a max mask of /7, though I
don't think there's any legitimate use of /8, even by the remaining
Class A holders [2] like AT, HP, and the US DoD--nobody _should_ have
an email network even approaching a /16 let alone a /8, though note that
Google currently includes three /16s. I'm not sure where to draw a
similar "too large" threshold for IPv6; perhaps /32?)

-Adam (still here, sometimes) 

Links:
--
[1] https://en.wikipedia.org/wiki/Sender_ID
[2]
https://en.wikipedia.org/wiki/List_of_assigned_/8_IPv4_address_blocks#List_of_assigned_/8_blocks