The contact module needs to write the X-Originating-IP headers in the mail. Right now people obtaining the spam mail via a form on a site that they not administrating, have no other option than to disable the contact possibilities in the profile.

If the X-Originating-IP header were in the mail, it would be easier to file an abuse of the original IP address submitting the form.

Issue fork drupal-171886

Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

About issue forks

Comments

dave reid’s picture

dave reid
he/him
Primary language English
Location Nebraska USA
commented
Version: 5.x-dev » 8.x-dev
Category: task » feature

This is a feature request, so it can only be fixed in D8 now.

bertboerland’s picture

bertboerland commented

Feature request or not, it is *highly* needed and should have been in all contact / mail forms.

dave reid’s picture

dave reid
he/him
Primary language English
Location Nebraska USA
commented

Mail API is extendable and I'm sure you could write a small module to fill the need in the meantime.

twod’s picture

twod
Primary language Swedish
Location Sweden
commented

woukd also love to see this feature, we're getting a lot of mails that end up in spam folders and I think this header would help.

If there's a D6 (or D7) custom snippet to do this, I'd appreciate if someone could point me there. Meanwhile, I'll start experimenting with the API on my own and post my findings here if there are no objections.

deekayen’s picture

deekayen commented

I just threw this together. There were a few other modules which were needing similar functionality.

https://drupal.org/project/x_originating_ip

kjholla’s picture

kjholla commented
Issue summary: View changes

I have been working on a similar issue, but with version 6.30.

