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

From: "John R Levine" <[email-masked]>
Date: 28 Nov 2015 21:58:18 -0500

You might want to take a look at this proposed WG charter and send 
appropriate comments.  It looks to me actively harmful, for a variety of 
reasons including that tits proponents appear to be painfully unfamiliar 
with the realities of modern e-mail systems where 90% of the mail is spam, 
malware and phishes, and the main privacy threats to users are from the 
criminals sending the spam.

R's,
John
---------- Forwarded message ----------
Date: Thu, 26 Nov 2015 08:46:29
From: Alexey Melnikov <[email-masked]>
To: [email-masked]
Cc: Murray S. Kucherawy <[email-masked]>
Subject: [Shutup] Proposed Charter for the
     "SMTP Headers Unhealthy To User Privacy" WG

Hi,
I will repost updated charter proposal after a few more people join the mailing 
list, but in order to bootstrap the public discussion, here is the latest 
version.

I've used the version provided by Patrik Wallstrom and addressed private 
comments received from Murray Kucherawy. Other then fixing typos, he suggested 
to describe what is out of scope and he also asked to clarify relationship with 
DMARC WG which might be going in the opposite direction in regards to data 
minimization in the Received header fields. I also replaced "SMTP protocol" 
with "Email" in a couple of places where the former was not correct.

So the latest proposal is below:
--------------------------
Charter for SMTP Headers Unhealthy To User Privacy

Header fields in Email messages can reveal private information to an
observer that might be used for attacking an organization or an
individual.  The goal of this working group is to reduce the amount of
private information exposed by Email header fields through:

  * well-engineered improvements to the SMTP protocol and

  * guidance for SMTP implementors and deployments on
    privacy-preserving practices

Some examples of privacy-sensitive header fields:

SMTP [RFC5321] requires that each successive SMTP relay adds a
"Received" header field to the mail headers.  These fields are used for
audit and debugging of mail transmission, mail loop prevention, and as
input to spam detection algorithms.

However, Received header fields also leak address and timing information
that can expose user location, internal network operational details,
and inter-organizational peering arrangements that may not otherwise
be public knowledge and may increase risks to those users and
organizations.

Other header fields also contain sensitive information that is not
strictly needed for SMTP transport but are sometimes used for debugging,
such as comment fields in header fields like Mime-Version [RFC2045], or common
extension header fields like User-Agent, X-Mailer, etc.  Indication of a
specific Mail User Agent or toolchain may expose users to tailored
attacks.

When e-mail messages are end-to-end encrypted (e.g. PGP/MIME [RFC3156]
or S/MIME [RFC5751] multipart/encrypted messages), some header fields
expose substantial amounts of metadata that are not relevant or necessary
for functional SMTP service but are customarily expected by the recipient
of the mail, including Subject, From, To, Cc, References, and
In-Reply-To.  While some work has been done previously to specify
protection for these header fields in encrypted messages [RFC2634], these
solutions are not widely deployed and messages using them often have
interoperability and end-user UI/UX problems due to their structure.

The working group will prioritize privacy-preserving Email header field
minimization techniques that are interoperable with existing e-mail
deployments and that avoid unnecessary degradation of mail service and
user experience.

The working group with liaise with DMARC WG to make sure that changes
to email handling are compatible with DMARC or at least discuss cons and pros
of using DMARC with changes suggested in this working group.

The working group can discuss related work, but work on any items other
then the 3 listed below would require rechartering.

Work items:

  * draft-josefsson-email-received-privacy
  * https://modernpgp.org/memoryhole/
  * Privacy-preserving mail loop prevention

---

From: "Carl S. Gutekunst" <[email-masked]>
Date: Sat, 28 Nov 2015 19:34:12 -0800

On 11/28/2015 06:58 PM, John R Levine wrote:
> appropriate comments.  It looks to me actively harmful, for a variety 
> of reasons including that tits proponents appear to be painfully 
> unfamiliar with the realities of modern e-mail systems where 90% of 
> the mail is spam, malware and phishes, and the main privacy threats to 
> users are from the criminals sending the spam.

