View Issue Details

IDProjectCategoryView StatusLast Update
0017377phpList 3 applicationCampaign Send Processpublic18-01-21 21:27
ReporterElementGreen Assigned To 
PrioritynormalSeverityfeatureReproducibilityalways
Status newResolutionopen 
PlatformIntel Xeon CPU E5-2680 VPS HostOSUbuntu LinuxOS Version14.04
Product Version3.0.7 
Target Version3.5.0 
Summary0017377: Adding Received: header with HTTP web browser IP address is a privacy issue
DescriptionI was surprised to find my personal home broadband IP address embedded in the Received: headers of campaign emails. This seems like a pretty severe privacy issue, which users of phplist should at least know about.

Attached is a patch which adds a configuration option called ENABLE_HTTP_CLIENT_STAMP which enables this functionality (if someone wants it), but it should be disabled by default in my opinion. I can see how this type of thing makes sense for anonymous forms which send emails (what the link to the Spamcop page talks about) or for situations where the admins of the phplist can't be trusted entirely, but this is a system that is secured via a login so that is usually not the case. I don't wish to broadcast to the world my physical location, or at least would like to know that that is what is occurring, prior to doing so.
Steps To ReproduceSend a campaign email (with immediate mode)
Look at the headers and note the Received: header for the IP address of the HTTP client which sent the campaign
TagsConfiguration and sending

Activities

ElementGreen

09-09-14 20:41

reporter  

phplist-disable_http_client_stamp.patch (1,335 bytes)   
diff -ru phplist.orig/admin/class.phplistmailer.php phplist/admin/class.phplistmailer.php
--- phplist.orig/admin/class.phplistmailer.php	2014-09-09 12:11:39.000000000 -0700
+++ phplist/admin/class.phplistmailer.php	2014-09-09 10:20:18.000000000 -0700
@@ -142,7 +142,8 @@
 #        $this->addCustomHeader("Return-Receipt-To: ".$GLOBALS["message_envelope"]);
       }
       ## when the email is generated from a webpage (quite possible :-) add a "received line" to identify the origin
-      if (!empty($_SERVER['REMOTE_ADDR'])) {
+      if (defined('ENABLE_HTTP_CLIENT_STAMP') && ENABLE_HTTP_CLIENT_STAMP
+          && !empty($_SERVER['REMOTE_ADDR'])) {
         $this->add_timestamp();
       }
       $this->messageid = $messageid;
diff -ru phplist.orig/config/config.php phplist/config/config.php
--- phplist.orig/config/config.php	2014-09-09 12:12:27.000000000 -0700
+++ phplist/config/config.php	2014-09-09 12:11:15.000000000 -0700
@@ -34,6 +34,9 @@
 
 define("PHPMAILERHOST",'');
 
+# Enable adding a Received: header for HTTP client IP address in campaign emails
+# define("ENABLE_HTTP_CLIENT_STAMP",1);
+
 # if test is true (not 0) it will not actually send ANY messages, but display what it would have sent
 # this is here, to make sure you edited the config file and mails are not sent "accidentally"
 # on unmanaged systems

michiel

09-09-14 20:59

administrator   ~0054955

yes, interesting isn't it. We'd want this option when phpList is used for incorrect things, like spam, but not when we can be trusted and are sending correctly.

Tricky these kinds of things. I can totally understand not wanting to give out your home IP address to your entire subscriber base. In a way, you may not even mind your subscribers to see it, but you definitely don't want anyone else who can read the mails (which is more than you can imagine).

Obviously you figured out how to stop it. I'd be interested to raise this discussion in a wider audience to see if we want to make it a feature. I'd still opt to keep it ON by default.

Zbyszek

02-11-15 18:06

reporter   ~0057126

Especially interesting when one has dynamic rDNS at home.

Can make Spam Assassin a little bit angry at RDNS_DYNAMIC and DYN_RDNS_AND_INLINE_IMAGE.

bulgin

17-01-21 15:10

reporter   ~0063701

I think this is indeed a privacy issue and a feature should be added that allows users to toggle this on and off. As well, it certainly adds to a users' spam count and raises the possibility of being banned. It's also wrong - the ip address of the home user is not "sending" the email, it is "triggering" the send from a server-hosted account. Please consider changing this. Thank you.

michiel

17-01-21 17:06

administrator   ~0063702

You can use the remote processing service from phpList.com

https://www.phplist.com/createaccount

bulgin

17-01-21 17:20

reporter   ~0063703

Thanks Michael but doesn't that defeat the purpose for those who host their own server using the community version of phplist? As well, many users already have an ip address associated with their campaigns - and oftentimes with excellent standing (no spam reports) - so migrating to another service requires them to once again build trust and confidence in the system and to wait a long,long time for spam filters to recognize the sending ip as legitimate.

Seems to me that an option or plugin to turn off this what I consider to be a misconfiguration, would solve the issue, no?

Thanks again for your feedback.

bulgin

17-01-21 17:31

reporter   ~0063704

Forgot to mention, but directly related to this issue my server was identified as part of a RATS Dyna blacklist - a pretty significant entry for a server that has been operating for years unscathed by block lists. My tests have shown that when I send using process queu it goes into that list and when not sending via process queu, stays out. So something to consider in terms of severity.

michiel

18-01-21 09:17

administrator   ~0063705

The "remote processing service" will invoke the processqueue process from the phpList servers. It will still send via your own SMTP servers. It avoids having to run processqueue from your local system, which will avoid adding the header mentioned in this ticket to the mails. That will also avoid being on "Dyna blacklists".

You can set it up here: /lists/admin/?page=hostedprocessqueuesetup

Issues on blacklisting are complex and hard to analyse. Most data is anecdotal. It is probably the main reason to use a service instead of a self-hosted system.

bulgin

18-01-21 21:27

reporter   ~0063706

Thank you @michiel that looks like a usuable solution, although I know many are hesitant to allow_url_fopen. Thank you for the providing this.