Recipient filtering means that the forward server sends a response to the seppmail.cloud when a mail is transmitted, stating that an invalid recipient does not exist.

Sections on this page:

anchor link Advantages of activated receiver filtering

  • More accurate billing of users, no fee-based issuing of certificates for non-existent users.
  • Prevent backscatter (harassment of uninvolved parties through error messages), which can lead to entries in block lists or impair the reputation of the sending server.

anchor link Configuration options in Exchange

Most mail servers already give a clear response after RCPT TO if a mail recipient does not exist.

(C1) However, Exchange accepts all recipients by default and then sends a bounce message to the sender. As senders are easy to forge, unnecessary error messages can be sent to forged but uninvolved senders.

(C2) By adjusting the configuration, Exchange can also provide appropriate feedback on the time of transmission. Since Exchange 2013, however, this only takes place by default once the message has been fully transferred (END OF DATA). Although this already improves the situation, just as with the standard behaviour, there is still an unnecessary waste of bandwidth and computing time for mail processing.

(C3) Unfortunately, the Exchange frontend does not allow a better configuration. The only way to optimise recipient filtering in accordance with RCPT TO is to change and expose the Exchange backend to the seppmail.cloud.

From the point of view of seppmail.cloud, C1 represents a gross misconfiguration and jeopardises the reputation of the cloud outbound servers and is therefore not permitted when using SC-OUTBOUND.

C2 is acceptable if it can be demonstrated why C3 cannot be realised.

anchor link Procedure for activation in Exchange 2013 and higher (on-premises)

C2 can be achieved by activating recipient filtering in the Exchange backend. The configuration can be activated via Powershell with the following commands:

 

Set-RecipientFilterConfig -Enabled $true -RecipientValidationEnabled $true
 
Get-AcceptedDomain | Set-AcceptedDomain -AddressBookEnabled $true
 
Set-RecipientFilterConfig -RecipientValidationEnabled $true

 

For C3, the incoming mail traffic from the seppmail.cloud then has to be redirected from port 25 to port 2525 of the Exchange server. This can be achieved, for example, by a corresponding NAT rule on the firewall. For the full description, see the SEPPmail Secure E-Mail Gateway documentation.

anchor link Procedure for activation in M365

Documentation at Microsoft: Microsoft Exchange documentation: use directory-based edge blocking

anchor link Procedure for activation with other mail servers/hosting providers

Please consult the manual or the support of your product.

anchor link Checking the implementation

The success of the implementation can be checked using the SMTP Tester of the seppmail.cloud.

anchor link Behaviour of seppmail.cloud

The seppmail.cloud checks the existence of recipient addresses based on SMTP requests. If recipient filtering according to RCPT TO is active (C3), exact entries for both existing and non-existing users can be created in the cache. The entries for existing users are valid for 7 days, for non-existing users for 4 hours.

If recipient filtering is only active after END OF DATA (C2), it can only be recognised on the basis of the SMTP error messages of the target server whether a user is invalid. In this case, only entries for non-existent users with a validity of 3 days can be created.

If no recipient filtering is active (C1), it is only possible to guess which users do not exist based on the bounce message sent. In this case, only negative entries with a validity of 7 days are created.

In the case of C1 or C2, a positive entry of a test address with a validity of one hour may be visible.

If a mail is sent again to an invalid address for which there is already an entry in the cache, the message is rejected with the error message "previously cached response" followed by the original error message of the target server (C2+C3) or with a generic message "User unknown or bouncing" (C1). This prevents in case of repeated delivery attempts to invalid addresses that an address check or final delivery (as well as a bounce in the case of C1) is performed for each delivery attempt. This also saves resources on the target server and is part of our in-built denial of service protection measures.

Incorrect or no longer correct entries can be removed manually at an early stage via the seppmail.cloud GUI under User Management > CA Recipient Cache.