Gah.... just what I do not need. I've spent endless hours trying to 
explain to paranoid customers that the diagnostic value provided by 
Received fields far offsets any possible data leakage. Consistently, 
these are folks with the poorest understanding of the technology, making 
them hard to sway with technical arguments, but easy prey for "official" 
efforts like this.

I don't suppose there's any way for the chairs to just kill this thing?

<csg>

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Sun, 29 Nov 2015 11:16:50 +0100

It could be killed by establishing minimum standards for encryption, 
e.g. no crypto RFC without support for perfect forward secrecy.

That 
said, this proposal sounds as if it will sink on its own. The very 
point of it is to hide intimation from a set of parties that includes 
the spam filter. Considering that problem and the abysmal adoption of 
PGP-based tools, I see no future for this.

Arnt

---

From: John C Klensin <[email-masked]>
Date: Sun, 29 Nov 2015 10:24:57 -0500

--On Saturday, November 28, 2015 7:34 PM -0800 "Carl S.
Gutekunst" <[email-masked]> wrote:

>> You might want to take a look at this proposed WG charter and
>> send  appropriate comments.  It looks to me actively harmful,
>> for a variety  of reasons including that tits proponents
>> appear to be painfully  unfamiliar with the realities of
>> modern e-mail systems where 90% of  the mail is spam, malware
>> and phishes, and the main privacy threats to  users are from
>> the criminals sending the spam.
> 
> Gah.... just what I do not need. I've spent endless hours
> trying to explain to paranoid customers that the diagnostic
> value provided by Received fields far offsets any possible
> data leakage. Consistently, these are folks with the poorest
> understanding of the technology, making them hard to sway with
> technical arguments, but easy prey for "official" efforts like
> this.
> 

So far, this is just a mailing list, with its proponents
seemingly to actively push the idea/proposal.  I certainly
didn't notice "consider the harm it would cause and whether
there are any real privacy benefits to offset it and then figure
out whether this is a good idea" as part of either the draft
charter for a WG or the description of the mailing list.

IMO, the IETF seems to be suffering from two patterns of late
that interact with this:

(1) All one has to do to get approval and resources for an idea
in various quarters is to say "need to improve privacy" in
appropriately enthusiastic tones.  Whether the idea would
actually accomplish that to any significant degree, much less
whether it would outweigh the operational harm it would cause,
seems to be irrelevant.

(2) "We worked very hard" is equivalent to "this deserves the
next step and all the community can do is fine-tune, not say
'no'".  The applies to "can we have a mailing list", "given the
mailing list, can we have a WG", and "given the WG and a few
documents, can the work be advanced to standards track" (where,
in each case, "can we" might accurately be replaced by "we are
entitled to".

If one wants this killed, one possibility is that, , as Arnt
suggests, it will be an exception to (2) and will just
self-destruct.    Otherwise, I see two possible (and compatible)
options:

(i) Tell the Nomcom, as loudly and clearly as possible, that any
AD who has been part of either of the patterns above should be
retired and candidates evaluated on the basis of whether they
will contribute to those patterns or push back against them.
Remind them that there is nothing in the BCPs that allows them
to stop paying attention to input after some cutoff that they
established, especially when that input is linked to unfolding
events in the community.

(ii) Appeal the decision to grant this effort a mailing list and
to encourage them to develop a charter.    I won't initiate such
an appeal, but would be happy to join in and help draft if
others wanted to.

Or one can sit and wait and try stopping the juggernaut after it
has acquired the momentum and level of investment that leads to
pattern (2) above.

      john

---

From: John C Klensin <[email-masked]>
Date: Sun, 29 Nov 2015 10:40:36 -0500

--On Sunday, November 29, 2015 11:16 AM +0100 Arnt Gulbrandsen
<[email-masked]> wrote:

> It could be killed by establishing minimum standards for
> encryption, e.g. no crypto RFC without support for perfect
> forward secrecy.

