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> _______________________________________________ clamav-users mailing list [email protected] http://lists.clamav.net/cgi-bin/mailman/listinfo/clamav-users Help us build a comprehensive ClamAV guide: https://github.com/vrtadmin/clamav-faq http://www.clamav.net/contact.html#ml
