Strategies for protecting IMAP (e.g. MFA)
Arjen de Korte
build+dovecot at de-korte.org
Mon Nov 15 11:52:22 UTC 2021
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.
More information about the dovecot
mailing list