[clamav-users] clamav list spf problem

[Gene Heskett]

On Thursday 21 June 2018 11:47:02 Andrew McGlashan wrote:

> On 21/06/18 23:29, Gene Heskett wrote:
> > What I'd like to see is a good description of SPF.  All these
> > acronyms get thrown around, usually with no references as to why its
> > even needed or how to implement it. Does it help control the
> > neighborhood feral cat problem or what?
>
> If email is setup for a domain name (that you are responsible for),
> you can and should specify which servers are allowed to send email for
> that domain name.  If any servers (or any other Internet connected
> device) sends emails for your domain name and they are not in your
> authorized list, then those emails should be rejected.
>
> However, if you open up your SPF record to more widely accept other
> possible senders, then the bad guys have an opportunity to impersonate
> you more easily and you also risk getting a great deal more
> backscatter.
>
> If you have strong rules and you know exactly what you are doing, you
> can do tests to help make sure you got it right, then beyond the tests
> or testing period you are best to provide a hard fail response so that
> if any non-authorized sender tries to send email for your domain name,
> they /should/ be stopped.
>
> Well setup mail servers should check all incoming email against your
> published SPF records (published in DNS) and if your rules allow them
> to reject emails due to a non-authorized sender being deteected, then
> they really should reject the emails; if they do not honour your
> rules, then it can lead to unnecessary backscatter and potential for
> emails /from/ your domain name being sent fraudulently (ie not sent
> from an authorized server).
>
> Having weak rules that don't fully enforce the exact list of
> authorized senders can greatly lessen the value of SPF and make your
> rules next to useless -- especially if they do not do a hard fail.
>
> Now, relying on the settings (or rules) of other service providers
> gives an opportunity for someone else to ruin your rule set if they
> make a mistake -- the way this is done is to "include" someone else's
> rules without you being able to adjust them as required; you are
> therefore relying on them to get it right.  As I've said before, I run
> scripts to determine if an "upstream" or otherwise would be included
> entry has changed in any way, then I vet the changed rules to make
> sure they are valid (as best I can determine) and build my own rules
> based on the data from upstream and I do not allow the include to be
> active, which would allow someone else to break my rules beyond my
> control.
>
> There is another consideration with SPF that is very important, it is
> that there is a limited number of DNS lookups, if you do an include
> and they in turn do an include (and this could really expand out),
> then you will possibly hit the 10 maximum DNS lookups available before
> the SPF check will fail.  This is bad.  The less DNS lookups you need
> to do, the better -- you can avoid DNS lookups by using known fixed IP
> addresses in your rules in place of a DNS name.
>
> The other major problem with many people using SPF is that they have
> more than one rule returned when their SPF record is queried.  This is
> also invalid -- SPF *must* return a single entry (which may have
> includes), if there are two or more SPF results returned, then you
> have a problem and the tester of your rules should fail to provide you
> a positive result.
>
> If the possible sending servers are very dynamic, then it can be more
> difficult to get a suitable static SPF rule set.  But more often than
> not, the rule set can be very stable -- so, if you construct it
> carefully and purposely, then there is every chance you can provide a
> long standing answer that is very definitive and if it is obeyed, then
> it should be very hard for someone else to successfully send
> fraudulent emails for your domain name (provided all receiving mail
> servers check and make sure the rules are followed correctly).
>
> If your ISP or some other service provider is sending emails on your
> behalf, they /may/ also be responsible for the appropriate DNS records
> for your SPF.
>
> My own take is this, I run my own DNS servers, my own mail and web
> servers; I also run my own "cloud" servers (Nextcloud).  I do not
> believe in delegating these responsibilities to third parties and
> paying them for the privilege.  Many service providers themselves may
> not know what they are doing, so they too often err on the side of
> caution and often leave your SPF records open to abuse by having test
> or soft fail settings.  Of course having either test or soft fail
> settings will lessen the risk that your emails won't be delivered
> correctly, at the very real risk that it opens up your domain name for
> abuse.
>
> So, take responsibility if you have a domain name that your are
> responsible for with email facility and make sure that your SPF
> records are as exact and precise as possible to lessen the opportunity
> for someone else to abuse your domain name which can lead to damage to
> your domain name's reputation and consequently yourself as being the
> person responsible for the domain name's usage.
>
> Kind Regards
> A.

All sounds well and good, but where do I find the tut and tools to adjust 
this?


-- 
Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>