Several anti-spam systems provide methods of sending feedback so that e-mail service administrators can learn about complaints against their own senders. These feedbacks are very important for the email service administrator because too many abuses can compromise the reputation of the IP used by the service. If an IP’s reputation is compromised, multiple providers may stop receiving messages from that service.
The best-known feedback system is the Feedback Loop (FBL). The big problem with this system is that it depends on previous registration in each destination provider. If the email service administrator wants to have access to all of the complaint information against their senders, they must register at each FBL provider.
This FBL registration procedure is costly and complicated. For this reason, the SPFBL project has created a special rejection prefix, at the SMTP layer, so that email service administrators can obtain all information without registering with SPFBL providers.
About the SPFBL reputation system
The SPFBL reputation system consists of counting all legitimate messages (HAM) and illegitimate messages (SPAM) within a certain period of time for each source IP. This period will never be longer than seven days. This information is collected from all SPFBL project contributors through a P2P network.
Using these counts, the SPAM ratio is calculated by the total sending volume, which will be the sum of HAM and SPAM of that IP:
P = SPAM /(HAM+SPAM)
If this ratio exceeds the 50% threshold, the IP will be listed on the DNSBL SPFBL.net.
How to identify SPFBL rejection prefix
The SPFBL rejection prefix is generated in the SMTP layer and consists of the code 5.7.1, which means that the sending is not authorized, plus the word SPFBL, which means that there was a negative punctuation, due to the increment of the SPAM count:
The message, which follows the prefix, describes the reason for the negative punctuation.
Cleaning the IP reputation
Every email service administrator must determine policies for their clients and monitor the SPFBL rejection prefix in the MTA log files of the last seven days:
If using Exim, the administrator can find these records with the following command:
exigrep "5\.7\.1 SPFBL" /var/log/exim4/mainlog*
If using cPanel, the administrator can find these records with the following command:
exigrep "5\.7\.1 SPFBL" /var/log/exim_mainlog*
If any system that uses SPFBL receives too many e-mails/spams that generate rejections with this prefix, the administrator of the remote system must warn or ban his user who is sendung such spams. The goal is to avoid receiving new rejections with this prefix, which generate a negative point for each rejection.
Rejection may occur due to manual blocking. In this case, a URL will be sent within the message:
5.7.1 SPFBL BLOCKED
If the block is improper, you must start a release procedure. The release procedure, through the URL, depends on the recipient’s interaction. In this case, it is important that the sender contacts the recipient by another means of communication, to warn him that he has been improperly blocked by the anti-spam system and will start the release process. Once started, the recipient will receive a system email:
The sender 'firstname.lastname@example.org' wants to send you messages but was blocked by the SPFBL system as being a source of SPAM.
If you trust this sender and want to receive his messages, please go to this URL and solve the reCAPTCHA:
If the recipient completes this procedure, the system will remove any block that prevents messages from being accepted and will register the sender on the recipient’s whitelist, so that the recipient’s MTA will accept any message from that sender destined to that same recipient.
How to identify future spamtraps
The disabled addresses are recorded as non-existent in SPFBL service, returning the following prefix:
All rejections with this prefix are the sign that the email address should be removed immediately from the contact list or from the email marketing list.
If the removal is not done, there is a risk that the fire service will be listed at SPFBL network because the address can be converted to spamtrap at any time. Strictly speaking, each email address is converted to spamtrap one year after its inclusion in the list of non-existent recipients. High volume of non-existent recipients can list IP too.
Although spamtrap addresses remain in some contact list, without the sender’s knowledge, there is a mechanism that simulates sender blocking by the intended recipient, who would actually be a robot and not a real recipient. This blocking is performed in a pseudo-random fashion so that it is not possible for the sender to find out which addresses are from real recipients or what are spamtraps. If automatic spamtrap blocking is performed, the sender should treat the case exactly as if it were a real recipient and remove its address from the contact list, as it would actually be removing spamtrap without realizing it.
Invalid sender identification
In cases where the e-mail service does not have FCrDNS validation, and at the same time there is no sender validation by SPF, messages may be rejected with the following message:
5.7.1 SPFBL invalid sender indentification.
Just fix the FCrDNS or correct the sender’s SPF so that messages will be accepted as normal.
Security features not supported
Sometimes the MTA will not accept security features, like STARTTLS or AUTH, so the persistence of attempting these commands can cause reputation problems. All not accepted security features will be rejected as enhanced prefix code 5.7.4.
If your MTA receives a rejection for STARTTLS command, you must fix your MTA to not try to use this command when the EHLO command not answer this command as a choice:
5.7.4 SPFBL TLS not available.
If your MTA receives a rejection for AUTH command, you are doing this very wrong or most probably you’re looking for system vulnerabilities:
5.7.4 SPFBL authentication not supported.
In this last case, your MTA will be blocked immediately.
Feedback by ARF sending
All newer SPFBL instances are prepared to send Abuse Reporting Format (ARF) for administrators of each email service. For this service to work properly, the DNS Abuse List (DNSAL) technology is designed to determine which email address is responsible for each sending and email on the Internet.
If your company is interested in receiving ARFs from some instances of SPFBL, request a budget for inclusion of each IP range in our DNSAL. All new SPFBL instances are ready to query our DNSAL to determine which email address the ARF should be sent to.