Why does Sberbank have an incorrect SPF record for a domain?
In short: Sberbank's main domain (sberbank.ru) has an incorrect SPF record. This leads to the fact that attackers have the opportunity to make fake emails on behalf of Sberbank. The record itself is well-adjusted, fit, but with an error that nullifies all efforts.
Happy finale: during the day they fixed the record, now it is RFC compliant.
Well, and for those who will master to read - welcome under kat.
SPF helps to deal with the fake sender addresses. Do not confuse SPF with DMARC, SPF only allows you to determine whether a given IP address could send mail on behalf of that domain (with support for a number of exceptions and curtsies).
')
There is an opinion that SPF is not needed and harmful , however, as practice shows, SPF today is the main mechanism in DMARC and there is nothing like this on the horizon.
The mail server, accepting mail, looks at the sender's address, and then goes and requests special records from the sender's domain, where it is formulated in a cunning language, which IP can send mail from this domain, and which is not. As a result, a decision is made whether to accept this letter or not, and maybe to accept and count as spam.
Well, in general, not really. Initially, a record type was provided in SPF that allows Softfail to be made. It is like a joint, but excusable. That is, I say that mail from my domain can come from these addresses, then it is exactly normal. And if with some others, then this is forgivable.
This excusable posting in general today practically nullifies the sense of SPF, since spammers often get into this excuse post.
And in that their entry contains -all, this is precisely the avoidance of the apologetic Softfail. That is, the guys from Sberbank as if tell us that the mail from them can only come from the specified addresses and nothing else. Well done, that's great.
And the fact that the record they have formulated incorrectly. This causes a Permerror error, and then for most mail systems, the entry is not even checked, and the letter is simply skipped.
Agree, stupid to do -all, hard record and at the same time to make a mistake, making the whole record incorrect.
RFC 7208 introduces some restrictions on the number of DNS queries that the mail server must make in order to receive the necessary data in the SPF. It is the same RFC limits the number of queries with an empty result or error.
Parse the record:
0. v = spf1
The version of the SPF record, i.e. syntax
1. mx
Only servers that are listed as MX can send mail from the sberbank.ru domain.
Well, we see these five servers.
2. mx: shark11.sberbank.ru
Mail from the sberbank.ru domain can be sent by those servers listed as MX for the shark11.sberbank.ru domain
STOP! Again.
Mail from the sberbank.ru domain can be sent by those servers listed as MX for the shark11.sberbank.ru domain
And this result is counted as empty. And according to the RFC, after the first two such errors, you should stop analyzing the SPF record and consider it erroneous. What is happening.
In short, the guys overdid it a bit.
In fact, Sberbank itself rarely sends letters, or rather, in our postal system, for example, there are not so many of them. Much more of them come from the site "Sberbank AST", let's see there.
And then, alas, Softfail. Which nullifies the value of SPF records.
UPDATE
Colleagues from Sberbank AST responded quickly. Now like this:
In fact, of course, somewhat redundant, since there is an indication of mx and
But switching from ~ all to-all is commendable.
> host -t txt sberbank.ru sberbank.ru descriptive text "v=spf1 mx mx:shark11.sberbank.ru mx:shark12.sberbank.ru mx:shark13.sberbank.ru mx:shark14.sberbank.ru mx:email1.sberbank.ru -all" Happy finale: during the day they fixed the record, now it is RFC compliant.
> host -t txt sberbank.ru sberbank.ru descriptive text "v=spf1 mx -all" Well, and for those who will master to read - welcome under kat.
Why do you need SPF?
SPF helps to deal with the fake sender addresses. Do not confuse SPF with DMARC, SPF only allows you to determine whether a given IP address could send mail on behalf of that domain (with support for a number of exceptions and curtsies).
')
There is an opinion that SPF is not needed and harmful , however, as practice shows, SPF today is the main mechanism in DMARC and there is nothing like this on the horizon.
How it works?
The mail server, accepting mail, looks at the sender's address, and then goes and requests special records from the sender's domain, where it is formulated in a cunning language, which IP can send mail from this domain, and which is not. As a result, a decision is made whether to accept this letter or not, and maybe to accept and count as spam.
And what really works?
Well, in general, not really. Initially, a record type was provided in SPF that allows Softfail to be made. It is like a joint, but excusable. That is, I say that mail from my domain can come from these addresses, then it is exactly normal. And if with some others, then this is forgivable.
This excusable posting in general today practically nullifies the sense of SPF, since spammers often get into this excuse post.
What Sberbank fellow?
And in that their entry contains -all, this is precisely the avoidance of the apologetic Softfail. That is, the guys from Sberbank as if tell us that the mail from them can only come from the specified addresses and nothing else. Well done, that's great.
And what is Sberbank wrong?
And the fact that the record they have formulated incorrectly. This causes a Permerror error, and then for most mail systems, the entry is not even checked, and the letter is simply skipped.
Agree, stupid to do -all, hard record and at the same time to make a mistake, making the whole record incorrect.
But where is the mistake?
RFC 7208 introduces some restrictions on the number of DNS queries that the mail server must make in order to receive the necessary data in the SPF. It is the same RFC limits the number of queries with an empty result or error.
Parse the record:
"v=spf1 mx mx:shark11.sberbank.ru mx:shark12.sberbank.ru mx:shark13.sberbank.ru mx:shark14.sberbank.ru mx:email1.sberbank.ru -all" 0. v = spf1
The version of the SPF record, i.e. syntax
1. mx
Only servers that are listed as MX can send mail from the sberbank.ru domain.
> host -t mx sberbank.ru sberbank.ru mail is handled by 50 shark11.sberbank.ru. sberbank.ru mail is handled by 50 shark14.sberbank.ru. sberbank.ru mail is handled by 50 email1.sberbank.ru. sberbank.ru mail is handled by 50 shark12.sberbank.ru. sberbank.ru mail is handled by 50 shark13.sberbank.ru. Well, we see these five servers.
2. mx: shark11.sberbank.ru
Mail from the sberbank.ru domain can be sent by those servers listed as MX for the shark11.sberbank.ru domain
STOP! Again.
Mail from the sberbank.ru domain can be sent by those servers listed as MX for the shark11.sberbank.ru domain
> host -t mx shark11.sberbank.ru shark11.sberbank.ru has no MX record And this result is counted as empty. And according to the RFC, after the first two such errors, you should stop analyzing the SPF record and consider it erroneous. What is happening.
In short, the guys overdid it a bit.
How was it to be done?
"v=spf1 mx -all" Or maybe colleagues have done better?
In fact, Sberbank itself rarely sends letters, or rather, in our postal system, for example, there are not so many of them. Much more of them come from the site "Sberbank AST", let's see there.
> host -t txt sberbank-ast.ru sberbank-ast.ru descriptive text "v=spf1 mx a:mail2.sberbank-ast.ru a:mail3.sberbank-ast.ru a:mail4.sberbank-ast.ru a:gw.sberbank-ast.ru a:mail7.sberbank-ast.ru ~all" And then, alas, Softfail. Which nullifies the value of SPF records.
UPDATE
Colleagues from Sberbank AST responded quickly. Now like this:
> host -t txt sberbank-ast.ru "v=spf1 mx a:mail2.sberbank-ast.ru a:mail3.sberbank-ast.ru a:mail4.sberbank-ast.ru a:gw.sberbank-ast.ru a:mail7.sberbank-ast.ru -all" In fact, of course, somewhat redundant, since there is an indication of mx and
> host -t mx sberbank-ast.ru sberbank-ast.ru descriptive text sberbank-ast.ru mail is handled by 5 mail4.sberbank-ast.ru. But switching from ~ all to-all is commendable.
Source: https://habr.com/ru/post/307852/
All Articles