[Mimedefang] GMail (was Re: stripping Received headers based on authentication)

[Jan-Pieter Cornet]

Op 17 feb 2010, om 20:47 heeft David F. Skoll het volgende geschreven:
> You and Gmail are the only ones with this interpretation.

And me too.

What I find lacking in this discussion is the reason why google would  
do this. And I think I know why, because I'm tempted to do the same,  
at least for some recipients...

> For tracing purposes, it is desirable (I would say mandatory) to track
> the flow of email across this interface.

Precisely. And here also lies the problem, as some receivers start  
rejecting email based on the contents of IP addresses found in the  
Received headers, based on questionable IP reputation lists.

We have customers complaining to us that some other big (local, dutch)  
provider rejects all of their email. But if they send mail via gmail,  
it works fine, "so it must be xs4all's problem" (ie: my problem),  
according to the customer. Somehow, the IP address of a customer ended  
up on a reputation blacklist, possibly because of a virus infection  
somewhere in the past. A blacklist that is not easily queried even,  
and the remote mail server gives a very unhelpful "550 Message  
rejected".

Provided the email was received as authenticated SMTP, scanned for  
spam, and the sender/IP checked for clean email behavior (not sending  
too much mail, causing too many bounces, etc), then my interpretation  
of what email is "legit" versus what email is "spam", is probably  
better than the flaky deep-header-inspecting reputation list of the  
receiver, and I'd be tempted to remove or hide the real origin of that  
message, at least for specific receiving ISPs (we're not doing  
anything like that yet, though, that would really directly go against  
the RFC).

I believe that that's the motivation why google hides the remote HTTP  
address (blaming privacy seems very silly in light of Eric Schmidt's  
recent remarks). There are probably too many receivers out there that  
have rules like "oh, it was submitted via webmail from Nigeria, it's  
junk". It could be that gmail is actually better at detecting spam  
than just applying blanket blocks to entire countries, and these  
'random blocking based on submitting IP' occurred more often than  
outgoing spam was getting through the gmail defenses. So, it was a  
source of queries to the gmail support department that was easily  
'fixed' (do they even have a support dpt? I dunno...)

> Generally speaking, between an X client and an X server, or between an
> SSH client and an SSH server, there is not an interface between two
> administrative domains.  So apart from the fact that the SMTP gateway
> *cannot* report the client's IP, there's *no need* for it to do so.
> (If people started offering public-access Pine-over-SSH or
> public-access Thunderbird-over-X, I would change my position.)

We offer just that (well, pine/mutt over ssh), at least, it requires  
that you sign up for a monthly fee. Do note that although all of our  
customers get this ability for free, only about 1% ever use it.

Our pine/mutt installations do not include an X-SSH-Connected-from:  
header :)

> It's not whimsical at all.  Google is suppressing critical information
> showing the flow of email from one administrative domain to another.


How so? It's being sent by a gmail subscriber, via the gmail system.  
Seems like the same domain to me :) (OK, I admit, now I _am_ teasing  
you, I know what you meant :)

I'm sure the information on the submitting IP isn't lost (hah, google  
and deleting data??!), it's just not publicly available. Google will  
surely dish up the info if they get abuse complaints. (... or a visit  
from the feds. Or a request from a big law firm. Or a request from any  
law enforcement agency anywhere on earth. Even from China or Pakistan.)

-- 
Jan-Pieter Cornet <johnpc at xs4all.nl>
"People are continuously reinventing the flat tyre".