Strategies for protecting IMAP (e.g. MFA)

[Arjen de Korte]

Citeren Benny Pedersen <me at junc.eu>:

> On 2021-11-14 20:26, Matthew Richardson wrote:
>> On Sun, 14 Nov 2021 08:12:53 -0800, Michael Peddemors wrote:-
>>
>>> And there are RBL's now for know IP(s) used by IMAP hackers, including
>>> SpamRats RATS-AUTH that can assist in reducing those attacks.
>>
>> Looking at https://www.spamrats.com/rats-auth.php the "Example Usage in
>> Dovecot" says "PLEASE UPDATE".
>>
>> How would one use a DNSBL like this in Dovecot to reject IMAP connections
>> from listed IPs?
>
>  submission inet n       -       y       -       -       smtpd
>       -o smtpd_tls_security_level=encrypt
>       -o smtpd_sasl_auth_enable=yes
>       -o smtpd_delay_reject=no
>       -o { smtpd_client_restrictions = reject_rbl_client  
> auth.spamrats.com=127.0.0.39, permit }
>       -o { smtpd_relay_restrictions = permit_mynetworks,  
> permit_sasl_authenticated, reject }

This is not an answer to the question, this is Postfix syntax.

> openRelay, dont do it

In what way would this create an open relay exactly? The 'permit' at  
the end of the 'smtpd_client_restrictions' only means that the client  
is accepted, not that other smtpd restrictions are lifted.

> resolved version
>
> submission inet n       -       y       -       -       smtpd
>       -o smtpd_tls_security_level=encrypt
>       -o smtpd_sasl_auth_enable=yes
>       -o smtpd_delay_reject=no
>       -o { smtpd_relay_restrictions = reject_rbl_client  
> auth.spamrats.com=127.0.0.39, permit_mynetworks,  
> permit_sasl_authenticated, reject }

Although syntactically correct, it is confusing at best to put client  
restrictions in another place than smtpd_client_restrictions.  
Especially with 'smtpd_delay_reject=no' in effect you'd only reject  
after receiving 'RCPT TO', which is evaluated after  
'smtpd_client_restrictions' and 'smtpd_helo_restrictions' during the  
SMTP transfer.

> order do matter

Indeed.