Contact forms using the alleged sender email as a Reply-To header are problematic with DMARC

Problem/Motivation

Starting 2024-02-01, Google and Yahoo are requesting DMARC policies which will reject invalid addresses/domains.

A problematic side-effect is that, with the recommended p=reject attribute, such messages will now trigger bounces from the site domains, assuming the email MX domain matches the site domain. In turn, this will degrade the deliverability properties of the sites, possibly preventing sites from emitting their normal transactional email.

This should initially only be a problem for sites sending more the 5k emails/day, but this is fairly common for sites using mailing lists on the primary domain.

In the case of contact module, this filtering is triggered by the use of the Reply-To header, which is being emitted on messages send to the configured destination, which is usually on the same domain as the site itself, triggering the deliverability degradations for the site domain.

This is done to make it easier for the user receiving the contact request to just use the Reply feature in their mail agent to reply to the request, but fails when a site is subject to volume submissions of blocked contact forms by automated agents able to work around captchas.

Set as "major" because Google and Yahoo are huge email providers and this policy just started being deployed last week, with a large blast radius potential for Drupal sites.

A good explanation of the policy issue and handling at https://dmarcian.com/yahoo-and-google-dmarc-required/

Steps to reproduce

1. set up a Drupal site on domain somedomain.tld
2. configure a domain with a DMARC record like "v=DMARC1; p=reject; rua=mailto:support@somedomain.tld; ruf=mailto:support@somedomain.tld; fo=1"
3. Configure the default contact form on the site to send to e.g. support@somedomain.tld
4. Log out of the site
5. Navigate to the contact form
6. Submit the form with a blocked email address like killoco1989@mail.ru
7. Observe how the receiver address does not receive the message, but receives a bounce notification instead

Proposed resolution

Modify the contact module so that use of the Reply-To header can be turned off. Possibilities include:

• Adding the reply address as another header like X-Drupal-Unsafe-Reply-Address
• Adding the reply address within the message body or subject
• Taking the above steps only for forms submitted by anonymous users, the reasoning being that authenticated users have non-blocked addresses or they would not be able to use the site in most scenarios

WORKAROUND: Until the issue is fixed, sites can alter the contact forms or hook the mailsystem to do similar changes in code.

Merge request link

TBD

Remaining tasks

Refine the initial design.

User interface changes

New configuration to be exposed.

API changes

Probably none.

Data model changes

Contact config entity configuration schema might change to include this header configuration.

Release notes snippet

TBD