But the enthusiastic support for "opportunistic encryption",
which sometimes seems to translate as "even poor encryption is
more protective of privacy than none", probably kills off any
such minimum standards.

> That said, this proposal sounds as if it will sink on its own.
> The very point of it is to hide intimation from a set of
> parties that includes the spam filter.

One could hope that issue, together with 

	"The working group will prioritize privacy-preserving
	Email header field minimization techniques that are
	interoperable with existing e-mail deployments and that
	avoid unnecessary degradation of mail service and user
	experience."

(from the draft charter) would kill it, but I note that even
that charter statement doesn't say "proposals that would degrade
mail service or not interoperate with existing deployments are
showstoppers".

> Considering that
> problem and the abysmal adoption of PGP-based tools, I see no
> future for this.

See above.  It does not appear to me to assume or need PGP-based
(or S/MIME, etc.-based) tools.   Given the draft charter says
"liaise with DMARC..." and the enthusiasm around opportunistic
encryption with DANE-based keys, "no future" doesn't imply "no
standard and pressure to adopt it".

    john

---

From: Chris Newman <[email-masked]>
Date: Sun, 29 Nov 2015 09:12:20 -0800

I oppose the current shutup charter text and draft-josefsson-email-received-privacy as both promote the elimination of mechanisms that protect users from fraud and abuse.

As I do care about user privacy, here's a strawman charter that I would support:

====
This WG will investigate mechanisms to conceal the information exposed by the submission client's IP address in the mandatory received header generated by the submission server. The output of this WG will provide a mechanism as effective at tracing abuse and fraud as current use of the submission client's IP address. Changing other rules related to received headers in SMTP is out of scope for this WG.
====

I believe RFC 2442 combined with PGP or S/MIME adequately protects email headers. I worked on an implementation of that in the 1990s. I'm doubtful the memory-hole proposal is sufficiently better or sufficiently likely to deploy to be worth IETF effort.

		- Chris

---

From: Dave Crocker <[email-masked]>
Date: Sun, 29 Nov 2015 09:25:47 -0800

On 11/29/2015 9:12 AM, Chris Newman wrote:

> ====
> This WG will investigate mechanisms to conceal the information exposed
> by the submission client's IP address in the mandatory received header
> generated by the submission server. The output of this WG will provide a
> mechanism as effective at tracing abuse and fraud as current use of the
> submission client's IP address. Changing other rules related to received
> headers in SMTP is out of scope for this WG.
> ====

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.

d/
-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: "John Levine" <[email-masked]>
Date: 29 Nov 2015 18:13:46 -0000

>and information disclosure.  Privacy vs. ops support.

It's not even privacy vs. ops support, it's privacy issues via some
hints of sender's location vs. privacy issues via the recipient
getting spammed, phished, and malware'd.

You are completely correct that there's been no discussion at all of
the tradeoffs.  After all, the vast majority of mail these days is
malicious, and the largest mail provider in the world already redacts
most senders' location info.

R's,
John

---

From: Alexey Melnikov <[email-masked]>
Date: Sun, 29 Nov 2015 18:34:46 +0000

Hi Chris,

> On 29 Nov 2015, at 17:12, Chris Newman <[email-masked]> wrote:
> 

I think this is a very reasonable counter proposal.

To address concerns from other people it might be worth tweaking it, so that if after investigation no reasonable proposal can be produced, the group should produce a document describing why the problem is not tractable or not worth solving considering tradeoffs.

> I believe RFC 2442 combined with PGP or S/MIME adequately protects email headers. I worked on an implementation of that in the 1990s. I'm doubtful the memory-hole proposal is sufficiently better or…

There might be more will to implement something this time around. Whether the memory-hole proposal is it, I don't know.

Best Regards,
Alexey

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Sun, 29 Nov 2015 19:45:19 +0100

I appreciate that shutup does not require PGP. What I meant is rather 
that when people who like PGP add PGP compatibility to something, the 
result dies without notable adoption. Perhaps it is merely coincidence? 
People talk about it in positive terms, there is political pressure on 
implementers, but approximately zero adoption.

