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.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ clamav-users mailing list clamav-users@lists.clamav.net 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
