X Headers use Primary Hostname
I have a question about the headers:
X-AntiAbuse
X-Get-Message-Sender-Via
X-Authenticated-Sender
It appears that these use the primary hostname even when mail is sent through a domain that has a dedicated IP. Why doesn't exim use the hostname of the dedicated IP to form these headers instead of the hostname of the primary server?
It seems like there are still a couple of places where exim still hasn't fully incorporated support for smarthosts / dedicated IPs. Some I was able to 'fix' with advanced configuration tweaks to variables, but these headers seem much harder to correct.
Has anyone found a way to fix this?
And is there work being done to better support dedicated IP accounts that don't want to bleed information about the host they live on?
-
Hello @Volox, Can you confirm that you've followed the steps documented on the link below? How to Configure the Exim Outgoing IP Address - cPanel Knowledge Base - cPanel Documentation If so, can you verify if the email was sent out via SMTP authentication as opposed to from a PHP script using the PHP Mail function? Thank you. 0 -
Yes, the mailhelo and mailips files are configured and the appropriate selections made in the cpanel configuration. I can see in the Received header of the email at gmail that the correct outbound server name and IP address (the ones associated with the dedicated IP of the particular account) were used to send the email. The email was sent out via SMTP authentication and I can see in my Received header that the authenticated user and the server that was connected to in order to send the email were both associated to the domain that I would expect. However the X headers show the primary server name (base name of the server) instead of showing the server name and domain that the email was sent through. 0 -
However the X headers show the primary server name (base name of the server) instead of showing the server name and domain that the email was sent through.
Here's the entry in /etc/exim.pl that's adding the hostname to the X-AntiAbuse line in the header:sub mailtrapheaders { $primary_hostname ||= Exim::expand_string('$primary_hostname'); my $original_domain = Exim::expand_string('$original_domain'); my $sender_address_domain = Exim::expand_string('$sender_address_domain'); my $originator_uid = Exim::expand_string('$originator_uid'); my $originator_gid = Exim::expand_string('$originator_gid'); my $caller_uid = Exim::expand_string('$caller_uid'); my $caller_gid = Exim::expand_string('$caller_gid'); my $headers = "X-AntiAbuse: This header was added to track abuse, please include it with any abuse report\n" . "X-AntiAbuse: Primary Hostname - $primary_hostname\n" . "X-AntiAbuse: Original Domain - $original_domain\n" . "X-AntiAbuse: Originator/Caller UID/GID - [$originator_uid $originator_gid] / [$caller_uid $caller_gid]\n" . "X-AntiAbuse: Sender Address Domain - $sender_address_domain\n" . check_mail_permissions_headers() . "\n"; if ( file_exists('/etc/eximmailtrap') ) { my $xsource = $ENV{'X-SOURCE'}; my $xsourceargs = $ENV{'X-SOURCE-ARGS'}; my $xsourcedir = maskdir( $ENV{'X-SOURCE-DIR'} ); $headers .= "X-Source: ${xsource}\n" . "X-Source-Args: ${xsourceargs}\n" . "X-Source-Dir: ${xsourcedir}"; } return ($headers); }
Exim document's the primary_hostname string on the document below: I believe the workaround noted on the following post is what you're looking for: There's also a feature request below you may want to vote and add feedback to to make this an easier task in the future: Thank you.0 -
I have already made the correction to smtp_active_hostname in a similar manner to the referenced post. I believe the problem with the way exim is creating the headers is with this part of the header: "X-AntiAbuse: Primary Hostname - $primary_hostname\n"
and probably similarly inside of: check_mail_permissions_headers() (from the code above I can only assume that is what creates the X-Get-Message-Sender-Via and X-Authenticated-Sender headers) If the smtp_active_hostname is set to machine1.rightdomain.com and the user being used to authenticate is user@rightdomain.com, then why would any header contain the $primary_hostname (which is machine.wrongdomain.com)? It would seem to me like $primary_hostname should be a variable that is used as a fallback and for the internals of exim and that headers should depend on values like smtp_active_hostname that allow for the host name to be set based on how exim is being connected to. The current code seems to defeat the multi-tenant / dedicated IP functionality. Although I like the feature request of using reverse DNS, I don't believe that would solve this problem since wouldn't that only fix the smtp_active_hostname default and / or smtp_banner and wouldn't address the primary_hostname variable that is getting used in these headers? The smtp_banner and the received header can both be fixed through a combination of changing how they are constructed and using a corrected smtp_active_hostname variable. The challenge here is that the Abuse headers are buried in code and so they cannot be easily changed to use the smtp_active_hostname variable. Since changing the primary_hostname variable that those headers use doesn't seem like a well advised idea, it seems like either the code should be 'fixed' or the formation of the headers should be bubbled up to a config entry that can be manipulated similar to the banner. If I'm missing something, please fill me in.0 -
The response I've gotten back so far is [QUOTE]The workaround would be to configure the "smtp_active_hostname" directive.
I've responded that I don't understand how that achieves a workaround since the headers are not set based on that directive. It sounds like this may end up being a feature request rather than a bug.0 -
Hello, To update, here's the feature request that originated from the support ticket: Change X Headers to allow for the host name to be set based on how exim is being connected to I'll leave this thread open so others that reach this thread can share more information about potential workarounds. Thank you. 0
Please sign in to leave a comment.
Comments
8 comments