I like Chris' strawman 
charter, but would prefer to see explicit goals and requirements, in 
the charter or an i-d. Not worsening the ability of spam filters to 
discriminate is a fine goal/requirement.

Arnt

---

From: Steve Atkins <[email-masked]>
Date: Sun, 29 Nov 2015 11:10:30 -0800

> On Nov 29, 2015, at 9:25 AM, Dave Crocker <[email-masked]> wrote:
> 

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.)

Cheers,
  Steve

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 29 Nov 2015 21:57:02 +0000

On 29/11/15 18:13, John Levine wrote:
>  the largest mail provider in the world already redacts

As I understood it, one of the possible outcomes of this
effort might be to document the kinds of redactions that
have been done so that others could do similarly.

I've no clue as to whether that'd result in a menu of "things
one can do," or if there are parts of that that may end up
as standards, but a good first step might be to document
what's been done already, esp if it's different in different
mail providers and if those variations have different impacts
elsewhere in the overall mail infrastructure.

Seems like the above would be a useful start anyway. (If
it's not been done already - there's no reason such stuff
absolutely has to be in an RFC.)

S.

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 29 Nov 2015 21:58:44 +0000

(Re-tx - there was an address typo in the earlier message)

S.

---

From: "John Levine" <[email-masked]>
Date: 29 Nov 2015 22:01:51 -0000

>have been done so that others could do similarly.

That would be OK as a second phase.  But we need to start by
understanding what would be worth redacting in the first place, and
what the costs of redaction are.  As noted many messages back, the
original draft charter mentioned IP addresses in SMTP Received
headers, but those generally reveal no persoanal or private
information.  And as Steve A noted, Gmail's sender address redaction
makes it harder to recognize spammers using their system.

R's,
John

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 29 Nov 2015 22:38:29 +0000

On 29/11/15 22:01, John Levine wrote:
> As noted many messages back, the
> information. 

I think the above depends on what addresses are put where and
whether or not those are redacted somewhere else. Or am I missing
something?

Which brings us back to what seems like the first step to me,
which is to document what is done, presumably by those who have
done stuff for what seemed like good reasons. I'd say the
debate as to efficacy might be better done after that. (I'm
assuming that some folks most interested in and knowledgeable
about privacy might not be up so to speed on current mail
practices and that the reverse may also be true to some extent.)

S.

---

From: Jim Fenton <[email-masked]>
Date: Sun, 29 Nov 2015 14:53:40 -0800

On 11/29/2015 09:12 AM, Chris Newman wrote:
> I oppose the current shutup charter text
> and draft-josefsson-email-received-privacy as both promote the
> elimination of mechanisms that protect users from fraud and abuse.

Agreed, and to be more specific:

The proposed charter speaks of Received header fields leaking address
information that can expose user location. Yes, they can. But, in
general, that information is essential to identifying spoofed header
fields: it's by tracing the chain of "from" addresses in Received header
fields that one can determine that someone is attempting to do something
fraudulent. Further, I don't have a lot of sympathy for organizations
that rely on the secrecy of their network topologies as an essential
security component. We're trying to increase the trust in email, not
reduce it.

There are users for whom their privacy is critically important, such as
press informants in totalitarian societies. There are many other ways to
determine their location (network monitoring coupled with a STARTTLS
downgrade attack, for one), and it would be harmful (potentially
life-threatening) if anyone thought that this would truly protect them.
They should be using something like SecureDrop and not using email at all.

draft-josefsson-email-received-privacy mentions the issue of senders'
locations appearing on mailing lists and in mailing list archives. I
have long felt that we are conflicted on whether the output of a mailing
list is a new message or the same as the one sent to the mailing list.
It usually has a different MAIL FROM address, and often has text added
to the message body, which I would think is enough of a change to make
it a new message. Yet the Message-ID and Received header fields are
preserved. I would think that an entire new message should be created,a
new Message-ID assigned, and DKIM signed by the mailing list's domain
(of course!). Only selected header fields would be transferred to the
new message. The original incoming header fields should be available
only to the list administrators, who deal with abuse issues.

