Subject: Re: [ietf-smtp] [Shutup] Proposed Charter for the "SMTP Headers Unhealthy To User Privacy" WG (fwd)

From: Arnt Gulbrandsen <[email-masked]>
Date: Tue, 1 Dec 2015 09:36:49 +0000

Ned Freed writes:
> Gmail:   Webmail does not disclose originating client IP, apparently using
>         invalid Received: field to avoid doing so.

Invalid, how so?

I looked at one now, and the oldest Received contained "by", "with" and 
"id" received-tokens. 5322 says all received-tokens are optional, 5321 says 
that SMTP servers MUST add a "from" received-token, but that Received 
wasn't written by an SMTP server and 5321 3.7.2 explicitly allows other 
software to be different. 2476 says nothing.

What am I overlooking?

Arnt

---

From: Rich Kulawiec <[email-masked]>
Date: Tue, 1 Dec 2015 08:53:25 -0500

On Mon, Nov 30, 2015 at 08:17:52PM +0100, Matthias Leisi wrote:
> Whose privacy are we trying to protect? Recipient or Sender? 
> 
> And from whom are we trying to protect it? Sender (administrative
> folks)? Recipient (administrative folks)? The man in the middle (state-
> or non-state-actor)?

I think that these are vitally important questions to consider up-front,
well before we entertain any discussion about *how* to protect privacy.

And I think that when we consider them, we should do so with a healthy
dose of reality, e.g., we need to consider factors outside the scope of
email servers and email standards.  It would be more convenient to pretend
those don't exist, but it certainly won't yield useful results.

---rsk

---

From: Hector Santos <[email-masked]>
Date: Tue, 01 Dec 2015 12:56:27 -0500

On 11/29/2015 2:10 PM, Steve Atkins wrote:

>> Chris's approach is reasonable, but I fear it is premature.
>>
>> The foundational issue here is a trade-off between information hiding
>> and information disclosure.  Privacy vs. ops support.
>>
>> I've seen essentially no public discussions, here or anywhere else,
>> about the technical aspects of this policy tradeoff.
>>
>> Absent some community-based sense of the underlying technical issues
>> here, targeting a specification is, in my view, not ready for prime time.
>
> There are already providers who remove or falsify Received headers in
> order to protect their users, so there is also the opportunity to look at
> what is currently being done and the effects of it.
>
> As one example, Gmail is one of those providers. (They're also consistently
> the biggest source of B2B spam in my inbox.)

Good point.

We are also talking about "hiding."  How about conversion, gateways?

There was never any "law" that required local hosting storage formats 
to remain in IETF RFC mail format.  It can be a local proprietary 
format once the final destination has been reached, mail "screened" 
and made available for the user. Header stripping features were a 
normal consideration.

What was always most important to a gateway, storage design was the 
ability to communicate, reply back between heterogeneous mail systems.

-- 
HLS

---

From: Ned Freed <[email-masked]>
Date: Tue, 01 Dec 2015 09:51:49 -0800 (PST)

> What am I overlooking?

In my testing I saw the following sorts of fields:

(webmail)

Received: by lffz202 with SMTP id z202so35306770lff.3 for
 <[email-masked]>; Wed, 21 Oct 2015 22:32:47 -0700 (PDT)

(submit)

Received: by pasz6 with SMTP id z6so88255027pas.2 for <[email-masked]>;
 Thu, 22 Oct 2015 07:30:31 -0700 (PDT)

That sure looks like an SMTP server to me so RFC 5321 applies, and I don't see
a "from" clause in there.

				Ned

---

From: Hector Santos <[email-masked]>
Date: Tue, 01 Dec 2015 13:29:57 -0500

On 11/30/2015 10:38 AM, Ned Freed wrote:

>> Can anyone share some information about which providers made which
>> decision?
>
> I posted about this earlier on the perpass list in respose to the initial
> discussion of the draft-josefsson-email-received-privacy draft. Here's an
> updated version of that information:
>
>          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:     Both webmail and submit disclose originating client IP in both
>          Received: fields and X-Originating-IP: (webmail) and X-AOL-IP:
>          (submit) fields.
> GMX:     Both webmail and submit disclose originating client IP.
>
> Thanks John Levine for the AOL submit data.

Our system has a RFC MIME storage and local proprietary format.  The 
operator must enable a "Preserve MIME format" option on a per private 
mail user basis or a per mail conference type basis.  So out of the 
box, the mail is converted to a safe minimum text format.   But if not 
converted, our system is not doing anything to hide raw headers (if 
requested by MUA) and I don't know if it should (out of the box).  But 
as always, even if considered, it would be an local policy 
configuration option.

-- 
HLS

---

From: Rich Kulawiec <[email-masked]>
Date: Wed, 2 Dec 2015 07:37:35 -0500

On Mon, Nov 30, 2015 at 08:55:46AM -0500, Derek J. Balling wrote:
> Hey, I tried to help whip people into shape on that front, but got no
> end of shit from The Powers That Be about it, and so I gave up trying.

I know that you made this effort, and I'd like to say for the record
that I greatly appreciate it.  We would all be far better off if all
email providers (particularly the large ones) displayed an appropriate
level of responsibility and professionalism -- which, unfortunately,
NONE of them do.

---rsk