Re: [perpass] draft-josefsson-email-received-privacy

[[e-mail]]

> >> stolen is a privacy problem, this is not a simple question, and any
> >> simple answer is wrong.
> >
> > Agreed.  I'm merely concerned that if we can't come up with a solution
> > to having someone's bank account credentials stolen, we shouldn't stall
> > attempting to resolve smaller problems that we can identify, such as a
> > privacy violation in the Received header.

> I hope you agree with the part where I said that any simple answer is
> wrong.

I certainly do.

> On my system, most real mail comes from the three gorillas, from ISPs such
> as T-W and Comcast, and from local schools or businesses.  Since we are
> weenies, a certain amount comes through mailing lists.  In every one of
> those cases, the IP address in the received header is the address of the
> server at the mail system, the institution, or the mailing list.  It tells
> you nothing you didn't already know if you looked at the bounce address in
> the SMTP envelope, or the From: or List-ID: in the message body.

As I understand it the argument here is that these IP addresses may expose
internal network topology - IMO even if a legitimate concern not a personal
privacy issue and hence out of scope - or perhaps might be usable in some sort
of correlation attack aimed at determining the user's general location. The
latter, even if it's in the remote realm of possibility, is not something
that's going to come close to passing cost/benefit muster.

> The spam mostly comes from compromised servers and botnets, where the IP
> tells you who the legitmate operator is (not the botnet operator) and
> indirectly where to send abuse reports.  Since that mail isn't sent by the
> party legitimately associated with the IP, and the only place the mail
> goes is back to the operator in a spam report, it's hard to see any
> privacy issues there, either.

Agreed.

> If you were talking about Received headers added in submission rather than
> SMTP, there are plausible PII issues, but there you will find that as
> often than not the sending MTA already obscures the location of the user,
> particularly when messages are submitted via webmail.  On the other hand,
> for abuse management it's essential that it be there in some form so the
> sending system can figure out which of its users is misbehaving or has
> been compromised.

I actually did a little checking of this the other day, and found the
following:

Gmail:   webmail does not disclose originating client IP, apparently using
         invalid Received: field to avoid doing so
         submit discloses originating IP
Yahoo:   Neither webmail nor submit disclose originating IP, some Received:
         fields are invalid but this looks like an unrelated issue
Outlook: Neither webmail nor submit disclose originating IP, valid Received:
         fields
AOL:     webmail discloses originating client IP, can't test submit due to AOL
         brokenness
GMX:	 Both webmail and submit dislose originating client IP

I'm fairly sure that in the past there were more cases where original client
IPs were exposed. So what we're seeing is an industry that looks to already on
the way to addressing this concern, albeit in a fairly haphazard manner.

> So I think it is fine to look at the issues and see where we might make
> improvements, but it is a bad idea to rush to naive changes that don't
> address real privacy issues but do cause real problems for operations and
> security.

Agreed again.

				Ned