What would the motivation be for anyone to implement any header privacy
improvements? There is far too much deployed infrastructure to get a
change to be made, absent a very strong business case. We could spend a
lot of time on this and not have it matter a bit.

I would support some work on the mailing list issue resulting in a set
of recommended practices, and possibly guidance on obscuring the source
IP address when an authenticated submission is made to an MSA. But
that's it.

-Jim

---

From: "John R Levine" <[email-masked]>
Date: 29 Nov 2015 17:54:39 -0500

>> As noted many messages back, the original draft charter mentioned IP 
>> addresses in SMTP Received headers, but those generally reveal no 
>> persoanal or private information.
>

The SMTP received header only shows the IP of the mail servers, not of the 
user.  In approximately 100% of cases, the location of the mail server is 
not interesting, and tells you nothing about the location of the user. 
For example, on your message to which I'm replying:

  Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6])
   by mail1.iecc.com ([64.57.183.56]) with ESMTPS (TLS1.2/X.509/AEAD) via
   TCP port 34923/25 id 563408838; 29 Nov 2015 22:38:49 -0000

That tells me that TCD's server is on TCD's network which is in Dublin, 
but it gives no hint whether you're on campus, at home somewhere in 
Ireland, or at a meeting on another continent.

> done stuff for what seemed like good reasons.

At this point, I'd like to see the intersection of what people are willing 
to do what what seems useful.  The stuff in the proposed shutup charter is 
presumably what someone's willing to do, but is unlikely to lead to 
anything useful.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail.

---

From: Jim Fenton <[email-masked]>
Date: Sun, 29 Nov 2015 15:01:36 -0800

On 11/29/2015 02:54 PM, John R Levine wrote:
>
> The SMTP received header only shows the IP of the mail servers, not of
> the user.  In approximately 100% of cases, the location of the mail
> server is not interesting, and tells you nothing about the location of
> the user. For example, on your message to which I'm replying:
>

Not 100%. Contrast that with the message I sent to the list a few
minutes ago:

Received: from v2.bluepopcorn.net (v2.bluepopcorn.net [IPv6:2607:f2f8:a994::2])
 (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
 (No client certificate requested)
 by ietfa.amsl.com (Postfix) with ESMTPS id 1551C1B3847;
 Sun, 29 Nov 2015 14:53:43 -0800 (PST)
Received: from [IPv6:2001:470:1f05:bfe:a06d:6a7c:4078:aebf]
 ([IPv6:2001:470:1f05:bfe:a06d:6a7c:4078:aebf]) (authenticated bits=0)
 by v2.bluepopcorn.net (8.14.3/8.14.3/Debian-9.4) with ESMTP id tATMrfPA024552
 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO);
 Sun, 29 Nov 2015 14:53:42 -0800

v2.bluepopcorn.net is my MSA; it also reported the IP address of my home
Linux machine, running Thunderbird, that I'm sitting directly in front of.

-Jim

---

From: "John R Levine" <[email-masked]>
Date: 29 Nov 2015 18:13:07 -0500

> Not 100%. Contrast that with the message I sent to the list a few

You're confusing SMTP and submission.

This is an SMTP received header, which tells us that you use 
v2.bluepopcorn.net to send mail from your bluepopcorn.net address, which 
doesn't strike me as much of a privacy leak.

> Sun, 29 Nov 2015 14:53:43 -0800 (PST)

This is a submission header.  It does indeed have an IP address, but all 
th address 2001:470:1f05:bfe:a06d:6a7c:4078:aebf tells anyone is that you 
use a v6 tunnel from Hurricane Electric, the endpoint of which can be 
anywhere.

> Sun, 29 Nov 2015 14:53:42 -0800

Chris Newman's short proposal addresses this in the cases where (unlike 
you) the IP tells you something about the location of the user.

Regards,

---

