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 <[email protected]>
"People are continuously reinventing the flat tyre".
_______________________________________________
NOTE: If there is a disclaimer or other legal boilerplate in the above
message, it is NULL AND VOID. You may ignore it.
Visit http://www.mimedefang.org and http://www.roaringpenguin.com
MIMEDefang mailing list [email protected]
http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
