Weblog entry #26 for lee
See all weblog entries made by lee.
There are plenty on reasons people submitting authenticated mail via the submission (port 587) may not wish to expose their IP address to their mail recipient, which may in turn expose their location. And for mail going through an authenticated mail submission host, I don't believe there's a compelling diagnostic reason to pass it on.
It's possible to modify Exim so that these headers aren't passed on. If you already modify headers in your exim config you'll be familiar with the received_header_text option. On a fresh install you can find the current setting by running:
/usr/sbin/exim4 -bP received_header_text
Then modify the part that generates the "from" couplet in the trace-field by wrapping it in a condition that only runs if the variable "$authenticated_id" is not defined (authenticated_id is whatever is set by the relevent auth configuration - usually a username). This might be in a file such as "/etc/exim4/conf.d/main/10_local_recieved" in a split config. Shown in bold below:
received_header_text = Received: \
${if !def:authenticated_id {${if def:sender_rcvhost \
{from $sender_rcvhost\n\t}{${if def:sender_ident \
{from ${quote_local_part:$sender_ident} }}${if \
def:sender_helo_name \
{(helo=$sender_helo_name)\n\t}}}}}}by $primary_hostname ${if \
def:received_protocol {with $received_protocol}} ${if \
def:tls_cipher \
{($tls_cipher)\n\t}}(Exim $version_number)\n\tid $message_id${if \
def:received_for {\n\tfor $received_for}}
But is it RFC-legal? Ignoring the fact that the use is widespread (googlemail for example) RFC2821 section 4.4 states
The FROM field, which MUST be supplied in an SMTP environment, SHOULD contain both (1) the name of the source host as presented in the EHLO command and (2) an address literal containing the IP address of the source, determined from the TCP connection.
I consider mail submission (RFC4409) to not be an "SMTP environment" in this context so I don't consider this to violate this requirement. However, if I'm wrong, then it would be fairly simple to add in a from couplet padded with false data such as localhost or an RFC1918 address.
Note that this only removes the location from the Recieved: header generated by the submission server - the information may also exist in other parts of the header such as Message-Id: header, it depends on the MUA involved.
To refresh the Message-Id for submission mail, one method would be to use a system filter:
if $authenticated_id is not "" then headers remove "Message-Id" headers add "Message-Id: <submit.$message_id@$primary_hostname>" endif
Comments on this Entry
Maybe I'm just slow this evening...
[ Parent | Reply to this comment ]
Yes, I'm deliberately fiting my interpretation to a) what I consider the cleanest solution (i.e. doesn't involve using false information in a trace field) b) what is actually being implemented by many sites in the field.
[ Parent | Reply to this comment ]
Google have been criticized for not including the IP address information, but the criticism is because it makes it hard to block email from abusive IP addresses, not about whether the implementation is RFC compliant or not.
Although I suspect this is largely a matter of scale, if your users abuse the service you'll presumably stop them or educate them. GMail, I assume, has a lower admin to user ratio?
[ Parent | Reply to this comment ]
It may be going on between an MSA and an MTA, rather than between MTA's, but it is still SMTP, not, to quote Lee, "a separate, albeit SMTP compatible, protocol". That really is playing with words alittle too far in my view.
I don't have any strong feeling either way, but the explanations seem to be more to convince yourselves that you're not doing a "bad" (RFC-breaking) thing rather than just being honest about not really seeing the need to put your IP address in the headers... Go on, own up to it, you won't be punished ;-)
As for GMail, well, at it's heart it's a webmail service, and as such a whole different ballgame of the "what actually _is_ the client" argument -- which IP address would you stick in the header, the the IP from the users browser, or the IP of the server in google's cluster? There's no easy answer, as any answer will be both right and wrong, depending on which way you look at it...
Cheers.
(PS, I don't know if it's true, but I heard that Google have an army of half-height clone admin's running around...)
[ Parent | Reply to this comment ]
For as long as he polices it correctly, I don't suppose anyone else cares how his email gets to his mail server (carrier pigeon trained to type the message in at the console are fine), the RFCs are just clarifying what details each player should undertake for themselves. Specifically hiding internal network stuff by header rewriting is mentioned in RFC2476.
I appreciate IP addresses aren't easy to do at the server side of a web connection, I deal with a lot of websites at work. But I think the request was that Google make a "best effort" to return the IP address of the webmail client, or SMTP Auth client, as applicable.
I can't say GMail spam is much of an issue for me, but I understand the frustration with the big email players, if you end up on the wrong side of even a small weakness on their part, it is easy to drown in spam. A classic case of this was the AOL port 25 blocking, when even after AOLs strenuous efforts to stop spam, zombies at AOL were still responsible for nearly 20% of the spam we were getting because the spambot owners had coded around the incomplete port 25 block AOL had deployed.
[ Parent | Reply to this comment ]