From: "Christian Huitema" <[email-masked]>
Date: Sun, 29 Nov 2015 15:02:57 -1000

On Sunday, November 29, 2015 12:54 PM, Jim Fenton wrote:
>
> There are users for whom their privacy is critically important, such 
> as press informants in totalitarian societies. There are many other 
> ways to determine their location (network monitoring coupled with 
> a STARTTLS downgrade attack, for one), and it would be harmful 
> (potentially life-threatening) if anyone thought that this would truly 
> protect them. They should be using something like SecureDrop and 
> not using email at all.

Uh, No. This is the classic "the other side of the boat is leaking too"
argument, coupled with a dollop of "no security is better than imperfect
security." Yes, there are many ways for metadata to leak. But that does not
mean that we should not plugs the leaks that we do know about.

The discussion so far shows that one hand many people believe that we are
disclosing too much metadata in mail headers, while many more believe that
the metadata disclosure is actually useful to fight various forms of abuse,
some of which may well compromise users' privacy. 

We also heard that some of the big providers have already unilaterally
decided to suppress some of the metadata, like the first hop address. So we
have at least one data point showing that not all metadata needs to be
preserved.

The "submission" hop may be a special case, but as Jim points out, mailing
lists may well another special case, for which some guidance would be
useful.

The concern about topology disclosure may or may not justify pruning some of
the metadata.

In short, it appears that there is enough concern and enough uncertainty to
justify working at least on an analysis document, and depending on the
outcome on a best practice document. Let's have this debate, and let's make
some progress on email privacy.

-- Christian Huitema

---

From: "Rolf E. Sonneveld" <[email-masked]>
Date: Mon, 30 Nov 2015 10:34:51 +0100

On 30-11-15 02:02, Christian Huitema wrote:
> decided to suppress some of the metadata, like the first hop address.

Can anyone share some information about which providers made which decision?

> So we

I fail to see the causality with the first sentence here: do you mean: 
the worlds e-mail ecosystem did not collapse, so this proves that not 
all metadata needs to be preserved?

> some progress on email privacy.

There has been done some work on this, which might be useful input to 
the discussion: see the report "Investigating the leakage of sensitive 
personal and organisational information in email headers" [1].

/rolf

[1] https://www.cs.ox.ac.uk/publications/publication9347-abstract.html.

---

From: Rich Kulawiec <[email-masked]>
Date: Mon, 30 Nov 2015 08:50:17 -0500

> here, targeting a specification is, in my view, not ready for prime time.

I find myself in strong concurrence with this, and will add/augment
it, if I might, by saying that in the contemporary environment, we rely
on header-carried information far more than we once did.

To explain: once upon a time, many mail system operators made at least
a good-faith effort to support the "postmaster" role address, and to
at least read -- if not answer -- messages sent there.  With the advent
of mega-providers, we've seen that disappear.  I happen to think that
this is unprofessional and unethical: one should never build something
that one isn't capable of running properly.  But my sentiments aside,
this is the reality we face.

And because we face it, we no longer operate in an environment where
queries to postmaster personnel will likely generate a response.  We're
left with either (a) figuring it out on our own (b) consulting other
email people and hoping one of them has already figured it out or
(c) trying to page someone via the mailop or nanog mailing lists.

The approach of "Hey, could you grep this message-id through
your logs and tell me what just happened?" is pretty much dead.
I find myself learning about and using as much header-carried
data as I can in order to diagnose problems, or -- in some cases --
to try to ascertain if a problem even exists or where it might be.
So to borrow a word from part of Dave's message that I elided,
I find this "premature".

Let me also add that John Levine isn't the only one who has used
heuristics derived from knowledge of local mail patterns to build
anti-abuse systems.  (See John's discussion in re how he handles
email from Cornell.)  I do that everywhere I go because it's an
extremely powerful approach, it scales, and it yields systems with
excellent FP/FN performance while using few resources.  It does
require having detailed knowledge of local inbound (and outbound)
traffic patterns, and it also requires using header information,
sometimes on a case-by-case basis.  (And this approach is quite
often tractable even if on first glance it doesn't appear so.
Most operations exchange the bulk of their email with relatively
few other operations.)

