Merge branch 'smriti-436679/documentation_change_for_incoming_emails' into 'master'

Docs for incoming email not following 2FA enforcement

See merge request https://gitlab.com/gitlab-org/gitlab/-/merge_requests/145106



Merged-by: Jon Glassman <jglassman@gitlab.com>
Co-authored-by: smriti <sgarg@gitlab.com>

doc/administration/incoming_email.md

@@ -161,6 +161,9 @@ If the sender's address is spoofed, the reject notice is delivered to the spoofe
 `FROM` address, which can cause the mail server's IP or domain to appear on a block
 list.
 
+WARNING:
+Users can use the incoming email features without having to use two-factor authentication (2FA) to authenticate themselves first. This applies even if you have [enforced two-factor authentication](../security/two_factor_authentication.md) for your instance.
+
 ### Linux package installations
 
 1. Find the `incoming_email` section in `/etc/gitlab/gitlab.rb`, enable the feature

doc/security/two_factor_authentication.md

@@ -107,6 +107,8 @@ Enforcement affects all [direct and inherited members](../user/project/members/i
 Access tokens are not required to provide a second factor for authentication because
 they are API-based. Tokens generated before 2FA is enforced remain valid.
 
+The GitLab [incoming email](../administration/incoming_email.md) feature does not follow 2FA enforcement. Users can use incoming email features such as creating issues or commenting on merge requests without having to authenticate themselves using 2FA first. This applies even if 2FA is enforced.
+
 ### 2FA in subgroups
 
 You can enable and enforce 2FA for individual subgroups in the same way as a top