I have modified the contact.module file to introduce the following lines into the contact_mail function:

  switch ($key) {
    case 'page_mail':
      if (module_exists('antispam')) {
        $body = $params['message'];
        $name = $params['name'];
        $mail = $message['from'];
        if (antispam_api_cmd_spam_check() == 1) { //If antispam returns 1, then mail is SPAM
          $message['headers']['X-My-Spam'] = 'Yes';
        }
      }

Obviously, this assumes that you have the antispam module installed, which I do. Along with this, I use a custom procmail recipe on my email server to catch all emails with the X-My-Spam header and route them straight to the junk folder.

I know this isn't the ideal solution for this, but it works for me as of now.

Regards,
Kiran

andypost’s picture

andypost
he/him
Primary language Russian
commented
Version: 8.0.x-dev » 8.1.x-dev

Is this still needed?
there's a request object that have all headers

deekayen’s picture

deekayen commented

@andypost, I don't think having a request object with headers resolves this. The request, which I was hoping to see, would have the contact module add X-FORWARDED-FOR headers that email server admins could read - even if they have nothing to do with Drupal.

My 7.x module "resolves" it for 7.x, but it really just turns this thread into a question of resolving it in contrib or core. The argument for core would be because most admins probably aren't aware of the X-FORWARDED-FOR email header, why they would need it, or the fact that a contrib module would add it.

Or you could go the no-bloat-in-core route and say the 8.0 module ought to be upgraded to 8.1, and so on in perpetuity.

andypost’s picture

andypost
he/him
Primary language Russian
commented
Issue tags: +Needs issue summary update

@deekayen I think we can get this anytime in core (patch with tests) - 8.0 if this is a bug or 8.1 as feature

Is there's agreement that most of users will need that?

bertboerland’s picture

bertboerland commented

@andypost it is what is needed to catch spam by bots to scan mail (detect and flag mail from roque ip addresses) and what is needed by any sysadmin to take action against either the ISP (file an abuse) or block IP addresses. Not having this makes us very VERY bad net citizens...

andypost’s picture

andypost
he/him
Primary language Russian
commented
Version: 8.1.x-dev » 8.0.x-dev
Category: Feature request » Task

Looks that can be made BC way

Issue summary still needs update

andypost’s picture

andypost
he/him
Primary language Russian
commented

@all I think we need https://en.wikipedia.org/wiki/X-Originating-IP so issue need re-title

Originating IP |^X\-Originating\-IP:(.*)|mi The IP address of the computer on which the email originated.

function x_originating_ip_mail_alter(&$message) {
  $ip_address = \Drupal::request()->getClientIp();

  // the normal headers should be sufficient if it's originating from the
  // server anyway, so don't include a header for localhost 127.0.0.1
  if ($ip_address != '127.0.0.1') {
    $header = \Drupal::config('x_originating_ip.settings')->get('x_originating_ip_header');
    $message['headers'][$header] = '[' . $ip_address . ']';
  }
}

But I'm sure that should be \Drupal::requestStack()->getMasterrequest()->getClientIp()

bertboerland’s picture

bertboerland commented

I think we need both. One to catch proxys and one to catch the client. Also note https://www.drupal.org/project/x_originating_ip

andypost’s picture

andypost
he/him
Primary language Russian
commented

I'm pretty sure we need only one because "XFF" in smtp is account list but http supposes this as hosts

PS: would be nice addition to implement ban module integration for that somehow in follow-up

deekayen’s picture

deekayen commented
Title: Mail needs X-FORWARDED-FOR in headers to get spammers » Mail needs X-Originating-IP in headers to get spammers

X-FORWARDED-FOR is a HTTP header and doesn't belong in the SMTP transaction.

andypost’s picture

andypost
he/him
Primary language Russian
commented
Issue tags: +Needs beta evaluation

Looks this change can go only to 8.1

Version: 8.0.x-dev » 8.1.x-dev

Drupal 8.0.6 was released on April 6 and is the final bugfix release for the Drupal 8.0.x series. Drupal 8.0.x will not receive any further development aside from security fixes. Drupal 8.1.0-rc1 is now available and sites should prepare to update to 8.1.0.

Bug reports should be targeted against the 8.1.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.9 was released on September 7 and is the final bugfix release for the Drupal 8.1.x series. Drupal 8.1.x will not receive any further development aside from security fixes. Drupal 8.2.0-rc1 is now available and sites should prepare to upgrade to 8.2.0.

Bug reports should be targeted against the 8.2.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.6 was released on February 1, 2017 and is the final full bugfix release for the Drupal 8.2.x series. Drupal 8.2.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.3.0 on April 5, 2017. (Drupal 8.3.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.3.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.6 was released on August 2, 2017 and is the final full bugfix release for the Drupal 8.3.x series. Drupal 8.3.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.4.0 on October 4, 2017. (Drupal 8.4.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.4.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.4.x-dev » 8.5.x-dev

Drupal 8.4.4 was released on January 3, 2018 and is the final full bugfix release for the Drupal 8.4.x series. Drupal 8.4.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.5.0 on March 7, 2018. (Drupal 8.5.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.5.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.5.x-dev » 8.6.x-dev

Drupal 8.5.6 was released on August 1, 2018 and is the final bugfix release for the Drupal 8.5.x series. Drupal 8.5.x will not receive any further development aside from security fixes. Sites should prepare to update to 8.6.0 on September 5, 2018. (Drupal 8.6.0-rc1 is available for testing.)

Bug reports should be targeted against the 8.6.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.6.x-dev » 8.8.x-dev

Drupal 8.6.x will not receive any further development aside from security fixes. Bug reports should be targeted against the 8.8.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.9.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.7 was released on June 3, 2020 and is the final full bugfix release for the Drupal 8.8.x series. Drupal 8.8.x will not receive any further development aside from security fixes. Sites should prepare to update to Drupal 8.9.0 or Drupal 9.0.0 for ongoing support.

Bug reports should be targeted against the 8.9.x-dev branch from now on, and new development or disruptive changes should be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.9.x-dev » 9.2.x-dev

Drupal 8 is end-of-life as of November 17, 2021. There will not be further changes made to Drupal 8. Bugfixes are now made to the 9.3.x and higher branches only. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.15 was released on June 1st, 2022 and is the final full bugfix release for the Drupal 9.3.x series. Drupal 9.3.x will not receive any further development aside from security fixes. Drupal 9 bug reports should be targeted for the 9.4.x-dev branch from now on, and new development or disruptive changes should be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.9 was released on December 7, 2022 and is the final full bugfix release for the Drupal 9.4.x series. Drupal 9.4.x will not receive any further development aside from security fixes. Drupal 9 bug reports should be targeted for the 9.5.x-dev branch from now on, and new development or disruptive changes should be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

smokris’s picture

smokris
Location Athens, Ohio, USA
commented
Version: 9.5.x-dev » 10.1.x-dev
Issue summary: View changes

smokris opened merge request !3174

smokris’s picture

smokris
Location Athens, Ohio, USA
commented
Status: Active » Needs review

I've opened a MR that adds the X-Originating-IP header to emails sent via site-wide and personal contact forms.

smustgrave made their first commit to this issue’s fork.

smustgrave’s picture

smustgrave commented
Status: Needs review » Needs work
Issue tags: +Needs framework manager review, +Needs Review Queue Initiative

This issue is being reviewed by the kind folks in Slack, #needs-review-queue-initiative. We are working to keep the size of Needs Review queue [2700+ issues] to around 400 (1 month or less), following Review a patch or merge request as a guide.

Removing credit from myself for the rebase. The MR has a fetch error so seeing if the rebase shakes things loose.

This was previously tagged for issue summary update per #9 which still needs to happen.

Added framework manager if they have any input. Should this go through security?

Version: 10.1.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch, which currently accepts only minor-version allowed changes. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

quietone’s picture

quietone commented
Status: Needs work » Postponed

The Contact Module was approved for removal in #3476879: [Policy] Move Contact module to contrib.

This is Postponed. The status is set according to two policies. The Remove a core extension and move it to a contributed project and the Extensions approved for removal policies.

The deprecation work is in #3520460: [meta] Tasks to deprecate the Contact module and the removal work in #3520466: [meta] Tasks to remove Contact module.

Contact will be moved to a contributed project after the Drupal 12.x branch is open.

Version: 11.x-dev » main

Drupal core is now using the main branch as the primary development branch. New developments and disruptive changes should now be targeted to the main branch.

Read more in the announcement.

andypost’s picture

andypost
he/him
Primary language Russian
commented
Project: Drupal core » Contact
Version: main » 1.x-dev
Component: contact.module » Code
Status: Postponed » Needs work