I'm thus less than sanguine about removing header information
without a very carefully considered discussion about what's there,
why it's there, how it's used (by humans and software) and what
the privacy implications, if any, are.

As an aside: I think this kind of approach is becoming more useful
by the day, as I'm firmly convinced that [most] message-body scanning
is becoming less useful by the day.

One other thing to factor in (not related to Dave's or John's points):

Many spammers-for-hire and other unethical mail system operators now
embed tracking links in their messages.  These are unique URLs keyed
to some tuple of {recipient address, message, etc.} and of course
their activation reveals recipient IP address, mail/web client version,
possibly recipient OS type/version, timestamp, etc.  This form of spyware
is becoming increasing pervasive, to the point where I think it's worth
noting that all the header redaction in the world (and all the on-the-wire
and message-body encryption) will fail to protect recipient privacy as
long as this technology is extent and as long as recipients insist on
using web-capable mail clients.

---rsk

---

From: "Derek J. Balling" <[email-masked]>
Date: Mon, 30 Nov 2015 08:55:46 -0500

On 11/30/2015 8:50 AM, Rich Kulawiec wrote:
> To explain: once upon a time, many mail system operators made at 
> least a good-faith effort to support the "postmaster" role
> address, and to at least read -- if not answer -- messages sent
> there.  With the advent of mega-providers, we've seen that
> disappear.  I happen to think that this is unprofessional and
> unethical: one should never build something that one isn't capable
> of running properly. But my sentiments aside, this is the reality
> we face.

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.
In fact, in some areas (like WHOIS database compliance) the IETF acted
very specifically to undermine my efforts.

The world is reaping what the IETF has sown, in this respect.

D

- -- 
I prefer to use encrypted mail. My public key fingerprint is FD6A 6990
F035 DE9E 3713 B4F1 661B 3AD6 D82A BBD0. You can download it at
http://www.megacity.org/gpg_dballing.txt

Learn how to encrypt your email with the E-Mail Self Defense Guide:
https://emailselfdefense.fsf.org/en/

---

From: "ComKal Networks" <[email-masked]>
Date: Mon, 30 Nov 2015 23:47:27 +0800 (WST)

Hi Rich,

> (c) trying to page someone via the mailop or nanog mailing lists.

Totally agree with you on the postmaster address, even the email
address(s) in the whois information can't always be relied on.

We do however live in the real world were many constantly
want what they want without thinking why they want what
they want, and having no regard for others outside there little
empires.

> So to borrow a word from part of Dave's message that I elided,

I think it's only the 'little' guy, or oldtimers like myself that
are still happy to help others when we can with diag
information from checking logs. I often use my logs first
because trying to extract header information from a 'normal'
email recepient isnt always easy. Though now I basically have
to keep header information for the Australian government that
shouldnt be such a big problem now.

> is becoming less useful by the day.

I have disabled general email body scanning except for
phishing and mismatching URL's on my server, to
many problems and false positives with general body
scanning.

> using web-capable mail clients.

I firmly believe that if you start removing the obvious forms of
header information, then those that need that information for
more than diagnostic reasons will simply do something that is
not so obvious and is easier to both overlook and hide in the
general body of the email. Another way of looking at it is dont
give the unethical mail system operator a reason to change
their MO, it only forces you the ethical operator to work harder
or faster to spot the next method of obfuscation, tracking. or
misdirection.

To me privacy is important in the body of an email, the headers
are no different than a physical email with an address and chain
of custody, though it goes without saying that all tracking except
the last server the email went through are not always 100%
trusted, the important of diagnostic information should never
be discounted.

Header information is also important for local anti-abuse
systems such as you and others mentioned, I use it for
manual additions to my servers filtering, others use it
to add to automated filtering systems, the more untainted
header information, the lower the false positive hits.

Cheers
Ian Manners

---

From: Ned Freed <[email-masked]>
Date: Mon, 30 Nov 2015 07:38:21 -0800 (PST)

> 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:

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:     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.

				Ned

---

From: "John Levine" <[email-masked]>
Date: 30 Nov 2015 16:26:03 -0000

>Can anyone share some information about which providers made which decision?

Please look at the list's archives, now available through a dandy new
search engine:

https://mailarchive.ietf.org/arch/search/?qdr=a&start_date=&end_date=&email_list=shutup&q=text%3A%28gmail%29&as=1

R's,
John

---

From: Randall Gellens <[email-masked]>
Date: Mon, 30 Nov 2015 09:29:10 -0800

At 2:53 PM -0800 11/29/15, Jim Fenton wrote:

>>  I oppose the current shutup charter text and 
>> draft-josefsson-email-received-privacy as both promote the 
>  Agreed,

Also agree.

>   and to be more specific:
>
>  The proposed charter speaks of Received header fields leaking 
> address information that can expose user location. Yes, they can. 
> But, in general, that information is essential to identifying 
> spoofed header fields: it's by tracing the chain of "from" 
> addresses in Received header fields that one can determine that 
> someone is attempting to do something fraudulent.

Very true.  It seems to me that every few years, proposals are made 
to effectively destroy 'Received' header fields without understanding 
how and why they are so useful.

>   Further, I don't have a lot of sympathy for organizations that 
> rely on the secrecy of their network topologies as an essential 
> security component. We're trying to increase the trust in email, 
> not reduce it.

Agree.  This is security through obscurity, and generally promoted by 
people who can't explain how it really helps.
>
>  draft-josefsson-email-received-privacy mentions the issue of 
> senders' locations appearing on mailing lists and in mailing list 
> archives. I have long felt that we are conflicted on whether the 
> output of a mailing list is a new message or the same as the one 
> sent to the mailing list. It usually has a different MAIL FROM 
> address, and often has text added to the message body, which I 
> would think is enough of a change to make it a new message. Yet the 
> Message-ID and Received header fields are preserved. I would think 
> that an entire new message should be created, a new Message-ID 
> assigned, and DKIM signed by the mailing list's domain (of 
> course!). Only selected header fields would be transferred to the 
> new message. The original incoming header fields should be 
> available only to the list administrators, who deal with abuse 
> issues.

This assumes that each mailing list has the best possible spam 
filtering and does the best possible job detecting forged header 
fields.  Since that isn't the case, we need to permit each mailing 
list subscriber to see how a message was sent to the list.

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
When I was younger, I could remember anything, whether it had
happened or not.                                --Mark Twain

---

From: Matthias Leisi <[email-masked]>
Date: Mon, 30 Nov 2015 20:17:52 +0100

> Am 30.11.2015 um 14:50 schrieb Rich Kulawiec <[email-masked]>:
> 

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)?

— Matthias

---

From: Martijn Grooten <[email-masked]>
Date: Mon, 30 Nov 2015 19:28:41 +0000

> getting spammed, phished, and malware'd.

We're actually pretty good at fighting various kinds of malicious email
and while I know headers like Received do play a role there, I'm not yet
convinced that their role is so fundamental that removing them, or
removing essential parts of them, would see these (proactive and
reactive) defenses collapse.

And I do actually think there is a privacy issue here and that we
shouldn't dismiss that right away.

However, I agree with others that the proposed charter seems a little
premature and that, to quote Dave Crocker, we ought to have "public
discussion about the technical aspects of this policy tradeoff" first.

Martijn.

---

From: Ted Lemon <[email-masked]>
Date: Mon, 30 Nov 2015 20:13:00 +0000

> Whose privacy are we trying to protect? Recipient or Sender? 

Yes.

> 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)?

Yes.   But you missed "passive listener," and also housemate of recipient.

Of course, we can't perfectly protect anybody's privacy.   But we can somewhat protect it.

--
Sent from Whiteout Mail - https://whiteout.io

My PGP key: https://keys.whiteout.io/[email-masked]