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:24:14 +0000

Ned Freed writes:
> I have no idea what Google does, but I can assure you Received: 
> field analysis
> does play a role in spam filtering elsewhere. And even if it didn't, there's
> more to mail operations than spam filtering.

I think it might be helpful if someone would name or describe a largish 
site or service provider that uses Recived, and describe how in useful 
detail. "A spam/virus filter company that handles mail for about x million 
mailboxes does ...", that kind of thing.

Arnt

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Tue, 1 Dec 2015 12:27:03 +0000

Ted Lemon answers Dave Crocker:
>> IMO an essential design benefit in many/most aspects of Internet
>> technologies is avoiding making any more global assumptions (or
>> requirements) than essential.  "Deferring to the end systems" is a very
>> broad-based design requirement and it includes minimizing assumptions
>> about the transit infrastructure.
>
> Sure, but in this case wouldn't deferring to the end systems 
> argue in favor of allowing end systems to make the decision as 
> to whether their private information should be exposed?

As I see it, that's not the question here. The question is: Should there be 
an RFC that can be used/misused to apply pressure regarding trace fields 
etc?

The issue isn't whether person X chooses to add trace fields. The issue is 
whether person Y can shout at Z to not add or even mangle trace fields, 
with support from a document that looks official, substantial and 
authoritative, even though neither Y nor Z understand the nuances of RFC 
statuses.

Arnt

---

From: Paul Smith <[email-masked]>
Date: Tue, 1 Dec 2015 13:13:32 +0000

On 01/12/2015 12:27, Arnt Gulbrandsen wrote:
>> Sure, but in this case wouldn't deferring to the end systems argue in 
>> favor of allowing end systems to make the decision as to whether 
>> their private information should be exposed?
>
> As I see it, that's not the question here. The question is: Should 
> there be an RFC that can be used/misused to apply pressure regarding 
> trace fields etc?
>
> The issue isn't whether person X chooses to add trace fields. The 
> issue is whether person Y can shout at Z to not add or even mangle 
> trace fields, with support from a document that looks official, 
> substantial and authoritative, even though neither Y nor Z understand 
> the nuances of RFC statuses.
Once that document exists, then no one will add the trace fields, 
because people are paranoid (often rightly so, but not, I believe, in 
this case). They won't read the document fully. It may say 'you can 
remove IP address information from trace headers, but should think long 
and hard about it because doing so may come back to bite you and leaving 
the information in has minimal risk unless you're so stupid you haven't 
bothered with a firewall'. They'll get as far as the first comma, and stop.

To be honest, I'm (pleasantly) surprised IP address information is still 
put in Received headers nowadays. IMHO, the fact that it is suggests 
that there's a very good reason for it to stay there.

Many service providers and software publishers 'stretch' the rules 
somewhat, so if this was a big problem without any down-sides, then IP 
addresses would have disappeared from Received: headers some years ago.

If there were compatibility issues (eg some SMTP servers rejecting mail 
without the IP address info there), then that would still be a problem 
even if a new RFC comes out, unless SMTP is totally deprecated and a new 
mail standard replaces it. If there are no compatibility issues with 
removing the IP address, then why aren't most providers/systems already 
removing it nowadays?

---

From: Tony Finch <[email-masked]>
Date: Tue, 1 Dec 2015 14:05:48 +0000

Ted Lemon <[email-masked]> wrote:
> Monday, Nov 30, 2015 6:02 PM Dave Crocker wrote:
> > On 11/30/2015 2:51 PM, Ted Lemon wrote:

> >> Why would I be relaying mail on?  Only for a mailing list.
> >
> > The most obvious is mailbox aliasing, such as for vanity addresses such
> > as university alumni associations provide.
>
> That's a mailing list with one subscriber.   Same scenario.

Not really. Mailing lists have very different administrative behaviour to
aliases - they change the return path to an administrative address when
forwarding the message whereas aliases do not. RFC 5321 section 3.9.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
South Biscay, Southeast Fitzroy: Variable 4, becoming southerly 4 or 5.
Moderate or rough. Fair. Good.

---

From: "John Levine" <[email-masked]>
Date: 1 Dec 2015 14:54:52 -0000

>mailboxes does ...", that kind of thing.

AOL famously uses the second received header to filter mail from
providers that are too large to block but too lazy or incompetent to
do proper outbound filtering on their users' mail.

A few years ago, there was a largish cable ISP* that was gushing spam
from customers through their MTAs and ignored the complaints.  I forgt
whether it was bots, or just customers using desktop spam blasters.
So AOL started 4xx soft failing mail that originated at the naughty
customers, and the ISP's mail servers predictably melted down.  That
finally got their attention and the situation soon improved for
everyone, not just AOL.

R's,
John

* - I know who it was but since they've mended their ways there's no
need to embarass them here.

---

From: Dave Crocker <[email-masked]>
Date: Tue, 1 Dec 2015 06:56:50 -0800

> forwarding the message whereas aliases do not. RFC 5321 section 3.9.

Yes.  And further...

They typically also have very different formal -- that's meant as
'official', not 'math' -- semantics.

Alias behavior tends to be /very/ close to pure relaying.  It changes
very little in the message, other than the rfc5321.Rcpt-To address.

Mailing lists tend to make massive changes to the original message; they
are taking formal delivery of the message and then post a new message.
For end users, the view is of a single message from original author to
final recipient.  To the email infrastructure it is two (or more)
post/deliver sequences.

Folks seeking to discuss email at this level should consider becoming
familiar with RFC 5598.  It will make careful discussion of email
behavior a lot more consistent...

d/
-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Ted Lemon <[email-masked]>
Date: Tue, 01 Dec 2015 15:42:16 +0000

> do proper outbound filtering on their users' mail.

Can you describe (or refer to a description) of what was done in sufficient technical detail that we can evaluate whether or not whatever gets proposed here would break that functionality, and also whether there was any other way to accomplish the same purpose?   I don't doubt that this story is true, and worth considering, but at the level of detail you've provided, it's just a story.

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

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

---

From: Ted Lemon <[email-masked]>
Date: Tue, 01 Dec 2015 16:51:53 +0000

Tuesday, Dec 1, 2015 8:13 AM Paul Smith wrote:
> Once that document exists, then no one will add the trace fields, because people are paranoid (often rightly so, but not, I believe, in this case). They won't read the document fully. It may say 'you can remove IP address information from trace headers, but should think long and hard about it because doing so may come back to bite you and leaving the information in has minimal risk unless you're so stupid you haven't bothered with a firewall'. They'll get as far as the first comma, and stop.

I had no idea RFCs were so powerful.

> To be honest, I'm (pleasantly) surprised IP address information is still put in Received headers nowadays. IMHO, the fact that it is suggests that there's a very good reason for it to stay there.

No, it doesn't.   It suggests that there are one or more reasons why it has stayed there, zero or more of which may be good reasons.

> Many service providers and software publishers 'stretch' the rules somewhat, so if this was a big problem without any down-sides, then IP addresses would have disappeared from Received: headers some years ago.

We are seeing providers right now disappearing IP address information for the submission IP source address, so your logic here would suggest that there is in fact a downside to including that information; otherwise it would not have disappeared.

> If there were compatibility issues (eg some SMTP servers rejecting mail without the IP address info there), then that would still be a problem even if a new RFC comes out, unless SMTP is totally deprecated and a new mail standard replaces it. 

There is no such compatibility issue, because there is no required content in Received: header fields (the only thing that's even strongly recommended is "via") .   There is advice about what should be in them.   People are able to extract data from them anyway, because implementations tend to have default behavior which nobody bothers to change; this behavior tends to follow the examples in e.g. RFC 5821.

>If there are no compatibility issues with removing the IP address, then why aren't most providers/systems already removing it nowadays?

We've already heard that some Email SPs _are_ removing IP addresses in the most obviously problematic case.   The reason they aren't removing IP addresses in more cases is quite likely that they are using stock software (probably Postfix, but could also be MS Exchange or other products) that have default behavior, and they have not been motivated to override the default behavior for cases other than the submit source address case, which has the biggest doxing potential.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 01 Dec 2015 16:54:52 +0000

Tuesday, Dec 1, 2015 7:27 AM Arnt Gulbrandsen wrote:
>> Sure, but in this case wouldn't deferring to the end systems> argue in favor of allowing end systems to make the decision as> to whether their private information should be exposed?
> 
> As I see it, that's not the question here. The question is: Should there be an RFC that can be used/misused to apply pressure regarding trace fields etc?

Yes, I agree that this is what we are discussing.   I think it's pretty clear that for Received header fields that refer to the IP address of the end-user, the answer is "yes, there should be such an RFC."   I haven't heard anyone seriously propose that this is not true, although I'd be interested to hear such an argument!

---

From: Ted Lemon <[email-masked]>
Date: Tue, 01 Dec 2015 17:03:08 +0000

Tuesday, Dec 1, 2015 11:51 AM Ted Lemon wrote:
> There is no such compatibility issue, because there is no required content in Received: header fields (the only thing that's even strongly recommended is "via") . 

Oops, this isn't true--as Arnt mentioned, RFC 5321 does require the presence of a from clause in the Received header field, although it says it SHOULD, not MUST, contain the name and IP address of host that was the previous hop.   This doesn't change anything, since there's explicit advice not to drop messages simply because they fail to meet this requirement.

---

From: Steve Atkins <[email-masked]>
Date: Tue, 1 Dec 2015 09:11:23 -0800

> On Dec 1, 2015, at 8:54 AM, Ted Lemon <[email-masked]> wrote:
> 

Well, I'll be the first, then.

When people routinely hide their identities - to the extent that a recipient cannot tell that two emails were sent by the same person - that eliminates many social and technical pressures on bad behaviour. But it *also* removes the ability for people to help them when their endpoints have been compromised.

The biggest email-related risk to peoples privacy is malware that compromises their computers (followed by phishing, that compromises their online accounts).

If someone is sending mail through a smarthost provider that a) hides the source of mail sent through them and b) has an abuse/security team that is anything less than top-tier then there is no way to identify that mail originated with them. When their machine is compromised, it can then send out malware and phishing itself, compromising others. And there's no way to contact the people responsible for the security of that machine - whether it be the end-user themself, the end-users employers IT department or the end-users residential ISP. The infection spreads faster, more people's privacy is violated.

*Routinely* removing end-user identifiers harms privacy.

Cheers,
  Steve

---

From: Ted Lemon <[email-masked]>
Date: Tue, 01 Dec 2015 17:29:16 +0000

> When people routinely hide their identities - to the extent that a recipient cannot tell that two emails were sent by the same person - that eliminates many social and technical pressures on bad be…

Your entire argument relies on this point, so I will just respond to this one point; I don't disagree with what you say afterwards, but I think that you are wrong in suggesting that obfuscating the Received: header field for the email submission causes the problem you say it does.

The claim you have made is that the person submitting the email is hiding their identity, but this is not the case.   First, they have to prove their identity in order to submit the mail in the first place, most likely.   Secondly, their IP address is visible to the submit server, and is likely logged.   It is the submit server that, we are theorizing, should hide their identity.

The entity responsible for providing support to _that person_ is the entity that operates the SMTP submit server.   That entity knows the end user's identity, and knows what IP address they used to submit the email.   So they are not prevented from providing the support that you rightly say they should provide.

It is certainly true that if the submit server is not operated by a responsible entity, then we have a problem.   The right fix for that problem is probably something similar to what John has said AOL did in a similar situation: start greylisting mail from that provider so that the high rate of spam chokes their queues, and they will start to be more proactive in addressing problems.

There is no need to violate the privacy of legitimate end-users who are doing nothing wrong in order to address this problem.

---

From: "John Levine" <[email-masked]>
Date: 1 Dec 2015 17:40:25 -0000

>Yes, I agree that this is what we are discussing.   I think it's pretty clear that for
>Received header fields that refer to the IP address of the end-user, the answer is "yes,
>there should be such an RFC."   I haven't heard anyone seriously propose that this is not
>true, although I'd be interested to hear such an argument!

Of course there is such an RFC.  RFC 6409 refers to RFC 5321 which
describes the content of the Received header in section 4.4.  It
includes the IP address from which the message was received.

If, perhaps, you are wondering if there should be an RFC that updates
that advice to say to do something else, that's totally unresolved,
since nobody yet has made a plausible argument of what to change and
why there would be an overall benefit from doing so.

Until we look at the actual costs and benefits, it's grossly premature
to propose any changes.

R's,
John

---

From: "John Levine" <[email-masked]>
Date: 1 Dec 2015 17:50:28 -0000

>It is certainly true that if the submit server is not operated by a responsible entity, then
>we have a problem.   The right fix for that problem is probably something similar to what
>John has said AOL did in a similar situation: start greylisting mail from that provider so
>that the high rate of spam chokes their queues, and they will start to be more proactive in
>addressing problems.

Ah, OK.  As I said, AOL used the IP addresess of the naughty users,
logged in the received headers in the incoming mail, to decide what to
reject.  (It wasn't greylisting since they rejected it every time the
ISP retried.)  Without those IPs they couldn't have done it, since
they certainly weren't going to reject legitimate mail from the other
users.

I'm glad to see that we now agree that logging the submission IP
addresses provides important security benefits.

R's,
John

---

From: Ted Lemon <[email-masked]>
Date: Tue, 01 Dec 2015 17:58:04 +0000

> includes the IP address from which the message was received.

That's the latest version of the SMTP submit spec, not a document about Received: header field privacy.

> why there would be an overall benefit from doing so.

The benefit is pretty obvious.   If my IP address and identity information appears in a Received: header field, then I can't send mail to a public mailing list without revealing to the world geolocation information that could be used for doxxing/swatting me, or for various other nefarious activities, and I can't send email to an individual unless I am willing to reveal that information to that individual.   And I can't send email through any server operated by anyone to whom I do not wish to reveal that information.

These may not feel like important issues to you, but for some people they are life-or-death issues, and there really is a tradeoff to be made between the freedom of people in that situation to speak, and the freedom of the operators of mail servers to surveil them, even when that surveillance has a good motive behind it.   The problem is that it's not _just_ the people who need the information who get it.

> Until we look at the actual costs and benefits, it's grossly premature

Right, that's why I keep asking questions.   It's easy to read a series of questions as leading to a conclusion, and of course there is a conclusion that seems to be indicated here, but if I didn't care about your opinion and knowledge on this topic, I wouldn't be asking you questions.

---

From: Chris Lewis <[email-masked]>
Date: Tue, 1 Dec 2015 12:58:13 -0500

On 12/01/2015 12:40 PM, John Levine wrote:

| Until we look at the actual costs and benefits, it's grossly
| premature to propose any changes.

Yes, I think that would be very valuable.  Educational at least.  I'm
in support of a WG for that purpose.

---

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

> mailboxes does ...", that kind of thing.

First, people have already been referred to SpamAssassin, which most definitely
does perform various checks on Received: fields. The code is out there; all
you need to do is look.

And SpamAssassin absolutely is used by large setups. (Whether or not it is an
appropriate tool for such use is another matter that I see no reason to get
into.)

Second, good luck on getting anyone to comment on the details of their own
secret sauce, or for that matter getting anyone who has learned such details
through business relationships. All such information is pretty much guaranteed
to be covered by confidentiality or nondisclosure agreements.

				Ned

---

From: Chris Lewis <[email-masked]>
Date: Tue, 1 Dec 2015 13:18:52 -0500

On 12/01/2015 12:58 PM, Ted Lemon wrote:

| These may not feel like important issues to you, but for some
| people they are life-or-death issues, and there really is a
| tradeoff to be made between the freedom of people in that situation
| to speak, and the freedom of the operators of mail servers to
| surveil them, even when that surveillance has a good motive behind
| it.   The problem is that it's not _just_ the people who need the
| information who get it.

We appreciate that, but there already are plenty of special purpose
infrastructures that are perfectly capable of doing what you want when
you want.  People who want it already have it.  No reason to encourage
the breakage of "good purpose surveillance" (such as spam/abuse
filtering or infected machine remediation) all the time, because a
very small number perhaps only occasionally needs it.

It doesn't have to be either/or.  It's both now.  Not sure we need to
rock that boat.  Hence a WG to answer that question.

---

From: Chris Lewis <[email-masked]>
Date: Tue, 1 Dec 2015 13:21:51 -0500

On 12/01/2015 11:51 AM, Ted Lemon wrote:

| We are seeing providers right now disappearing IP address
| information for the submission IP source address, so your logic
| here would suggest that there is in fact a downside to including
| that information; otherwise it would not have disappeared.

What we have now is a very small number of providers doing this on
purpose (I can count the number of major providers doing it with the
fingers of one hand), and a still very small, but marginally larger
set of providers not providing it because their infrastructure doesn't
know what it is and/or their software just doesn't do it for one
reason or another.

On the other hand, we can see that that the lack of that information
presents difficulties to filtering technologies.  When you get a
series of harassing emails from a given site originating from a given
user that's forging from lines and mutating content, you have nothing
concrete to filter on to distinguish it from other email from the same
provider.

Leaving you with an all or nothing situation of blocking the whole
provider.  Which isn't a big drawback if the provider is good at
stopping abuse because the problem won't last long, but, the largest
provider in question often isn't, especially in the case of individual
harrassment.  Indeed, without that information being present (or not
being accessible without great effort using the provider's server
logs), it can cause significant difficulty for the provider doing
anything about it even if they wanted to.  IOW: if even the provider
doesn't know where it's coming from (or if finding out is too
expensive to do at scale), then everybody (including the poor user
with the infected box) is SOL.

One of your other points is that the received lines aren't
standardized.  Well, yes, that's true.  But that is in fact an
advantage to filters.  The simple fact of different
formats/idiosyncratic behaviour gives filtering technologies more
leverage to make filtering decisions that have nothing whatsoever to
do with IP addresses.  We use this sort of information to great
benefit - as do the largest email providers.

"Standardized" or not, Received lines provide a rich detail of fodder
for filtering, whether or not the filter manages to understand what
the received line is trying to say about where the email allegedly
came from or how it got there.  The IP could just as easily be a
non-reversible encrypted blob unique to the sending user that only the
provider understands, but the receiver can filter on.

I say "allegedly", because the actual source (personal attribution) of
the email is generally irrelevant to filtering. Our primary goal is
stopping the trash, a secondary goal is helping the infectee fix their
problem, but if the provider wants to interfere with the latter, well,
we can live with it.

---

From: Paul Smith <[email-masked]>
Date: Tue, 1 Dec 2015 18:26:05 +0000

On 01/12/2015 17:58, Ted Lemon wrote:
> These may not feel like important issues to you, but for some people they are life-or-death issues, and there really is a tradeoff to be made between the freedom of people in that situation to speak, and the freedom of the operators of mail servers to surveil them, even when that surveillance has a good motive behind it.

Is email the right system to use in that scenario then? If your IP 
address can locate you to that level of detail to anyone who looks 
(which is NOT the case for the vast majority of people), then you're 
probably in the situation where you can, and should, work out something 
better.

If your IP address can't locate you that precisely, but only to your ISP 
(which IS the case for most people), so that someone has to contact your 
ISP to find out exactly where you are, then they can contact your ISP to 
find out from their obfuscated-IP (or email address) who you are anyway, 
so it won't help there.

---

From: "John Levine" <[email-masked]>
Date: 1 Dec 2015 18:43:28 -0000

>These may not feel like important issues to you, but for some people they are life-or-death issues, and
>there really is a tradeoff to be made between the freedom of people in that situation to speak, and the
>freedom of the operators of mail servers to surveil them, even when that surveillance has a good motive
>behind it.   The problem is that it's not _just_ the people who need the information who get it.

If you're depending on the header writing practices of random
submission servers to keep you from being doxxed, you're not very
bright.  The doxxing crowd routinely use social engineering to call up
and get people to provide the information from the logs.

If you really need to keep your location private, use a Tor connection
to gmail or yahoo webmail.

R's,
John

---

From: Ted Lemon <[email-masked]>
Date: Tue, 01 Dec 2015 18:46:50 +0000

> does perform various checks on Received: fields. The code is out there; all

Looking at the code isn't all that interesting, but given that it's available, what _would_ be interesting would be to try Spamassassin with and without, e.g., the Received: header field from the initial submit, on the same corpus of mail, and see how the effectiveness of the filtering changes.

> to be covered by confidentiality or nondisclosure agreements.

This is probably true, but the effect of it is that we should not consider assertions people make that they can't justify.  It's actually not that useful to know what specific heuristics people are using.   What would be more interesting would be to do A/B testing as I suggest above, using their proprietary solution.   It seems to me that that could in principle happen without disclosing the information that these organizations don't want to disclose.   If they don't care enough to make such information available, it's likely that it's because they don't see the issue as being sufficiently important, which is to say they don't think Received: headers make enough difference to be worth arguing about.

---

From: Kurt Andersen <[email-masked]>
Date: Tue, 1 Dec 2015 09:52:56 -0800

> behavior a lot more consistent...

And in regard to indirect mail flows, may I recommend
https://datatracker.ietf.org/doc/draft-ietf-dmarc-interoperability/

---

From: Ted Lemon <[email-masked]>
Date: Tue, 01 Dec 2015 19:04:14 +0000

Tuesday, Dec 1, 2015 1:43 PM John Levine wrote:
> bright.

Can we dispense with the insults?   How does this add value to the discussion?

> The doxxing crowd routinely use social engineering to call up

Yes, and sometimes they succeed, and the times that they succeed, that's when the harm they do makes the news.   The times they fail, we don't hear about.

> to gmail or yahoo webmail.

As a rule, people don't know they need a specific kind of privacy until it's too late.   People who are, at present, in the happy state of not knowing they need privacy are in that state for one of two reasons.   One, they haven't actually said anything to offend some random 13-year-old sociopath out on the Internet yet.   Two, the privacy safeguards that they need are in place, and the sociopath they offended fails to get their info.

What we are talking about doing here is making the second case more likely.   This is important work that's worth doing.   It's not the case at all that people who fail to protect their own privacy are "not very bright."   Frequently they are very bright, but simply didn't imagine that they would be screwed over by the infrastructure they are using in such a blatant and unpleasant way.

The reason that people get screwed over in this way is because we, who understand about privacy and understand how to deliver it, did not make it a priority.   That's what this discussion is about.   So please don't belittle people whom we have failed by claiming that they should somehow have anticipated the problem.   That really is our job, not theirs.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 01 Dec 2015 19:10:02 +0000

Tuesday, Dec 1, 2015 1:21 PM Chris Lewis wrote:
> What we have now is a very small number of providers [...]

e.g., gmail.
 
> When you get a

This is why against our protestations DKIM is seeing wide deployment.   The fact that there is nothing in the mail submit process that prevents the user from forging headers is the problem.   Violating non-evil users' privacy in order to solve that problem is stealing from Peter to pay Paul.

---

From: Rich Kulawiec <[email-masked]>
Date: Tue, 1 Dec 2015 14:21:49 -0500

On Tue, Dec 01, 2015 at 07:04:14PM +0000, Ted Lemon wrote:
> Frequently they are very bright, but simply didn't
> imagine that they would be screwed over by the infrastructure they are
> using in such a blatant and unpleasant way. [...]
> 
> The reason that people get screwed over in this way is because we, who
> understand about privacy and understand how to deliver it, did not make
> it a priority.

Are we talking about the same people who:

	- sign up for so-called "social networks"?
	- post all kinds of details about themselves on same?
	- use mail clients that are web-enabled?
	- use smartphones and install a plethora of
		apps whose privacy policies boil down
		to "we collect everything and do whatever
		we want with it"?
	- &etc.?

The aggregate intelligence that I can acquire on people by examining their
email headers going back 20 years is vastly less than the aggregate
intelligence collected by any of the above.  And by "vastly" I mean
"orders of magnitude".

---rsk

---

From: Martijn Grooten <[email-masked]>
Date: Tue, 1 Dec 2015 19:23:53 +0000

> problem, but if the provider wants to interfere with the latter, well,

I think this is a very good point. A recommendation to substitute a
"non-reversible encrypted blob" for the sender's IP address seems to me
a good balance between privacy and security.

I agree that if keeping your geolocation is a matter of life and death,
you shouldn't use email, but for me that is not a reason for the IP
address to be visible for anyone who can read the email. I think privacy
matters, even when it's not about life and death.

Martijn.

---

From: "Robert A. Rosenberg" <[email-masked]>
Date: Tue, 1 Dec 2015 13:36:04 -0600

At 17:58 +0000 on 12/01/2015, Ted Lemon wrote about Re: [ietf-smtp] 
[Shutup] Proposed Charter for the "SMTP Hea:

>The benefit is pretty obvious.   If my IP address and identity 
>information appears in a Received: header field, then I can't send 
>mail to a public mailing list without revealing to the world 
>geolocation information that could be used for doxxing/swatting me, 
>or for various other nefarious activities, and I can't send email to 
>an individual unless I am willing to reveal that information to that 
>individual.   And I can't send email through any server operated by 
>anyone to whom I do not wish to reveal that information.

I remember that years ago (but no longer) there was a remailer server 
somewhere in Europe that handled most of this situation. You sent it 
your message (with routing info in the message body) and it stripped 
off the identification info and headers and sent it to the desired 
destination using a new identity. All replies (and other messages to 
that identity) went back to the server which then repackaged the 
message and sent it back to you.

Of course you had to trust the remailer's operator and accept the 
fact that you were talking to it might be an exposure.

---

From: Rich Kulawiec <[email-masked]>
Date: Tue, 1 Dec 2015 14:45:31 -0500

On Mon, Nov 30, 2015 at 04:46:14AM +0000, Ted Lemon wrote:
> The experience you related sounds like hobbyist activity, no offense.
> I can't see how what you described could possibly scale to anything a
> large email provider would ever do [...]

First, most extant "large email providers" are not exemplars of the
behavior that I think we should standardize/encourage.  I *wish* they
were: prominent role models would be valuable assets.  But they're not.

Second, no, it's NOT hobbyist activity, it's actually a very useful
technique for the overwhelming majority of operations...because the
overwhelming majority of operations, by a huge margin, are NOT "large
email providers".  They're Joe's Shoe Factory and Bedrock University and
Mary's Construction.  And both their inbound and outbound mail streams,
when subjected to appropriate analysis, exhibit a number of obvious
patterns.  Knowledge of those patterns guides defensive strategies
(against spam, phishing, etc.) and yields systems that exhibit very low
FP and FN rates -- and are fairly resistant to gaming by attackers.

Third, disabling those techniques (by concealing information that they
rely on) makes the users of such sites LESS secure because it increases
their vulnerability to spam, phishing, etc.

---rsk

---

From: "Christian Huitema" <[email-masked]>
Date: Tue, 1 Dec 2015 11:50:59 -0800

> I agree that if keeping your geolocation is a matter of life and death,
you
> shouldn't use email, but for me that is not a reason for the IP address to
be
> visible for anyone who can read the email. I think privacy matters, even
> when it's not about life and death.
> 

I am also concerned with automated mass surveillance, including traffic
analysis. The basic traffic analysis produces "5-tupple" logs. Since a lot
of the Internet usage is now mobile, there is no direct mapping between IP
addresses and user identities. To move from traffic analysis to
surveillance, the analyzers need to restore that mapping. There are multiple
ways to do that, as explained in RFC 7624, and email headers are one of
them.

Clearly, there are also other sources of correlation between IP address and
identity. Various IETF working groups are busy closing these other sources
as well: MAC Address randomization to suppress direct mapping of identities
to roaming devices; DHCP anonymity profile to remove the leakage of metadata
in DNS packets; or, HTTPS to prevent observation of HTTP cookies. To break
the correlation between IP address and identity, we need to also close the
leakage in the SMTP traces.

Everybody understands that there is a tension there between privacy and
fighting spam. I get the use case of the virus-infected home PC that
originates spam through the permissive SMTP relay of some local ISP. But
then many mail providers feel the need to provide privacy to their users,
which drives them to deploy their own formatting of the "received" field. We
do have a tension there, and that tension is precisely why we want to study
the alternatives and come up with a proposed recommendation. Hence the WG
charter.

-- Christian Huitema

---

From: Richard Clayton <[email-masked]>
Date: Tue, 1 Dec 2015 21:10:20 +0000

In message <[email-masked]>,
Arnt Gulbrandsen <[email-masked]> writes

>mailboxes does ...", that kind of thing.

All of the big mailbox providers ("MAGY", and of course many more
providers as well) use large and complex machine learning systems for
spam filtering. Consult the company's annual reports for the value of X
in "x million" because it rather depends how you count.

These ML systems use any and all features of incoming email in order to
determine whether email should be rejected, placed into a spam folder or
placed in an inbox.

All email, spam or not, contains a rich set of information within the
body (which the spammers can control) and the header fields (which they
can of course forge parts of, but by no means all). The ML doesn't
really care how much of the information is forged (and many spammers do
not bother because it doesn't help much). The ML is looking for
patterns, or the lack of patterns.

The richness of the information in the header fields is an important
reason why the ML systems operate at up to "4 nines" of accuracy.

I doubt you're going to get told much more than that because these
systems are complex, proprietary and there is an understandable concern
(and indeed a great deal of experience) that spammers will exploit
nuggets of information to improve their delivery scores.

Received headers also assist in loop detection and in helping
troubleshooters to understand the cause of delivery problems and the
location of compromises -- and they are valuable for that alone.

People are used to email "just working" ... there's a lot of folks
peering at the entrails to make that happen and they need all the help
they can get!

If you want to have very limited data in your email header fields then
you should look at the systems that you operate yourself and clean up
the information at that point. You'll probably get a poorer delivery
experience when sending to MAGY and others -- but that's your tradeoff.

- -- 
richard                                                   Richard Clayton

Those who would give up essential Liberty, to purchase a little temporary 
Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755

---

From: Ted Lemon <[email-masked]>
Date: Tue, 01 Dec 2015 21:29:09 +0000

> experience when sending to MAGY and others -- but that's your tradeoff.

Here are the Received: headers from the previous message I sent to the list.   As you can see, there is no Received header at all for the submit server.   My submit server doesn't add one, because there's no good reason to.   I have had zero issues with mail I send not being delivered to any of the big providers.   When I do have issues, the issues I have tend to be really small servers (typically IETF participants who, like me, run their own mail servers) that have all sorts of exciting steampunk gadgets filtering spam.

The issues that I have tend to be that mail to those users is delayed, not that it never arrives.   It's their choice to set up greylisting, and slowing down the reply rate for discussions like this isn't a bad thing, so I really wouldn't describe this as a "poorer delivery experience."

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 1 Dec 2015 22:51:13 +0000

> concrete to filter on to distinguish it from other email from the same

If you assume the MSA in that case isn't rogue, then there are
a variety of options that could be used in place of the actual
IP address that would have better privacy properties without
being particularly onerous on anyone. For example one could
imagine replacing the MUA IP address value in a Received header
field with something like E(k-epoch, MUA-IP-address) where
k-epoch is some key that changes now and then, perhaps in a
way that requires very little state in the MSA.

The point (for now) is not to recommend that the above be
done but just to note that there are other options that may
not have been considered in the past. Or maybe they were but
the reasonable trade-offs have changed.

Cheers,
S.

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 1 Dec 2015 22:58:40 +0000

On 01/12/15 19:50, Christian Huitema wrote:
> the alternatives and come up with a proposed recommendation. 

+1 to all the above.

> Hence the WG

Well... the charter text proposed (perhaps combined with the draft
posted before) does seem to have caused a bit of an allergic reaction
from many mail folks;-)

I suspect those of us who would like to see work done to improve the
privacy properties of mail may need to understand that reaction some
more before trying to move stuff ahead.

Cheers,
S.

---

From: Chris Lewis <[email-masked]>
Date: Tue, 1 Dec 2015 18:17:18 -0500

> For example one could imagine replacing the MUA IP address value in
> a Received header field with something like E(k-epoch,
> MUA-IP-address) where k-epoch is some key that changes now and
> then, perhaps in a way that requires very little state in the MSA.

If you read on a little further, you'll note where I mentioned (and
Martin reiterated) "one-way encrypted blob".

Which I proposed to, for example, senior MTA people at gmail almost a
decade ago.

---

From: Chris Lewis <[email-masked]>
Date: Tue, 1 Dec 2015 18:11:34 -0500

On 12/01/2015 04:29 PM, Ted Lemon wrote:
> Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01DDB1B2F31; Tue, 1 Dec 2015 11:10:08 -0800 (PST)
> Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BPlsDC_M90ws; Tue, 1 Dec 2015 11:10:06 -0800 (PST)
> Received: from fugue.com (mail-2.fugue.com [IPv6:2a01:7e01::f03c:91ff:fee4:ad68]) by ietfa.amsl.com (Postfix) with ESMTP id CDD061AD481; Tue, 1 Dec 2015 11:10:05 -0800 (PST)
>

The inevitable result is your mail server is treated no differently than 
grandma's PC.

When your cat's litter box gets infected with, say, cutwail, spewing 
gazillions of copies of randomized "come do X to my Y!" exhortations, 
you're not giving the receiver (ML or ad-hoc) very much to distinguish 
between that and your pearls of wisdom.

Hence your entire infrastructure gets blocked, you end up annoyed, the 
cat ain't admitting anything, and nothing gets fixed very quickly.

Also remember that at scale, you CANNOT afford to talk to everybody who 
has trouble with email.  Not when the loaded labor rate of just one 
support call dwarfs the income you make with the associated customer.

If you have to get noticed by a human being, you're already cost them 
more than they'll make.

Of course many systems operate this way without much difficulty. 
Because they are either already clean or expend the effort to remain 
clean.  Which is fine until that one day when something goes wrong.

---

From: Hector Santos <[email-masked]>
Date: Tue, 01 Dec 2015 18:37:28 -0500

> the alternatives and come up with a proposed recommendation. Hence the WG

I'm all for "generalized" product enhancement features.

So you are proposing for SMTP developers to consider adding SMTP 
Receiver options such as:

   [X] Add "Received:" Header
       [_] Mask User IP address

Should this be at the USER or SYSTEM level? Both?   Effectively, we 
would be changing RFC5321 from a MUST to a SHOULD|MAY where a required 
protocol feature becomes optional.

-- 
HLS

---

From: Ted Lemon <[email-masked]>
Date: Tue, 01 Dec 2015 23:45:54 +0000

Tuesday, Dec 1, 2015 6:11 PM Chris Lewis wrote:
> When your cat's litter box gets infected with, say, cutwail, spewing gazillions of copies of randomized "come do X to my Y!" exhortations, you're not giving the receiver (ML or ad-hoc) very much to distinguish between that and your pearls of wisdom.

Er, no, the cat box doesn't have my credentials nor know my email address, so it can't send spam from me.   If it sends spam from someone other than me, the Received header field makes my /legitimate/ email look more like spam, because both the cat's spam and my legitimate email have the same IP address in the Received header field.   In this case I /definitely/ don't want the Received header field.

---

From: Martijn Grooten <[email-masked]>
Date: Tue, 1 Dec 2015 23:49:51 +0000

> experience when sending to MAGY and others -- but that's your tradeoff.

Sure, making such changes on your own is probably going to hurt more                                                                                                                                                                          
than it helps. Which seems a good argument in favour of some kind of                                                                                                                                                                          
RFC, or at least a WG discussing whether one is needed.                                                                                                                                                                                       
                                                                                                                                                                                                                                              
Martijn.

---

From: John C Klensin <[email-masked]>
Date: Tue, 01 Dec 2015 18:52:21 -0500

--On Tuesday, December 01, 2015 21:10 +0000 Richard Clayton
<[email-masked]> wrote:

>...
> If you want to have very limited data in your email header
> fields then you should look at the systems that you operate
> yourself and clean up the information at that point. You'll
> probably get a poorer delivery experience when sending to MAGY
> and others -- but that's your tradeoff.

Or one can look at a slightly different question for which
"operate a mail system oneself" it, itself, a privacy compromise
(or an optimization that favors different concerns)

I actually think this is the key to at least one part of the
issue.   Many of us with current or historical experience
operating mail systems of assorted sizes and complexity are
hearing the current questions and charter draft as "how do we
weaken the way mail works in order to get some additional
privacy about location?"  As Stephen points out, such questions
cause fairly several allergic reactions.   Any results that
require protocol (or required value) changes would also
encounter (at least for MUAs other than webmail variations) the
extremely slow deployment and adoption times for such changes
and a different sort of allergic reaction.  Suppose that,
instead, the question was closer to: "if a user had a serious
desire to protect her location, especially against pervasive
surveillance by state actors and too-curious message recipients,
how would she do that with existing systems?"  One answer is
that she would sign up for a mail account with whichever of MAGY
(or MASYF) seemed least inclined to report client/user location
information and, ideally, had the maximum number of her
correspondents.   She would, of course, conceal her actual
identity and normal locations from them, perhaps by choosing a
clever user identity but if necessary by lying.  

Presto: very little location information would be disclosed and
SMTP requirements would largely be a non-issue.  One might have
to address the question of whether one trusted MAGYF more or
less than a curious and overly-intrusive government, but wasn't
the question.

     john

---

From: Al Iverson <[email-masked]>
Date: Tue, 1 Dec 2015 17:52:41 -0600

On Tue, Dec 1, 2015 at 5:45 PM, Ted Lemon <[email-masked]> wrote:
> Er, no, the cat box doesn't have my credentials nor know my email address, so it can't send spam from me.   If it sends spam from someone other than me, the Received header field makes my /legitimate/ email look more like spam, because both the cat's spam and my legitimate email have the same IP address in the Received header field.

Is that a hobbyist configuration? Is it relevant? It sounds a bit like
a cat and the hat both sharing a NAT. But in a very common high volume
production email scenario used by email service providers, clients and
types of mail are segregated by sending IP address.

>  In this case I /definitely/ don't want the Received header field.

Noted that you don't. Just adding my voice: I do want it.

Regards,
Al Iverson

--
Al Iverson - Minneapolis - (312) 275-0130
Simple DNS Tools since 2008: xnnd.com
www.spamresource.com & aliverson.com

---

From: Ted Lemon <[email-masked]>
Date: Tue, 01 Dec 2015 23:55:01 +0000

> RFC, or at least a WG discussing whether one is needed.…

Yup, what I'm getting from this conversation is that we ought to try to gain a bit more clarity than we currently have on this question.   I'm hearing a lot of hand-wavey protests, but when I try to dig deeper it's not clear that much analysis has actually occurred.   That analysis would be worthwhile to do and to write up as an informational draft.   I think the informational draft should _make no recommendations_ but should just talk about the various use cases.

---

From: Martijn Grooten <[email-masked]>
Date: Tue, 1 Dec 2015 23:57:00 +0000

> Which I proposed to, for example, senior MTA people at gmail almost a

A decade ago the amount of spam was growing rapidly. Edward Snowden
tried to join the US army.

Things have changed. There may be more of an interest today.

Martijn.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 01 Dec 2015 23:59:53 +0000

Tuesday, Dec 1, 2015 6:52 PM John C Klensin wrote:
> Suppose that,
> how would she do that with existing systems?"

John, I think that I already explained why this isn't a good question to ask.   We don't want privacy just for people who think in advance, "hm, email in general isn't private, and I know that I am going to need privacy, so I will use this other service in order to gain privacy."   We want the email to already have been private when the need for it to be private arises, without the user who needs this privacy having a mental model that would allow the aforementioned questions to be asked, to say nothing of being answered.

Regarding my personal mail server, one instance is in Dallas and the other in Frankfurt.   Regardless of where I happen to be on any given day, any geolocation done on the headers will reveal that I am in a data center in one of those two cities.   Since I am not in either of those data centers, I am protected from any revelations about my actual location through header fields in my email.   Of course, you can tell that the mail came from me, but that's what I want, so it's okay.

---

From: Chris Lewis <[email-masked]>
Date: Tue, 1 Dec 2015 19:38:29 -0500

On 12/01/2015 06:45 PM, Ted Lemon wrote:
>> When your cat's litter box gets infected with, say, cutwail,
>> spewing gazillions of copies of randomized "come do X to my Y!"
>> exhortations, you're not giving the receiver (ML or ad-hoc) very
>> much to distinguish between that and your pearls of wisdom.
>
> Er, no, the cat box doesn't have my credentials nor know my email
> address, so it can't send spam from me.   If it sends spam from
> someone other than me, the Received header field makes my
> /legitimate/ email look more like spam, because both the cat's spam
> and my legitimate email have the same IP address in the Received
> header field.   In this case I /definitely/ don't want the Received
> header field.

Er yes, without the MSA-enforced IP address (or unique blob indicating
something similar) the filter can't necessarily tell whether your
legitimate email is different than the cat litter box.  By omitting
the MSA's received line your legitimate mail becomes _less_
distinguishable from the flying litter ... the ML has more chance of
lumping both of youse into the same bucket and so your email ends up
in the toilet too.

Even when everything is forged/forgeable (eg: regardless of whether
the MSA's headers are forged or decided to be trustworthy), the
uniformity of your Received/From tuples stands out in stark contrast
to the forged stuff (random or otherwise) to the ML - it gives the ML
more to "grab onto".

Now, with my piddly little mail server (which your steam punk mail
server doesn't seem to like BTW), the ML will rarely see enough signal
to do a proper analysis.  But at scale, the ML often will.

---

From: Chris Lewis <[email-masked]>
Date: Tue, 1 Dec 2015 20:09:18 -0500

lumping both of youse into the same bucket and so your, er, email ends 
up in the toilet too.

---

From: Chris Lewis <[email-masked]>
Date: Tue, 1 Dec 2015 20:43:43 -0500

> John, I think that I already explained why this isn't a good question to ask.   We don't want privacy just for people who think in advance, "hm, email in general isn't private, and I know that I am…

The reality is that if the user wasn't already conscious of their 
privacy and striving to preserve it through continuous vigilance, 
they've already completely outed themselves.

For example, if you're expecting to use a nicknamed gmail account, that 
email conversation with Amazon with your credit card info or Facebook 
with your real name last year, has outed that gmail account forever - 
gmail hides received lines remember?

It's far better to train them in the reality of what they need to do to 
preserve their own privacy, than the impossibility of trying to 
privacy-protect everything (and still have something anybody wants to use).

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 2 Dec 2015 01:57:00 +0000

> privacy-protect everything (and still have something anybody wants to use).

Do you have any evidence for the above?

But in any case, I think your argument is clearly wrong because we
know that it is not possible to "train them" in security or privacy.
(That leaves open the possibility that your conclusion is correct
based on some other argument, but very much weakens confidence in
your conclusion for me.)

IMO the onus is on us as technology developers to ensure that what
we make allows those who deploy that to do a good enough job. In
this case there is room for debate about the cumulative privacy
exposure from many messages including MUA IP addresses (or of
popular implementations defaulting to do so) vs. the benefits
accruing to anti-spam techniques.

For me, claims that any of this is so obvious as to not even need to
be looked are not at all convincing. And in that I do include claims
that "all we need to do is X and it'll be privacy friendly" (for any
X) as well as claims to "move on, there's nothing to see here."

S.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 02 Dec 2015 02:30:58 +0000

> types of mail are segregated by sending IP address.

My answer applies to both the gmail scenario and the private server scenario.   In both cases, putting my IP address in the Received header field means that my legitimate mail is more likely to be dropped as spam, not less likely.

> Noted that you don't. Just adding my voice: I do want it.

Correction: by "I do not want it," I mean "it do not want my mail legitimate getting dropped as spam," not "On a personal level, I don't like it."

---

From: Ted Lemon <[email-masked]>
Date: Wed, 02 Dec 2015 02:55:14 +0000

Tuesday, Dec 1, 2015 8:43 PM Chris Lewis wrote:
> The reality is that if the user wasn't already conscious of their privacy and striving to preserve it through continuous vigilance, they've already completely outed themselves.
> 
> For example, if you're expecting to use a nicknamed gmail account, that email conversation with Amazon with your credit card info or Facebook with your real name last year, has outed that gmail account forever - gmail hides received lines remember?

I think you are misunderstanding the reasoning behind hiding the IP address in the received header.   It is not because the IP address associates the email address with your identity.   In all likelihood, the email address is very strongly associated with your identity, as you say.   One of the primary uses of email addresses _is_ to establish an identity, after all.

The purpose of obscuring the IP address is to avoid an association between the _IP address_ and your identity.   This accomplishes several useful privacy benefits:

- If you regularly post to a public mailing list, as we both do, nobody can scrape the mailing list for Received headers and figure out whether or not I am at home, in order to find an opportune time to break into my home.
- If you post to a public mailing list, that doesn't reveal information about where you live to people who might want to harass you.
- An MiTM attack on your email service provider that prevents TLS encryption of your mail will not give the attacker information linking your identity to specific IP addresses.

Whether these are issues that we need to be concerned about it certainly something we can debate.   I definitely agree that _just_ obscuring the IP address in the Received header isn't enough to protect you.   But if it's not obscured, that's definitely enough to out you.

> It's far better to train them in the reality of what they need to do to preserve their own privacy, than the impossibility of trying to privacy-protect everything (and still have something anybody wants to use).

This is literally impossible.   We don't demand that airline passengers take part in making sure that the airplane is safe to fly.   Why do we expect people with similar levels of knowledge about the operation of email to understand how to preserve their privacy?

---

From: Al Iverson <[email-masked]>
Date: Tue, 1 Dec 2015 21:00:24 -0600

> Correction: by "I do not want it," I mean "it do not want my mail legitimate getting dropped as spam," not "On a personal level, I don't like it."

Clarification:
1. Received headers and the IP addresses therein are currently
valuable for filtering today, for me, for others, and as I've observed
for others as big as AOL.
2. When I say "I do want it," I mean I think it would be a great loss
to lose the current information (IP address and/or received headers)
valuable for filtering purposes today under existing use cases. I want
received headers and IP address source information to remain in email
headers.
3. Your concern about your sending reputation being commingled with
your cats is already the way the world works today if your mail
streams are commingled. This is not a new problem and the proposed
potential solution of redacting IP addresses or removing received
headers takes data way instead of adding more data for filtering
purposes. It's sort of cutting off a leg because we don't like how the
arm works. Too much of spam filtering and reputation today is still IP
address-based to throw out that identifier today. Like Chris said, the
machine learning out there now almost always uses that identifier as
an input today.

Regards,
Al Iverson

---

From: Ted Lemon <[email-masked]>
Date: Wed, 02 Dec 2015 03:09:49 +0000

Tuesday, Dec 1, 2015 2:20 PM Chris Lewis wrote:
>> If they don't care enough to make such information available, it's
>> likely that it's because they don't see the issue as being
>> sufficiently important, which is to say they don't think Received:
>> headers make enough difference to be worth arguing about.
> 
> That's not what it means at all.
> 
> For any such information to be even remotely meaningful, it has to be tested on very large real environments.
> 
> Imagine, if you will, our approached our largest customers (which are certainly big enough to matter in this context), and asked them to either:
> 
> - sacrifice filtering effectiveness for a week and tell us the
> result, or
> - re-instrument thousands of receiving MTAs to distinguish and report
> on the differential based on a new indicator I provide
> 
> So that we could satisfy your curiousity, they'd laugh in our faces.

That is literally what I said.   They don't care enough about satisfying my curiosity to do the work.   Perfectly understandable.   If they thought that the IETF producing a document recommending that the Received header field be obfuscated were a serious problem, they would care enough to do the work--it's really not that much work, and chances are they already have a test harness that would allow them to do it.

> I could tell you the differential in our instrumentation. But if you don't accept my previous assertions, you won't accept this one either.

Again, this is literally what I asked for.   I do not trust your assurances that you speak from authority.  IETF people are always trying to argue from authority--if we held that against each other we would never get anything done.

I am very curious to hear your numbers, as long as you explain how you got them.  I don't mean explain your spam algorithm--I mean characterize your sample, and explain why you think it's a good sample, and explain your methodology: what you did to the sample for test A versus what you did for test B.   Interesting things to do for the test sample to differentiate it from the control sample would be removing the last Received header field entirely (last in sequence, meaning first added), modifying the From clause for example as Stephen Farrell suggested, or simply deleting the From clause but keeping the rest of the last Received header field.

BTW, turning off the Received header field testing for a week isn't a valid methodology, since there's no way to control for the rather substantial variation in amounts and types of spam from week to week.

> In an ideal world, when everybody here was under NDA, I could give you some of the obvious, compelling and overwhelming evidence. 

I don't think you could.   You've said enough things that don't actually make sense at this point that I would really need you to show your work, not just give me assurances like the following:

> It's huge. Really.

Sorry.

---

From: Rich Kulawiec <[email-masked]>
Date: Tue, 1 Dec 2015 22:16:59 -0500

> accruing to anti-spam techniques.

It's not just anti-spam techniques that benefit.  Anti-phish
techniques do as well, and while *sometimes* phishes are delivered
via spam, sometimes they're not (e.g., spear-phishing, which may
consist of a single messages, thus not bulk, thus not spam).

So do attempts to trace harassment, bullying, etc.  So do efforts
to detect and prevent fraud.  So do attempts to detect, diagnose,
and fix delivery problems.  And so on: the utility of header
information is enormous, particularly in an environment which
increasingly lacks cooperation.

---rsk

---

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

> they've already completely outed themselves.

+1

The same user that might -- and I emphasize "might" -- in some way have
a fraction of their privacy protected is the same one that has a 9-line
email signature with the URLs of their social network profiles, their
phone number, their title and employer, and other far more readily-useful
information.  That same user makes poor password choices, has their
email account breached, and the resulting spam run reveals most of the
contents of their "address book".  Or they use a web-enabled mail client
and click on links in messages, thus handing over accurately-timestamped
IP address information along with client name/version, OS name/version,
etc. to senders or third parties.  That user replies to spam, clicks on
"unsubscribe" links, and uses a mail client that's 8 revisions out-of-date
and was recently discussed at length on full-disclosure.

Nobody is going to bother looking at the Received headers of their
messages because nobody needs to.

---rsk

---

From: Ted Lemon <[email-masked]>
Date: Wed, 02 Dec 2015 03:35:04 +0000

Tuesday, Dec 1, 2015 10:25 PM Rich Kulawiec wrote:
> information.

This is a stereotype, which very clearly is not grounded in any kind of serious, statistically sound survey of real-world users.   Are you seriously proposing that the IETF should base its decisions on reasoning of this quality?

---

From: Paul Smith <[email-masked]>
Date: Wed, 2 Dec 2015 08:56:24 +0000

> This is literally impossible.   We don't demand that airline passengers take part in making sure that the airplane is safe to fly.   Why do we expect people with similar levels of knowledge about t…
The thing is that whatever you do to email, the weak link is always the 
human. Humans are the ones who respond to Nigerian princes, they're the 
ones who think it's OK to send their bank password by email to anyone 
who asks for it in an authoritative way, etc.

So, training HAS to be done, otherwise people will lose privacy.

Of course, most people don't really care about privacy whatever they say 
(witness all the personal information posted to Facebook/Twitter/etc) so 
it doesn't matter that they can't be trained. The ones who do really 
care about their privacy are the ones who will train themselves if the 
information is available to them.

---

From: Paul Smith <[email-masked]>
Date: Wed, 2 Dec 2015 09:21:45 +0000

> Regarding my personal mail server, one instance is in Dallas and the other in Frankfurt.   Regardless of where I happen to be on any given day, any geolocation done on the headers will reveal that…
IP geolocation won't (usually) tell anyone exactly where you are.

According to Geolocation databases, an IP address of one of my business 
customers based in Huddersfield, UK, is either in Hereford, Beulah, 
Rochdale, or just the UK. So, Geolocation isn't really working closer 
than country level.

The actual user's computer is going to be 192.168.15.something, so that 
being in the header isn't going to locate the user in any way to someone 
not involved in the business.

If you are a bigger business and have a range of IP addresses, then the 
geolocation MAY give more information, but it's not a given. Relying on 
it for anything more precise than a country is taking a big risk.

My business has 3 small IP address ranges (three ISPs for redundancy):
The first one is either in Silvertown, Holmfirth or London depending on 
which Geolocation database I look at. I have no idea where Silvertown 
is, Holmfirth isn't bad , and London is not very precise, as well as 
being 200 miles away.

The second is either in a city called 'Paul' (that's my name - not a 
city), or Mitcham (no idea?) or Rochdale (my ISP) or the UK.

The third is in Exeter (Sowton Industrial Estate, apparently - quite 
precise, but 257 miles away...) or just the UK

(FWIW, my home IP range which is from the same ISP as the second one 
above, and in the same town as that, is either in 'Paul' (again), 
Brenchley or Rochdale, so it looks as if some of them just give random 
details if they don't know the answer... Rochdale I understand as that's 
the ISP, but Brenchley, Mitcham or Beulah are just random)

---

From: Paul Smith <[email-masked]>
Date: Wed, 2 Dec 2015 09:37:13 +0000

On 01/12/2015 19:23, Martijn Grooten wrote:
> "non-reversible encrypted blob" for the sender's IP address seems to 
> me a good balance between privacy and security. I agree that if 
> keeping your geolocation is a matter of life and death, you shouldn't 
> use email, but for me that is not a reason for the IP address to be 
> visible for anyone who can read the email. I think privacy matters, 
> even when it's not about life and death. Martijn.
I'm fascinated by the concern about geolocation.

How well does it work for other people? For me, it gives me the country 
fairly reliably, and nothing else reliably at all.

A hashed IP address will not help issues with 'tracking' people using 
their IP addresses (you just track people using the hashed address 
instead). The only thing it will prevent is someone using geolocation, 
which my tests suggest is pretty useless 99% of the time anyway...

---

From: Paul Smith <[email-masked]>
Date: Wed, 2 Dec 2015 09:44:34 +0000

> peering at the entrails to make that happen and they need all the help 

This is the bit that worries me. As a small mail server publisher & 
hosting company, we try to actually help our customers with their 
problems (unlike some of the big providers). The information in the 
Received headers is vital to us when trying to narrow down why their 
messages bounced, or why their incoming mail was delayed, or whatever.

If information is stripped away from Received headers, then we'd be 
hampered with that diagnostic work, and would have to rely on 
cooperation from the big providers, which we all know is pretty much 
never going to happen.

Once you've got a real (competent) person on the end of 
[email-masked]' who can reply usefully within a few hours, then 
I'd be happier about stripping away the little bit of trace information 
we currently have.

---

From: Richard Clayton <[email-masked]>
Date: Wed, 2 Dec 2015 10:02:47 +0000

In message <[email-masked]>, Martijn Grooten
<[email-masked]> writes

>RFC, 

I think you have misunderstood my point (which Chris Lewis also made)... 

If you discard all the data that identifies that you were the origin of
this email then your previous good reputation will not count towards
ensuring that another email from you is treated favourably.

It doesn't matter a jot whether or not that discarding is done on the
basis of the rules set out in an RFC or otherwise.

>or at least a WG discussing whether one is needed.

you should note that IP addresses acquire reputation because of the
prefix they are within, because of the AS that announces that prefix and
because of the country that AS operates from...   replacing an IP with a
blob will remove those opportunities for you to inherit some kudos from
your neighbours and fellow citizens

this WG is going to have to come with something fairly clever to avoid
making things worse  (and please don't forget about loop prevention)

- -- 
richard                                                   Richard Clayton

---

From: Martijn Grooten <[email-masked]>
Date: Wed, 2 Dec 2015 10:04:55 +0000

On Wed, Dec 02, 2015 at 09:37:13AM +0000, Paul Smith wrote:
> How well does it work for other people? For me, it gives me the
> country fairly reliably, and nothing else reliably at all.

A very small sample (n=2) of submission IP addresses found in email
headers gave me the city/area the sender was based in.

It's not just about geolocation though; Christian pointed out some other
issues with being able to track people via their IP address.

> A hashed IP address will not help issues with 'tracking' people
> using their IP addresses (you just track people using the hashed
> address instead). The only thing it will prevent is someone using
> geolocation, which my tests suggest is pretty useless 99% of the
> time anyway...

Yes, just using a hash wouldn't help much. The "cryptographic blob"
should be somewhat more complicated than just a hash. An RFC could make
recommendations about how to generate such a blob.

Martijn.

---

From: Paul Smith <[email-masked]>
Date: Wed, 2 Dec 2015 10:10:38 +0000

> headers gave me the city/area the sender was based in.
That's much better than I get...
> recommendations about how to generate such a blob.
It would have to change per message to make it untrackable, but then it 
wouldn't be any use for reputation logging either.

If it changes per message, it would have to be identifiable by the host 
which generated it, which would mean there'd have to be someone to deal 
with trace enquiries at the service provider, and some way of 
identifying/deciding who can, and who can't, get identifiable data from 
the 'blob'.

Otherwise, you may as well just remove it totally.

---

From: Martijn Grooten <[email-masked]>
Date: Wed, 2 Dec 2015 10:13:42 +0000

On Wed, Dec 02, 2015 at 10:02:47AM +0000, Richard Clayton wrote:
> making things worse

I fully agree. I don't think we should discard the possibility of the WG
being able to do that right away though.

Martijn.

---

From: Martijn Grooten <[email-masked]>
Date: Wed, 2 Dec 2015 10:31:53 +0000

On Wed, Dec 02, 2015 at 10:10:38AM +0000, Paul Smith wrote:
> It would have to change per message to make it untrackable

I think a reasonable compromise would be for this blob to stay constant
for (user,IP address) for some time. This would allow spam filters to
link emails to the same sending machine, but wouldn't link emails to
website visits from the same IP address.

Martijn.

---

From: Paul Smith <[email-masked]>
Date: Wed, 2 Dec 2015 10:51:53 +0000

> website visits from the same IP address.
That would still allow someone to 'track' you by comparing the blob to 
your home/work/mobile blobs

It wouldn't work if the user is unknown (eg for ISPs who validate 
customers based on IP address, rather than SMTP authentication), and it 
may 'expose' more information since the blob now "identifies" the user 
rather than just the IP address as there is now.

It might stop you linking website visits to IP addresses (does anyone do 
that?), but what if the website requests email validation by asking you 
to reply to an email it sends to the user? Now, people have access to 
the 'blob', and can link that to the IP address of the user with a high 
degree of probability.

I'm not convinced there's any way to 'hide' IP address information other 
than removing it totally, which arguably reduces spam detection, which 
is a much greater risk to privacy than tracking IP addresses from 
Received headers. It seems to be a well-intentioned idea that will 
actually make things worse rather than better.

A working group is fine, as long as the charter is clearly something 
like "explore the possibility of hiding header information and, if it's 
sensible, then work out how it may be done", and not "work out how to 
hide header information". i.e. -as long as it can accept that it may be 
a bad idea and shouldn't be done at all. That doesn't seem to be the 
intention behind the proposed charter - that seems to be "we're going to 
do it regardless, this WG is to work out what we can remove".

---

From: Rich Kulawiec <[email-masked]>
Date: Wed, 2 Dec 2015 08:04:49 -0500

On Tue, Dec 01, 2015 at 11:50:59AM -0800, Christian Huitema wrote:
> surveillance, the analyzers need to restore that mapping. 

I share this concern, but:

I think it's a very safe bet that all large email providers have
been quite thoroughly backdoored [1] by at least one intelligence agency,
with or without their knowledge, with or without their cooperation.
Consider that such an agency -- with access to all of the logs on MAGY
(to borrow an acronym seen elsewhere in this discussion) -- can do an
incredible amount of surveillance even before they grab the messages.
(Which they will also do, of course.)

What fraction of the world's email traffic (measured by message count)
traverses at least one of MAGY?  What fraction does that become if we
add so-called "social networks" and a dozen other large email providers?

My point is that if the mass surveillance is coming from governments
with sufficient resources, they won't rely on header extraction from
messages for traffic analysis: they'll just tap the logs.  Or request
it from their colleagues who already have (if there's a close working
relationship) or try to steal it from them (if there's not).

---rsk

[1] I think this is a safe bet because we have an existence proof
demonstrating that they've already done it once.  Surely nobody is naive
enough to think that they've only done it once or only done it one way:
this data is far too rich for its acquisition to depend on
a single point-of-failure.

---

From: Richard Clayton <[email-masked]>
Date: Wed, 2 Dec 2015 13:23:36 +0000

In message <[email-masked]>, Rich Kulawiec <[email-masked]>
writes

>add so-called "social networks" and a dozen other large email providers?

exact data is somewhat proprietary, but approximations are easy to find
with these new fangled search engine devices...  but to save you the
trouble of working out some appropriate search terms:

        https://www.senderbase.org/static/email/#tab=2

However, this table is a bit odd in that Yahoo appears twice (and
Microsoft appears three times, but for a more obvious reason)

I think you might reasonably assume that the presence of a Vietnamese
ISP and the University of Minnesota are indicative of spamming. I expect
that examining headers :-) will reveal a great deal about what is
happening at the latter institution (the former source is an ongoing
issue that I understand to be bots and a semi-functional abuse@ system)

- -- 
richard                                                   Richard Clayton

---

From: Ted Lemon <[email-masked]>
Date: Wed, 02 Dec 2015 13:50:50 +0000

Wednesday, Dec 2, 2015 3:56 AM Paul Smith wrote:
> The thing is that whatever you do to email, the weak link is always the human. Humans are the ones who respond to Nigerian princes, they're the ones who think it's OK to send their bank password by email to anyone who asks for it in an authoritative way, etc.
> 

Look, I'm really sorry to keep harping on this, because I know it's a bit off topic and probably annoying, but your model of how to do security for end users is simply wrong.   The way you prevent people from getting scammed is to by default not deliver email from people they don't know.   I realize this is anathema to a lot of email folks, but that's why facebook is more popular than email now: facebook doesn't deliver spam from people you haven't friended.

The way you prevent people from getting their passwords ripped is to not give them passwords.   The tokbind working group is working this problem, and the solution they have is a good one, which we will undoubtedly see deployed in the future.   It's true that it's not available now, and the vulnerability that you cite does exist now.   This is a problem we need to solve, not an inevitable quality of online technology.   Security technology based on physical tokens is also getting better/more accessible.   It's worth noting that Nigerian scammers typically scam people who have actual cognitive deficits, not regular people.   People aren't actually all equally gullible, and there are lots of people who are skeptical enough that they can benefit from privacy protections even in the absence of secure token binding and physical tokens.

> Of course, most people don't really care about privacy whatever they say (witness all the personal information posted to Facebook/Twitter/etc) so it doesn't matter that they can't be trained. The ones who do really care about their privacy are the ones who will train themselves if the information is available to them.

This doesn't reflect what people who actually study this issue are saying.   People do care about privacy.   They just can't get it.   Even though they can't get it, they do take measures to get it to the extent that they can.   It's true that not everybody does this, but it is not true that most people just don't care.   If you ask them "do you care about privacy," they might say no, but if for example you ask them "do you care if thieves know whether or not you are out of town," they will say yes.

So saying that because people don't care about privacy, we shouldn't try to protect their privacy, is wrong on two counts: first it's wrong that people don't care about privacy, and second it's wrong that we shouldn't try to protect people from threats of which they are not presently aware.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 02 Dec 2015 14:03:21 +0000

Wednesday, Dec 2, 2015 4:37 AM Paul Smith wrote:
> How well does it work for other people? For me, it gives me the country fairly reliably, and nothing else reliably at all.

I use google maps to check the accuracy of geolocation, from my laptop, which doesn't have GPS.   At home, in a small town in a sparsely populated region, it's accurate to about fifteen miles.   In New York, it's accurate to a few blocks.  In Herndon, Virginia, it's similarly accurate.   It was able to geolocate me during my train rides to and from DC last week with about ten mile accuracy, which is pretty impressive.

This is sufficient accuracy to tell that I'm out of town, and it's also sufficient to give a social engineer enough information to zero in on me.   If all you know is that I'm in the U.S., finding records about me is hard; if you know what town I live in, it's a lot easier.

> A hashed IP address will not help issues with 'tracking' people using their IP addresses (you just track people using the hashed address instead). The only thing it will prevent is someone using geolocation, which my tests suggest is pretty useless 99% of the time anyway...

Bear in mind that if everybody behind a particular NAT gets the same hash, and anybody leaks the actual IP address, that leak can be used to geolocate everybody behind that NAT.   It's still worth doing the hashing, but it might be better to do it in a way that produces a different token for each user.   Or it might not--we'd have to think about the threat model.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 02 Dec 2015 14:05:50 +0000

Wednesday, Dec 2, 2015 4:44 AM Paul Smith wrote:
> This is the bit that worries me. As a small mail server publisher & hosting company, we try to actually help our customers with their problems (unlike some of the big providers). The information in the Received headers is vital to us when trying to narrow down why their messages bounced, or why their incoming mail was delayed, or whatever.

This is all true, and definitely a matter of concern.   The question is, is there some way that we can give you enough information to do the debugging you need to do, without leaking private information?   E.g., when would you need the sender's home IP address to do debugging?

---

From: Paul Smith <[email-masked]>
Date: Wed, 2 Dec 2015 14:17:55 +0000

> This is all true, and definitely a matter of concern.   The question is, is there some way that we can give you enough information to do the debugging you need to do, without leaking private inform…
Eg, someone says to me "so and so received this message from me, but I 
didn't send it - has my laptop got a virus on it?" I can look at the IP 
address in the Received header and say, "no, that message came from 
China, someone's just spoofing your address",  or "it may have done, is 
your ISP 'bigisp.com'?" (or in some cases, "is your home IP address 
1.2.3.4?" (if they have a static IP address))

Or, the answer may be "that message came from Russia, but it was sent 
through your ISP - your ISP password may have been compromised, you may 
want to change it"

If the IP address is hidden, I can't do all that. There may be a way to 
replicate the information without giving away the same data, but the IP 
information *is* useful. The above scenarios do happen to me, not 
infrequently.

(There may be other solutions to fixing problems with spoofed addresses, 
compromised passwords, etc, but those are all separate issues, and have 
been discussed at length).

---

From: Paul Smith <[email-masked]>
Date: Wed, 2 Dec 2015 14:19:07 +0000

> This is sufficient accuracy to tell that I'm out of town, and it's also sufficient to give a social engineer enough information to zero in on me.   If all you know is that I'm in the U.S., finding…

Maybe the US is different. In the UK, it generally gives random 
locations which have no relation to reality, or probably just the ISP's 
location.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 02 Dec 2015 14:24:47 +0000

Wednesday, Dec 2, 2015 9:19 AM Paul Smith wrote:
> Maybe the US is different. In the UK, it generally gives random locations which have no relation to reality, or probably just the ISP's location.

Possibly the UK has better privacy laws?   The EU as a whole certainly does.   It may also depend on how much information the ISP is willing or able to sell about you.

---

From: "John Levine" <[email-masked]>
Date: 2 Dec 2015 14:49:53 -0000

>Look, I'm really sorry to keep harping on this, because I know it's a bit off topic and probably
>annoying, but your model of how to do security for end users is simply wrong. ...

Different people are different and it is not helpful to pretend that
all end users are the same.  Most people say they care about privacy,
but their actions show that they actually don't, e.g., they'll trade
their password and SSN for a candy bar.

Some people really do care about privacy.  I don't know if you've ever
talked to someone who runs a battered women's shelter, but I have.
For them, their privacy is really a matter of life and death, and they
have to deal with impressively complex threats.  I've heard direct
reports of malware that installs keyloggers that report back to the
hostile spouse.  These people boot their computers from a CD to use
webmail through Tor, and buy burner phones in bulk.  The kind of stuff
we're talking about redacting here is completely irrelevant to them,
since as I said, they are not so dim as to depend on their mail
provider's logging practices for their safety.

Christian's point about bulk collection is a reasonable one, but just
as the collection affects a lot of people, the security benefits from
good header logging affect a lot of people, too.  We need to start by
understanding how they're really used and what the benefits are.

>From what we've heard here from people who run significant mail
systems for real users, the benefits are substantial.

R's,
John

---

From: Dave Crocker <[email-masked]>
Date: Wed, 2 Dec 2015 07:12:02 -0800

On 12/2/2015 5:50 AM, Ted Lemon wrote:
> Look, I'm really sorry to keep harping on this, because I know it's a bit off topic and probably annoying, but your model of how to do security for end users is simply wrong.   The way you prevent people from getting scammed is to by default not deliver email from people they don't know.   I realize this is anathema to a lot of email folks,

Absent hard data that shows efficacy, both of you are wrong.

At base, we don't know how to prevent folks from getting scammed, while
still allowing them to interact with the outside world.

Lots of people are sure they know the right answer here, but none of
them can document efficacy.  Worse, most of the ways people cite have
already been demonstrated to be inadequate or unachievable.

So yeah, this line of discussion is entirely out of scope.

d/

---

From: Ted Lemon <[email-masked]>
Date: Wed, 02 Dec 2015 15:12:44 +0000

> their password and SSN for a candy bar.

Show your data or please stop making generalizations like this.   This is really not helpful.

> provider's logging practices for their safety.

So what you are saying is that there are two kinds of caring about privacy: not at all, or extremely.   I'm sure these stereotypes are based in real personal experience, but anecdotes are not data.   This is not what actual research on this topic appears to show.   We tend not to remember reasonable people in ordinary situations: we remember complete idiots, because it's funny/disturbing, and we remember people in trouble.   Basing policy decisions on personal recollections tends to get things badly wrong.

> understanding how they're really used and what the benefits are.

I agree that we need to understand this.  I've been asking people who say they are in the know if they could share some data with us, and since I asked yesterday, it's unreasonable to think that someone would already have answered.   Hopefully we will get some data.

> systems for real users, the benefits are substantial.

We've heard unsubstantiated assertions to this effect, not accompanied by any data, yes.

The reason I'm skeptical about this is twofold.  First, the one example someone presented that seemed to support the case for including IP address identifying information from the mail submission server actually looks to me like it makes things worse, not better, at least in the presence of a competently operated mail submit server.

Second, I'm pretty sure that if you are filtering spam, and then you add a heuristic that pays attention to the initial sender's source address, you will see some increase in messages identified as spam.   However, if you saw that effect five years ago when you installed that heuristic, and your filtering software has gotten a lot more sophisticated in its reliance on ML since then, you might still believe that the heuristic is making a big difference, when it's really making a small difference. 

And you might never have instrumented it in such a way that you could discover the present truth of the matter.   And that's precisely the perfectly reasonable mindset from which claims that "it makes a big difference" would come without any data at all to back them up.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 02 Dec 2015 15:20:09 +0000

> Absent hard data that shows efficacy, both of you are wrong.

Not leaking data is 100% effective at not leaking data.

> still allowing them to interact with the outside world.

We know that revealing their personal information is harmful.   We know that this information is used, in real world situations, to cause harm to real people.   We do not know which specific sources are used, so it may well be that nobody is currently using the Received header field to do it.   It may be that the Received header field is not currently the weakest link.   However, it is clearly a weak link: as soon as I wanted to see what information my email was revealing, all I had to do was go to the ietf-smtp archive and look at my recent messages to the archive, and there the Received headers were, available for the world to see.

> already been demonstrated to be inadequate or unachievable.

Redacting IP address information from SMTP submission servers is very achievable, as witness the fact that the major email providers are doing it.   Whether it actually prevents peoples' demonstrably violated privacy from being used against them is indeed unknown.

---

From: Dave Crocker <[email-masked]>
Date: Wed, 2 Dec 2015 07:23:43 -0800

> Not leaking data is 100% effective at not leaking data.

A shame that has nothing to do with this thread or what I said.

>> At base, we don't know how to prevent folks from getting scammed,
>> while still allowing them to interact with the outside world.
> 
> We know that revealing their personal information is harmful.  

A shame that has nothing to do with this thread or what I said.

>> Lots of people are sure they know the right answer here, but none
>> of them can document efficacy.  Worse, most of the ways people cite
>> have already been demonstrated to be inadequate or unachievable.
> 
> Redacting IP address information from SMTP submission servers is very
> achievable, 

A shame that has nothing to do with this thread or what I said.

d/

---

From: Ted Lemon <[email-masked]>
Date: Wed, 02 Dec 2015 15:28:15 +0000

Wednesday, Dec 2, 2015 9:17 AM Paul Smith wrote:
> Eg, someone says to me "so and so received this message from me, but I didn't send it - has my laptop got a virus on it?" I can look at the IP address in the Received header and say, "no, that message came from China, someone's just spoofing your address",  or "it may have done, is your ISP 'bigisp.com'?" (or in some cases, "is your home IP address 1.2.3.4?" (if they have a static IP address))

This is email that your customer sent through your server (or didn't).   Suppose you didn't have the Received header with the user's IP address on it.   Are you really going to tell me that you couldn't use information at your disposal to give both of the answers that you proposed?

If it was not sent through your server, you don't even need to look at your logs to see that--it's in the Received header fields that you didn't redact, or rather, it's evident because your mail servers probably aren't mentioned in the Received header fields.   If they are, then you can go look at the logs to see what IP address connected to the server to drop that email; if the logs don't match the headers, it's fake, and if they do, you have the submitter's IP address.

I will grant you that the Received header field saves you some time, but it doesn't prevent you from answering the particular question that you are proposing as a motivating use case for not redacting it.   If this were a serious problem, you would spend a half hour to write a script that eliminated the time difference.

---

From: Dave Crocker <[email-masked]>
Date: Wed, 2 Dec 2015 08:02:55 -0800

Gentle folk,

There have been several days of postings from folk expert in this domain
of discourse, each carefully explaining the problems with various
assertions being made.  None of those postings seems to be effecting
much improvement in the conduct of this thread.

So it's time for folk making assertions of efficacy or inadequacy to
take the burden of documenting the validity of their assertions, as well
as explaining how they are relevant to a discussion of whether to
charter this wg.

d/

---

From: "John Levine" <[email-masked]>
Date: 2 Dec 2015 16:06:26 -0000

In article <[email-masked]> you write:
>-=-=-=-=-=-
>-=-=-=-=-=-
>> their password or SSN for a candy bar.
>

Hmmn.  If people are this unfamilar with practical user security, and
are unable to type "trade password for a candy bar" into Google, this
is going to be a very slow slog.

R's,
John

---

From: "Derek J. Balling" <[email-masked]>
Date: Wed, 2 Dec 2015 11:11:09 -0500

> Show your data or please stop making generalizations like this.   This is really not helpful.
http://news.bbc.co.uk/2/hi/technology/3639679.stm

-- 
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: Ted Lemon <[email-masked]>
Date: Wed, 02 Dec 2015 16:26:49 +0000

> is going to be a very slow slog.

John, what is deeply frustrating about this conversation is that every time I ask a serious question, I get an answer like this.   Did you look into that study?   Can you describe their methodology?   Did they identify potentially confounding factors that would introduce bias into the results?   Does their methodology account for those factors?   Do they make any sort of case at all for why their sample is a representative sample?   You don't know, do you?   You just read one of the clickbait articles that Google offered you.

The very study you are citing is actually used as an example of bad methodology in a textbook, _Elementary Statistics: Looking at the Big Picture_, by Nancy Pfenning.   Did the researchers check to see if the people they surveyed gave their actual birthday, or their actual password?   Or were they the ones who were scammed?   The survey was also done in 2004.   Do you think nothing has changed since then?

The reason this has become a slog is that nearly every answer I've gotten for a question I've asked, and nearly every criticism I've seen of a statement I've made, is of a similar level of quality to the answer you just gave me.  I don't mean to single you out--your example study is just too good an example not to use.

What this conversation has told me is that nobody on this mailing list actually knows the answer to this question: "what are the costs and benefits of redacting information from the Received header fields in email messages?"   You all think you know the answer, and your intuition is probably not completely invalid, but if we actually care what the answer to this question is, we probably do need to form a working group to study it a bit more seriously than we have done thus far, and we definitely can't rely on the assurances of supposed subject matter experts as to what the actual cost is.

---

From: "Derek J. Balling" <[email-masked]>
Date: Wed, 2 Dec 2015 11:32:31 -0500

I've been uncharacteristically (for me) quiet up 'til now, so let me --
perhaps naively -- say what, to me, seems like a simple thing.

1.) It's axiomatic that Received headers disclosure some level of
private data
2.) It's a matter of debate how valuable that data is to those who would
abuse it
3.) It's a matter of debate as to what impact redaction/removal of that
data from message headers would cause

Why isn't this as simple as chartering the WG to go off and:

1.) Document the answers to questions 2 and 3 above, with data
2.) If they so choose after doing #1, propose remedies or changes to the
existing methodologies consistent with the data they found above

At that point, everyone can observe the data, attempt to replicate it
(almost like a peer-review process, one would think) and then the
discussion can be about whether or not any proposal that came out of the
WG meets the larger goals of the net at-large.

It seems that it shouldn't be this hard to charter them to go off and
"crunch data" and "come up with a proposed solution consistent with that
data".

Nobody's "committed" to anything by letting folks go off and work on
this. so why is there such vociferous debate over letting them go do
that? What am I missing? (it's possible I have missed something, because
this debate is the most traffic we've seen in years on this list).

D

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 2 Dec 2015 16:43:58 +0000

> existing methodologies consistent with the data they found above

(With no hats) That seems eminently sensible to me. I'm sure
the specific text to describe the questions would need a bit
of work, but that oughtn't be too hard.

S.

---

From: Dave Crocker <[email-masked]>
Date: Wed, 2 Dec 2015 08:54:58 -0800

> of work, but that oughtn't be too hard.

1. That's an IRTF type of task, not an IETF type of task.

2. As sensible as the task might seem, the IETF pretty much never
requires documentation about expected efficacy.  That makes imposition
of such a requirement, here, discriminatory.

The original approach to chartering working groups was rather simpler:

  1.  Is there clear indication that 'the community' wants to do this,
by virtue of there being folk who want spend time on wg development and
they or other folk making noises about interest in implementing and
developing it?

  2.  Is there a clear understanding of potential /danger/ from doing this?

These days, we mostly stop at the first half of Question 1.  But we have
pretty much always left the question of 'efficacy' to the market.

d/

---

From: "Derek J. Balling" <[email-masked]>
Date: Wed, 2 Dec 2015 11:59:22 -0500

> pretty much always left the question of 'efficacy' to the market.
It seems to me that #1 is covered by virtue of the request existing in
the first place.

I would argue that #2 will be covered in whatever work-product the WG
comes up with (just as any other RFC would have to document
negative-impacts, lack of backward compatibility, etc.).

D

---

From: Dave Crocker <[email-masked]>
Date: Wed, 2 Dec 2015 09:24:41 -0800

> It seems to me that #1 is covered by virtue of the request existing in

Please re-read what I wrote a bit more carefully and consider the part I
said is mostly ignored, namely the second half of #1.  If you still hold
the view you stated, please explain how the second half has been satisfied.

> negative-impacts, lack of backward compatibility, etc.).

If there is no obvious problem with doing work in this space, then yeah
waiting until it's done to look for specific problems makes sense.  But
that's not applicable for the current type of work, as dangers of the
/category/ of work have already been cited.

d/

---

From: "Derek J. Balling" <[email-masked]>
Date: Wed, 2 Dec 2015 12:33:39 -0500

> the view you stated, please explain how the second half has been satisfied.
"Is there clear indication that 'the community' wants to do this". OK,
how do we determine that?
"by virtue of there being folk who want spend time on wg development"? 
It seems to be case that such people exist, or we wouldn't be having
this discussion. "(and) they or other folk making noises about interest
in implementing and developing it" It seems like this whole discussion
is that of "them and other folks" making noises about implementing and
developing it.
> If there is no obvious problem with doing work in this space, then
> yeah waiting until it's done to look for specific problems makes
> sense. But that's not applicable for the current type of work, as
> dangers of the /category/ of work have already been cited. d/ 
As the proponents of the WG have noted, the "big four" webmail providers
are already to some extent doing things similar to what the
WG-proponents are considering, and the Internet hasn't collapsed in pain
from their so doing. It seems, then, that any problems are, in fact,
non-obvious, as the ones which have been raised have been shown to be
(to some extent) overblown.

---

From: "John Levine" <[email-masked]>
Date: 2 Dec 2015 17:40:04 -0000

>can describe) so we can get more data to #3.  However, I suspect that we
>will find that the majority of "use-cases" for Received data are harmful
>to users, ...

Not surprisingly, I suspect the exact opposite, that there's a long
list of ways that networks and mail operators use Received data to
help and protect their users, and the harm is at this point largely,
maybe entirely, speculative.  Over on ietf-smtp, we've heard from
actual mail system operators describing the uses they make of it.

The fact that you can tell approximately where someone is is not a
harm unless and you can explain how that information has been used to
his detriment.  You can kind of tell where I am from my mail headers,
but since my name and address and phone number are in the phone book,
it's hard to imagine what the damage would be.

Arguments along the lines of well, somebody might do this are not
persuasive.  Anyone might do anything.  I would also be pretty
surprised if any non-trivial mail provider changed their practices
beyond what they do now.  I presume you've seen Ned's list of how
large mail providers do and do not display submission IPs.

R's,
John

---

From: Ted Lemon <[email-masked]>
Date: Wed, 02 Dec 2015 18:02:36 +0000

Wednesday, Dec 2, 2015 12:40 PM John Levine wrote:
> You can kind of tell where I am from my mail headers,

The damage is that there are quite a few John Levines in the world.   If you say something that triggers someone's desire to harass you, they will be able to use your IP address to determine that it is the John Levine who lives in Trumansburg who offended them, and then they can just google "John Levine Trumansburg" to dox or swat you.   This is _precisely_ the problem with revealing your IP address.   It took me about ten minutes to get your home address, and that's because I don't have any practice.   Without the IP address, I would have had no chance of figuring out _which_ John Levine to target with my notional swatting or pizza delivery.  It would have taken <1 minute to find your street address except that you did a good job of chaffing by using a P.O. Box.

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Wed, 2 Dec 2015 18:23:20 +0000

> -----Original Message-----
> From: ietf-smtp [mailto:[email-masked]] On Behalf Of Ted
> Lemon
> Sent: Wednesday, December 02, 2015 1:03 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [ietf-smtp] [Shutup] Proposed Charter for the "SMTP Headers
> Unhealthy To User Privacy" WG (fwd)
> 
> > You can kind of tell where I am from my mail headers, but since my
> > name and address and phone number are in the phone book, it's hard to
> > imagine what the damage would be.
> 
> The damage is that there are quite a few John Levines in the world.   If you
> say something that triggers someone's desire to harass you, they will be able
> to use your IP address to determine that it is the John Levine who lives in
> Trumansburg who offended them, and then they can just google "John
> Levine Trumansburg" to dox or swat you.   This is _precisely_ the problem
> with revealing your IP address.   It took me about ten minutes to get your
> home address, and that's because I don't have any practice.   Without the IP
> address, I would have had no chance of figuring out _which_ John Levine to
> target with my notional swatting or pizza delivery.  It would have taken <1
> minute to find your street address except that you did a good job of chaffing
> by using a P.O. Box.
> 

It took me 20 seconds using google and no IP Addresses were harmed in the testing - https://www.google.com/?gws_rd=ssl#q=john+levine. BTW John, congratulations on your page ranking. 

I've refrained from getting into this conversation but increasingly my sense is that Ted has a solution that is seeking a problem.

Mike

---

From: Richard Clayton <[email-masked]>
Date: Wed, 2 Dec 2015 18:22:18 +0000

In message <[email-masked]>, Derek J. Balling
<[email-masked]> writes

>is that of "them and other folks" making noises about implementing and

I'm unclear how many implementors and developers have chimed in so far.
The people whose names I have recognised have pretty much all been anti-
spam experts (working or consulting for large providers).

A concern would be that some of the enthusiasm for the process is people
may be planning to use the existence of an RFC as a stick with which to
beat into submission the implementors and the developers ("but you have
to do this, the IETF said so"). Now that may be the right way to
proceed, but I'm not entirely sure if the implementors and developers
would entirely concur.

Of course a sophisticated understanding of the different types of RFC
(and the precise meaning of SHOULD) makes this a non-issue, but that
understanding is thinly spread.

>WG-proponents are considering, 

I'm not quite sure what is being considered, so I would disagree for
that reason alone.

>and the Internet hasn't collapsed in pain
>from their so doing. 

I know many in Law Enforcement who are extremely pained that what used
to be a trivial exercise in processing header field data from MAGY to
assess whether an investigation will be easy is no longer practical.

This has put a big delay in the way of determining how best to pursue an
email related lead (or indeed to decide whether or not a case is
tractable at all).

That may not pain you, but I assure you it pains the victims, and no I'm
not going to spend the rest of the day providing references as to the
accuracy of that claim. but reading this might give some clues:

<https://www.lightbluetouchpaper.org/2015/11/20/the-emotional-cost-of-
cybercrime/>

Of course the triage that I describe would be in most cases satisfied by
a "blob" that gave AS number and a user identifier (allowing a view to
be taken regarding jurisdiction and number of incidents that would be
linked).

In fact a user identifier would work better than IP addresses which can
vary considerably and in the case of mobile are pretty much useless as
identifiers of people. But any work schedule needs to make clear if the
aim is to hide identity or location or both -- there's separate trade-
offs for each.

- -- 
richard                                                   Richard Clayton

---

From: Ted Lemon <[email-masked]>
Date: Wed, 02 Dec 2015 19:17:56 +0000

> <https://www.lightbluetouchpaper.org/2015/11/20/the-emotional-cost-of-

Does the linked article say anything to support the point you made above?   It's a study about the emotional impact of fraud, which I can tell you from personal experience, without reading the study, is pretty overwhelming, for many of the reasons cited in the study.

This is why I don't want 419 scammers to be able to scrape identifying info about my elderly relatives off of their email.

As for the cops to whom you refer, who aren't mentioned in the article you mentioned, they would probably benefit from reading the RFC we've been talking about writing, since I suspect some of the information they need would be captured in it.

---

From: "Christian Huitema" <[email-masked]>
Date: Wed, 2 Dec 2015 10:41:32 -0800

> may be planning to use the existence of an RFC as a stick with which to
beat
> into submission the implementors and the developers ("but you have to do
> this, the IETF said so"). Now that may be the right way to proceed, but
I'm
> not entirely sure if the implementors and developers would entirely
concur.

What makes you think that the pressure is not happening right now? Why do
you think that so many of the big-name e-mail providers are already
redacting some of the "Received" information? Do you really believe that the
pressure would stop if the IETF just remained silent? 

The WG process will ensure that the IETF provides careful and balanced
guidance, and hopefully uniform implementations. The absence of IETF process
will only ensure that the pressure and implementations will happen without
IETF guidance. 

-- Christian Huitema

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 02 Dec 2015 17:59:33 +0100

I believe that spending any time on answering #2 in a quantitative way
is a waste of time and will derail useful work in this area.  For me to
be able to geolocate Derek with sufficient probability as being close to
Kingston, NY, USA by looking at the email he sent below is sufficient
motivation for me to work on this.  I do appreciate and welcome help
from experts on #3 so we can describe the best solution to this problem.

I hope that some well-known larger domains will implement
draft-josefsson-email-received-privacy-01 (or something like it that we
can describe) so we can get more data to #3.  However, I suspect that we
will find that the majority of "use-cases" for Received data are harmful
to users, and that we can support the few good use-cases (like loop
detection) anyway.

/Simon

ons 2015-12-02 klockan 11:32 -0500 skrev Derek J. Balling:
> _______________________________________________
> Shutup mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/shutup

---

From: Rich Kulawiec <[email-masked]>
Date: Wed, 2 Dec 2015 16:47:08 -0500

On Wed, Dec 02, 2015 at 06:02:36PM +0000, Ted Lemon wrote:
> Without the IP address, I would have had no chance
> of figuring out _which_ John Levine to target with my notional swatting
> or pizza delivery.

Have you not heard of these things called "search engines"?

I found John's address in seconds (via DuckDuckGo, incidentally).

Those of us who have frequent occasion to track down online miscreants
have a wide variety of methods available to us to find them.  Sometimes an
IP address is one of the clues we use, but most often it's not, because
it's obvious on inspection that it belongs to a hijacked system (or it's
a complete forgery) and thus it means nothing.  I suggest reading some
of the impressive investigational work done by Ronald F. Guilmette for
detailed examples -- not only has he done the work, but he's written it
up in lucid fashion.

So the assertion here that the IP address is the key clue, or even
an important clue, is wrong.

---rsk

---

From: Rich Kulawiec <[email-masked]>
Date: Wed, 2 Dec 2015 17:51:24 -0500

On Wed, Dec 02, 2015 at 03:35:04AM +0000, Ted Lemon wrote:
> This is a stereotype, which very clearly is not grounded in any kind
> of serious, statistically sound survey of real-world users. 

Neither is my assertion that the ocean is wet, but everyone with
real-world experience knows it's true.

But if you really must: I suggest setting up an address, subscribing
it to at least a thousand different and topic/location-varied mailing
lists and then pushing all the incoming traffic through a procmail
filter that stashes everything for future analysis.  Then wait
a few years.  Or decades.  My corpus has about 25 years' worth of
traffic and is about 40G, gzip'd.  Message count is around 24M.
You can then, for example, write a script (or find one) that
strips off headers or signature blocks or whatever and tosses
them into a hopper for analysis.

What you will very quickly discover is that users are *deliberately*
handing out far more and far more useful information about themselves
than their mail servers are *incidentally* handing out.  You're fretting
over a tiny breadcrumb when there's a full buffet sitting on the table.

---rsk

p.s. Speaking of real-world users, if I want to know somebody's
(current) IP address, one reliable technique is to get them to click
on a unique link that corresponds to a URL on a web server whose logs
I can access.  Thus if I want Joe Cool to cough up his current
IP address, I can say:

	"Hey, Joe, why dontcha check this out?

	http://www.example.com/stuff-for-joe.html

	Thanks, man."

I can ask Joe to do this via any means available -- email, IM,
IRC, text, etc.  And "Joe", for a value of "Joe" approximating
"darn near everyone", will do it.  (If this were not true, then
phishing, drive-by malware downloads, etc., would not be so
incredibly successful.)  Various methods of encouraging Joe
to comply exist, as noted by Marcus Ranum:

	"There have been numerous interesting studies that indicate that
	a significant percentage of users will trade their password for
	a candy bar, and the Anna Kournikova worm showed us that nearly
	1/2 of humanity will click on anything purporting to contain
	nude pictures of semi-famous females."

(See http://www.ranum.com/security/computer_security/editorials/dumb/)

Like I said above: this is *one* reliable technique: there are many others.

---

From: Chris Lewis <[email-masked]>
Date: Wed, 2 Dec 2015 19:21:35 -0500

> Does the linked article say anything to support the point you made above?   It's a study about the emotional impact of fraud, which I can tell you from personal experience, without reading the stud…

The linked article does support why it's so important to prevent things 
like this happening, and why people like Richard (and myself and many 
others here) use items of information like we're talking about here to 
do just that.  Prevent it where we can, stop it getting through when we 
can, and help LE catch the guys doing it.  This is (part of) what many 
of us do for a living.

> This is why I don't want 419 scammers to be able to scrape identifying info about my elderly relatives off of their email.

Do you have any evidence that 419 scammers have any email from your 
elderly relatives that's amenable to scrape such info off of, let alone, 
have any use for such identifying information?  All they need is an 
email address and a trickable recipient.  Your elderly relatives have 
probably already put their street address, phone numbers, and photos of 
their pets (complete with geolocation in the JPGs) into the emails.

The perceived threat presented by archived mailing lists isn't so much 
about received lines (archives often don't contain much header detail 
anyway), but the addresses themselves.  That is what is of interest to 
419 scammers (and the spammer that spammed me less than 3 hours after 
creating this address for the sole purpose of this discussion!). 
Shouldn't this RFC be about obfuscating email addresses in mailing list 
archives?  It'd have more effect on 419 scammers.

> As for the cops to whom you refer, who aren't mentioned in the article you mentioned, they would probably benefit from reading the RFC we've been talking about writing, since I suspect some of the…

Here's the draft in question:

[This is brief draft critique, which you can ignore, except for the fact 
that it indicates why a WG is necessary]

https://tools.ietf.org/html/draft-josefsson-email-received-privacy-01

The only operative content is:

    The purpose of this document is to propose a mechanism that
    implementers and operators of SMTP agents may adopt to mitigate the
    privacy violation.

Note the "may adopt" - sounds optional right?

and then:

    The "from clause" of the Received header MUST NOT be added by SMTP
    entities concerned with the privacy of their clients.

1) Is there anybody out there dumb enough to assert that they're NOT 
concerned with the privacy of their customers? This is therefore 
tantamount to an absolute requirement, not an option, and could be 
treated as such and potentially enforced through the courts, as well as 
by providers using this as an easy-out to do nothing whatsoever when 
abuse is reported to them.

2) I don't see anything in there that would mitigate the loss of this 
information in either the descriptive text nor the example given - since 
the from clause is simply omitted rather than, for example, translated 
into a interpretable-only-by-the-provider identifier blob.

3) It entirely begs the question of when the information of potential 
privacy concern isn't in a "from" clause.  Such as providers who issue 
X-Originating-IP headers, "authenticated as x on y" clauses in Received 
or other headers, and perhaps even details of personal crypto key 
identifiers.  Protocol specifications are intended to be taken 
literally, a protocol specification that doesn't effectively do what you 
want is useless.

4) The security section has nothing about the downsides of removing this 
information or even hint at less-privacy invasive alternatives.

How much of this is really a social issue that has to be addressed with 
societal action compared to a technical bandaid that only helps in rare 
circumstances?  If you're concerned about, say, governmental 
surveillance, I'm thinking that fixing your government is better than 
(only occasionally) hiding just this teensy bit of information from them.

---

From: Chris Lewis <[email-masked]>
Date: Wed, 2 Dec 2015 22:58:30 -0500

> based on some other argument, but very much weakens confidence in

You will find no person more in agreement that we cannot train 100% of 
people with PSAs and similar (the fact that 419s still flow is certainly 
proof of that), but the reality is that most people do learn such things 
one way or another.  You have and I have, otherwise, we'd not be having 
this discussion.  Did you get your knowledge from a PSA?  Your parents? 
  School?  The media?  Nope.  But you still got it.

Trying to "measure" the result of training is usually futile, because 
correctly posing the questions, and getting useful answers is equally 
complicated and fraught with definitional/terminology problems.  I groan 
whenever these surveys are published, because the questions are badly 
crafted, the answers irrelevant, the interpretation is completely out to 
lunch, and the media scrambles it unrecognizeably.

And indeed, does the fact that 1% of people are still liable to fall for 
a 419 mean that the training, education, PSAs, news media coverage of 
such things etc was all in vain?  No.  is it effective?  Somewhat. 
Perfect?  No.

The subject is mushy.  People are mushy.  Measuring things that are 
mushy in 2+ dimensions is worse. But most of us have managed to survive 
vastly more dangerous circumstances by learning how to avoid them along 
the way.  It's slow, but it happens.  Just type in "how to use email 
anonymously" into your search engine, and voila!

> we make allows those who deploy that to do a good enough job.

Is hiding from clauses sufficient to do that?  No, not when the people 
who use email don't understand that what they put in the bodies of the 
emails is usually FAR more revealing than a temporary IP address in an 
Internet cafe does, or the fact that my MTA's IP address indicates, at 
best, I'm "somewhere in south, maybe eastern ontario".

Nothing you can do with from clauses will affect the bad guys looking at 
you.

Only the people already conscious/understanding of personal 
safety/privacy are going understand and make the choices that they need 
to make to preserve their privacy.  A mere from clause is not going to 
it, and claiming that eliding from clauses does anything significant to 
preserve privacy is in the end a dangerous lie even just in an email 
context.

> In

Please don't minimize it as just being "anti-spam".  I say I'm 
"anti-spam", but what that really means is anti-spam, anti-fraud, 
anti-malware.  The latter two have serious real-world consequences.  LE 
uses this to try to find people contemplating suicide, or equally, 
people making death/bomb threats or engaging in harassment.  ISPs use 
this to identify and inform customers that are infected with malware.

I (and several others here) could "document" some of what I've seen/been 
involved with where this matters, but that would in many cases (a) 
violate NDAs, (b) give the bad guys intel on how to avoid us, (c) 
probably violate privacy, and (d) since it's just me and not a vetted 
journal or something equally "reputable", some here will ignore it 
anyway as hearsay or self-serving BS.

[Which is ironic, because my work almost never involves MSA submission 
addresses, and it's not parsed let alone recorded.  I don't really have 
a horse in this race.]

This is real life too: user's savings and lives depend on some of this, 
not just a few annoying spam messages.

Yes, it would be nice for LE to say something, but the approvals 
required to say _anything_ whatsoever in public take a very long time, 
it'd probably get dismissed as self-serving hearsay, and as I've seen 
often, some people get all wobbly when LE is around.

It would also be nice for providers to say something, but the legal 
constraints of "speaking on behalf of/in public" are even worse.  When I 
did that once for a topic near to this, it took four months to get 
approvals and I had to go through a media relations course (until I 
pointed out that they didn't have to worry about be bleating out company 
future plans/finances because, unlike the senior executives normally 
taking the course, I couldn't possibly know any of that to leak).

---

From: Paul Smith <[email-masked]>
Date: Thu, 3 Dec 2015 09:20:11 +0000

> existing methodologies consistent with the data they found above
I have no problem with that. The problem I have is with the proposed 
charter as it is, which skips (1) and goes straight to 'how to remove 
data', ignoring the question about whether data should be removed at all.

---

From: Paul Smith <[email-masked]>
Date: Thu, 3 Dec 2015 09:26:31 +0000

On 02/12/2015 18:02, Ted Lemon wrote:
> The damage is that there are quite a few John Levines in the world.   If you say something that triggers someone's desire to harass you, they will be able to use your IP address to determine that it is the John Levine who lives in Trumansburg who offended them,

But you've got his email address...

taugh.com/contact.phtml says their address is in Trumansburg - there, I 
didn't need his IP address!

Try finding which town *I* live in without using my email address... :-)

---

From: Rich Kulawiec <[email-masked]>
Date: Thu, 3 Dec 2015 05:58:15 -0500

On Wed, Dec 02, 2015 at 07:21:35PM -0500, Chris Lewis wrote:
> Shouldn't this RFC be about obfuscating email
> addresses in mailing list archives? 

No, it shouldn't.  I'll leave out the lengthy argument against that
(for now) in favor of the bottom line: having examined that issue
at great length, the conclusion is that it's (a) completely pointless
in terms of security/privacy and (b) greatly diminishes the value
and utility of archives.

---rsk

---

From: Rich Kulawiec <[email-masked]>
Date: Thu, 3 Dec 2015 06:37:49 -0500

On Wed, Dec 02, 2015 at 10:58:30PM -0500, Chris Lewis wrote:
> anti-malware.  The latter two have serious real-world consequences.

This is an excellent point which bears repeating.  Those of us who
work on real-world mail systems have independently and collaboratively
developed numerous defensive techniques, some of which are designed
to defend our operations from the Internet, and some of which are
designed to defend the Internet from our operations.  While we may
use the shorthand "anti-spam" what we mean is probably closer
to "SMTP-borne threats" -- but that phrasing is a bit awkward.

Those threats are real, numerous, and increasingly sophisticated.
Sometimes they're standalone; other times they're coupled with
threats carried by other protocols or completely out-of-band.

Simultaneously, we grapple with the problem of dealing with email traffic
which *isn't* a threat but which originates from or transits mail systems
with (transient or long-term) issues.  The kind of information that
we use to stop threats is the exact same kind of information that we
use to deliver email that might otherwise be rejected.

Thus any reduction in that information must be *very* carefully
considered, as the two most likely and immediate outcomes are (1) an
increase in the number of SMTP-borne threats that reach their targets
and (2) a decrease in the delivery of benign (for lack of a better term)
email messages.

---rsk

---

From: Ted Lemon <[email-masked]>
Date: Thu, 03 Dec 2015 14:28:30 +0000

Thursday, Dec 3, 2015 6:37 AM Rich Kulawiec wrote:
> This is an excellent point which bears repeating.

No point bears repeating, particularly an assertion that solution X works for problems Y and Z without giving specifics.   Repeating the same assertion over and over again does not make it more true, and it is not the case that the other readers of this mailing list did not understand it when you said it the first time.

That said, as Dave Crocker pointed out, the actual topic of this thread is supposed to be whether we want to have a working group that does an analysis of this problem.   It seems that you care quite a bit about this, and given the current industry trend toward more header privacy, it seems to me that you would want to be able to take some time to do the work to provide data to back up the assertion that you are saying is so important.   So can we take your assertion as support for forming such a working group, and a willingness to participate in it?

---

From: Dave Crocker <[email-masked]>
Date: Thu, 3 Dec 2015 06:44:21 -0800

On 12/2/2015 7:58 PM, Chris Lewis wrote:
> one way or another. 

"Most people" do not.  Not even close to most people and very nearly
never any people consistently, since the ability of humans to perform
real-time and nuanced monitoring reliably like this, reliably and over
time, borders on no ability at all.

Feel free to provide documentation to the contrary.

The issue isn't whether people generally understand the general issue.
It's whether they can develop very specific understandings and apply
them in real time, to useful effect over extended time.

> complicated and fraught with definitional/terminology problems. 

Right.  That should alert us all to the challenges of the training itself.

d/

---

From: Ted Lemon <[email-masked]>
Date: Thu, 03 Dec 2015 14:53:36 +0000

> Try finding which town *I* live in without using my email address... :-)

Wow, you've got some _epic_ chaffing going on!   First, Melbourne, UK, not Melbourne, Oz.   And then apparently "Paul Smith" is a retailer of some sort, in both countries, and there's a Derbyshire council member named Paul Smith, etc.

I will admit that I am stumped, but this is a bit of a perfect storm.   Having a last name of Smith and a common first name is certainly a great way to avoid being targeted, although it's also been known to get people in trouble.   There is a Paul Smith who got in a bit of a jam for growing pot in his garage who lives fairly close to you.   (Or perhaps _is_ you!  :)

---

From: Ted Lemon <[email-masked]>
Date: Thu, 03 Dec 2015 14:57:20 +0000

Thursday, Dec 3, 2015 4:20 AM Paul Smith wrote:
> I have no problem with that. The problem I have is with the proposed charter as it is, which skips (1) and goes straight to 'how to remove data', ignoring the question about whether data should be removed at all.

I think there's consensus on this.   I certainly don't disagree, with the caveat that we don't actually have a choice about whether the data is going to be removed, just an opportunity to weigh in on whether that's a good idea.

---

From: Paul Smith <[email-masked]>
Date: Thu, 3 Dec 2015 15:48:21 +0000

On 03/12/2015 14:53, Ted Lemon wrote:
> I will admit that I am stumped, but this is a bit of a perfect storm.   Having a last name of Smith and a common first name is certainly a great way to avoid being targeted, although it's also been known to get people in trouble.
That's because "Paul Smith" is an awesome name :-) We even have our own 
Facebook group ;-)

Everyone should change their name to it, then no one would be able to 
find anyone, and all the privacy issues would be fixed instantly!

> There is a Paul Smith who got in a bit of a jam for growing pot in his garage who lives fairly close to you.   (Or perhaps _is_ you!  :)
No, that's not me (although growing pot in garages seems to happen a lot 
around here...), and I'm not the fashion designer either.

Of course, the opposite side of the coin is that if you're called 
"Hezekiah Feedlebump", no amount of hiding IP addresses is going to stop 
people knowing which one you are.

---

From: Chris Lewis <[email-masked]>
Date: Thu, 3 Dec 2015 15:13:29 -0500

> Feel free to provide documentation to the contrary.

I'm going to appear flippant, but I think it's appropriate.

Neither you nor I have been killed by a bus.  Every time we meet I 
"document" that fact by saying "hi Dave" and chatting a bit (or do you 
want to see my passport next time?).

In fact, very few people have been killed by buses.

That success is not part of our genetic makeup, it's not wired in.  It 
required training to achieve that, it's very real-time, and requires 
nuanced monitoring ("is that thing possibly going to hit me?" to a 
degree that technology cannot make us immune).  Nor does the fact that a 
few people have been killed by a bus mean that the training didn't work.

We can build the signs, the fences, the traffic signals and so on, but, 
none of that's going to save me if I walk around the center of the city 
with my eyes closed.

The reality is that trying to retain the privacy level that some people 
think they need to have cannot be done "reliably" and still permit the 
use of the Internet in the way that most people want.  If we want to 
"nanny" privacy to this level, we really should be talking about filters 
that prevent people from giving out their phone numbers, addresses, 
pictures of pets (with geolocation in the jpgs), and vacation schedules 
in email or anywhere else.

People have to partition what they do between "what must be kept 
private" and what doesn't need to, and use measures appropriate to their 
actions at the time.

> them in real time, to useful effect over extended time.

I contend that people can acquire general understandings (at least in 
this area) that requires no deep-dive into understanding the underlying 
technology to achieve the level of privacy they want, and in fact it's 
quite easy to a level far exceeding just removing "from" clauses. To 
whit: "If you want email privacy, use an anon remailer, there's lots 
listed on <search engine of choice>, and check out the reviews".

[My advice would also be "don't subscribe to IETF lists".  I've gotten 
11 spams in the few days since I created this email address to 
participate in this discussion.]

> Right.  That should alert us all to the challenges of the training itself.

Or, alert us that our measurement methods are completely bogus, and we 
really should be measuring it some other way.

While I have no way to prove this, I should think that the success rates 
of 419s is lower than it would have been in the society of 20 years ago. 
  If not, the human race is far stupider than anyone thought and we're 
all doomed.

[I should be careful in saying that, after having one experience 
intervening with one allegedly hi-tech astute husband and wife who were 
about to fall for the exact same phish for the second time.]

---

From: "Christian Huitema" <[email-masked]>
Date: Thu, 3 Dec 2015 12:27:32 -0800

On Wednesday, December 2, 2015 8:11 AM, Derek J. Balling wrote:
> > Show your data or please stop making generalizations like this.   This
is
> really not helpful.

That was a bit of stunt, polling people in the street outside a conference
room, designed to shock and grab attention with little attention paid to
demographics or study conditions. It is also 11 years old, and public
perceptions have evolved a lot since then, especially after the Snowden
revelations. For something a bit more scientific, balanced, and recent, I
recommend the Pew Research Center study on "Public perceptions of privacy,"
November 2014.
http://www.pewinternet.org/2014/11/12/public-privacy-perceptions/

The Pew Research study shows a fairly good awareness of privacy, a
widespread concern about surveillance by government and businesses, but also
a loss of confidence in the security of common communications channels. Most
say they want to do more to protect their privacy, but many believe it is
not possible to be anonymous online. And many of the responders were
actually taking steps to protect their privacy, however ineffective those
steps may be.

-- Christian Huitema

---

From: Hector Santos <[email-masked]>
Date: Thu, 03 Dec 2015 13:40:18 -0500

> I think there's consensus on this.   I certainly don't disagree, with the caveat that we don't actually have a choice about whether the data is going to be removed, just an opportunity to weigh in…

I don't get what is the big deal.  Established systems are going to do 
what is the best interest of their company, product line and 
customers.  While hiding, filtering information may be a new security 
consideration, its not going to change the 30+ years of default SMTP 
expectations, and in this case, the adding of a "Received" trace line, 
especially for an authenticated relay operation.  I expect  most 
products will make it optional where the default will what it is today 
in SMTP RFC 821 (STD10), RFC 2821 and RFC5321 operations:

  [X] Add Received Line
      [_] Hide/Mask IP

The biggest issue might be to decide whether any of this should be a 
SYSTEM or USER option. Right now, it is system wide option, but there 
has been many similar privacy consideration where it made more sense 
to make it a USER option (or an ADMIN option to set at the user level).

Also, this I-D is informational. Should it be standard track if it 
indirectly updates an existing standard (STD10) mode of operation?

     Side note: I have long had concerns of the IETF using 
"informational" docs
     as a fast track, lower threshold method as a means to an end.

Personally, If the WG is created, it should also consider looking at 
reducing redundancy and the major RFC5322 overhead in electronic mail 
that already exist.   Many headers are simply not needed at all and 
many do leak all sorts of user information.

-- 
HLS

---

From: Ted Lemon <[email-masked]>
Date: Fri, 04 Dec 2015 00:53:34 +0000

> In fact, very few people have been killed by buses.

The reason very few people are killed by buses, to the extent that this is even true, is not _just_ that people have learned to look out for cross traffic, although they certainly have.   It's that there is a whole system of traffic laws that try to make sure that the bus and the person who would be killed by it do not occupy the same space at the same time.   There are sometimes stringent, sometimes lax, but very real licensing requirements to operate a bus, and if you are hired to operate a bus, and turn out to be a dangerous driver, you will probably lose your job.   In addition, there are rigorous inspection requirements in most localities (and where there aren't, bus fatalities are not coincidentally higher).

I think your analogy is a good one, but I don't think the conclusion you drew from it made any sense, because you only accounted for the behavior that people engage in to avoid being hit by buses, and that behavior is probably less than half of the protection that's in place to keep them from getting hit.   Nobody is perfectly attentive.   You need a belt-and-suspenders system of defense if you are going to avoid accidents.

The same is true of email, and that's why we're having this conversation!

---

From: "Robert A. Rosenberg" <[email-masked]>
Date: Thu, 3 Dec 2015 20:29:42 -0500

At 13:40 -0500 on 12/03/2015, Hector Santos wrote about Re: 

>many do leak all sorts of user information.

Which headers do you regard as "not needed" and which leak user info? 
For the latter, please indicate if the header's existence in a 
message is under the control of the user's MUA.

---

From: "Robert A. Rosenberg" <[email-masked]>
Date: Thu, 3 Dec 2015 21:39:47 -0500

At 17:51 -0500 on 12/02/2015, Rich Kulawiec wrote about Re: 
[ietf-smtp] [Shutup] Proposed Charter for the "SMTP Hea:

>"darn near everyone", will do it.

If the message is HTML, then putting a 1x1 web-bug image in the HTML 
will trigger the info UNLESS the user's MUA is set to NOT 
automatically retrieve images.

---

From: Ted Lemon <[email-masked]>
Date: Fri, 04 Dec 2015 02:48:43 +0000

Thursday, Dec 3, 2015 9:39 PM Robert A. Rosenberg wrote:
> If the message is HTML, then putting a 1x1 web-bug image in the HTML will trigger the info UNLESS the user's MUA is set to NOT automatically retrieve images.

That retrieving images is the default behavior of most MUAs, and that it is even possible to do without cryptographically validating the ID of the sender in _any_ MUA, is an example of what I am talking about when I say that UI design is vitally important to protecting users' privacy.

Obviously if you have an MUA that behaves so stupidly, then your privacy is forfeit.   At present, that's most MUAs.   This is something that I hope MUA implementors will wise up to, and we ought to be advising them to if we aren't already.

There are some ways of fixing this without involving the MUA.   E.g., if a user gets email with links to images, rewrite all of the links to point to a proxy that has a mapping between each rewritten link and the original; if the MUA fetches against that link, proxy it.   This protects the end user's IP address without requiring that they install a new MUA, and should be the default behavior of every mail system (but I suspect isn't the default behavior of any, although I heard Google was contemplating doing something like this).

---

From: "Robert A. Rosenberg" <[email-masked]>
Date: Thu, 3 Dec 2015 23:14:21 -0500

At 22:58 -0500 on 12/02/2015, Chris Lewis wrote about Re: [ietf-smtp] 
[Shutup] Proposed Charter for the "SMTP Hea:

>Trying to "measure" the result of training is usually futile, 
>because correctly posing the questions, and getting useful answers 
>is equally complicated and fraught with definitional/terminology 
>problems.  I groan whenever these surveys are published, because the 
>questions are badly crafted, the answers irrelevant, the 
>interpretation is completely out to lunch, and the media scrambles 
>it unrecognizeably

Then there is the issue of "Push Polls" were the questions and/or 
responses to select from are deliberately designed to insure that you 
get the desired results you want since it is impossible to get any 
other result.

---

From: "Robert A. Rosenberg" <[email-masked]>
Date: Thu, 3 Dec 2015 23:53:10 -0500

At 02:48 +0000 on 12/04/2015, Ted Lemon wrote about Re: [ietf-smtp] 
[Shutup] Proposed Charter for the "SMTP Hea:

>>  If the message is HTML, then putting a 1x1 web-bug image in the 
>>HTML will trigger the info UNLESS the user's MUA is set to NOT 
>That retrieving images is the default behavior of most MUAs, and 
>that it is even possible to do without cryptographically validating 
>the ID of the sender in _any_ MUA, is an example of what I am 
>talking about when I say that UI design is vitally important to 
>protecting users' privacy.
>
>Obviously if you have an MUA that behaves so stupidly, then your 
>privacy is forfeit.   At present, that's most MUAs.   This is 
>something that I hope MUA implementors will wise up to, and we ought 
>to be advising them to if we aren't already.

As you can see from my X-Mailer header (which BTW [since we are 
talking about leaking info] leaks the fact that I am using a Mac and 
what MacOS Version I am running) I use Eudora. One of its settings 
(which I have set) tells the MUA to NOT fetch images and to wait 
until I click on the image icon to replace the icon with the actual 
image. Thus I see the icon whenever I am sent a Web-Bug in lieu of 
the bug calling home.

---

From: Chris Lewis <[email-masked]>
Date: Fri, 4 Dec 2015 10:30:55 -0500

> I am very curious to hear your numbers, as long as you explain how you got them.  I don't mean explain your spam algorithm--I mean characterize your sample, and explain why you think it's a good sa…

The issue here is even describing the methodology of comparing the test 
sets and the discussion about how it's very difficult to catch the same 
spam in other ways, reveals altogether too much information for spammers 
to use.

The numbers I've been able to give in these threads should be 
informative and are about as far as I can go.

> BTW, turning off the Received header field testing for a week isn't a valid methodology, since there's no way to control for the rather substantial variation in amounts and types of spam from week…

Actually, even though I'm not specifically measuring this over long 
periods of time (because the efficacious is already proven well enough 
to me and the systems who use the results which is what matters), I 
could readily provide time-series numbers that take into account that 
variation and demonstrate the usefulness of the technique.  But I don't 
think it worth the days worth of digging through old log files, and the 
exposure risk to the measurement infrastructure itself it would take to 
prove to you that I actually do know what I'm talking about.

> I don't think you could.   You've said enough things that don't actually make sense at this point that I would really need you to show your work, not just give me assurances like the following:

Your inability to make sense of what I've said is demonstrative of a 
lack of operational experience.  I don't like "I know, and can't tell 
you how, trust me" arguments from authority any more than you do. 
Ironically, most people say I talk far too much.  I like explaining 
things and do a lot of free training in the appropriately secured 
venues.  But sometimes I have no choice.

Sorry.

If you can tell me what I said doesn't make sense, maybe I could fix 
those bits.

---

From: Chris Lewis <[email-masked]>
Date: Fri, 4 Dec 2015 11:14:39 -0500

On 12/02/2015 08:50 AM, Ted Lemon wrote:
ch.

> So saying that because people don't care about privacy, we shouldn't try to protect their privacy, is wrong on two counts:

Claiming that's the stance of anyone here is wrong on several counts, 
not least being that a very large part of what we do is specifically 
aimed at anti-phishing (that "default no strangers" does little for 
these days, eg: address book spamming), and that's a vastly bigger 
privacy issue than a Received from clause.

The argument is that it's a relatively minor thing, the lack of which 
has worse privacy/operational and other implications, and there are more 
significant wins elsewhere.

Several years ago, a major anti-abuse industry organization invited a 
speaker from one of the privacy groups intimately involved with the 
issue of Syrian expats in the west being online harrassed, stalked and 
potentially harmed by SEA.  I had seen the reports earlier and did a 
little digging based upon what I could see (albeit rather indirectly, 
and without any contact with any of the true "point people" in the mess 
so it would be improper for me to act on my own).

The first thing out of his mouth was "I came here prepared with a 
diatribe about how your entire industry were endangering lives, and to 
my surprise learned that you were just as concerned about privacy as we 
are, and we should be treating you as allies".  After the end of the 
talk he was deluged with specific offers of assistance, which I think 
included taking down one of the sources of it (identified by headers 
such as the RFC wants to eliminate) I brought up in the Q&A: "Why is 
this still up?".

---

From: Dave Crocker <[email-masked]>
Date: Fri, 4 Dec 2015 08:54:54 -0800

On 12/4/2015 7:30 AM, Chris Lewis wrote:
>> I am very curious to hear your numbers, as long as you explain how you
>> got them.  I don't mean explain your spam algorithm--I mean
>> characterize your sample, and explain why you think it's a good
>> sample, and explain your methodology: what you did to the sample for
>> test A versus what you did for test B.   Interesting things to do for
>> the test sample to differentiate it from the control sample would be
>> removing the last Received header field entirely (last in sequence,
>> meaning first added), modifying the From clause for example as Stephen
>> Farrell suggested, or simply deleting the From clause but keeping the
>> rest of the last Received header field.
> 

There's a deeper problem with this line of query.

I believe we have reasonable consensus about the facts and about the
basic issues, from the various folk who spend fulltime working in this
space and have posted to this thread.

Hence, queries of the 'show your work' type move into the realm of
etended tutorial to non-experts, rather than helping to the vetting of
foundational issues for creating a working group.

Extended tutorial material is well and good in the right context, but it
is not typically considered appropriate for vetting a working group
creation effort.  Worse, I believe the tutorial exercise has been going
on for quite a few days now, which makes it costly, as well as wasteful.

d/

---

From: Chris Lewis <[email-masked]>
Date: Fri, 4 Dec 2015 12:51:03 -0500

> on for quite a few days now, which makes it costly, as well as wasteful.

Yes, you're quite right.

Backing up to the original mandate of this discussion:

I think it's fairly evident that the draft (and some of the discussions 
here are venturing into areas outside of the normal scope of IETF work 
(eg: social policy) and has insufficient practical experience to be 
adequately informed on how to accomplish the result, let alone the 
potential consequences from an operational/security/privacy perspective.

Work in this area can be immensely useful, but the candidate draft 
presumes too much and needs substantial re-work, probably to the point 
of starting over.  For example:

- Normative "MUST NOT" wording won't work in an IETF 
non-technical/non-interoperability policy-based supposedly optional choice.

- The draft has no understanding that the Received lines and other 
headers may well have exactly the same information in other than a 
Received "from clause".  IOW: the proposal doesn't come close to 
addressing the desired outcome.

- The draft makes no notice of the privacy, operational or security 
issues that can be impaired by the lack of such information.  IOW: the 
proposal may well do more harm than good even if only to privacy.

Before deciding what the draft should say, let alone before 
re-work/starting over, we need to have a proper discussion of the 
pros/cons of doing anything in this space, and if we do decide to do 
something in this space, identify what protocol details need to be 
addressed.

---

From: Ted Lemon <[email-masked]>
Date: Fri, 04 Dec 2015 19:37:36 +0000

> foundational issues for creating a working group.

I share your discomfort.   However, my concern with the approach of simply refusing to answer questions on the grounds you state is twofold: first, it excludes any participation by stakeholders other than anti-spam developers, and there are other stakeholders.   Second, it preserves the status quo, which is clearly broken.   By which I do not mean that you all are not doing good work: what I mean is that because you are so effective at minimizing spam, there is no incentive to actually clean up many of the messes you are working around at the moment.

>From my perspective, quite a bit of useful information has already been shared as a result of this discussion, and it would be nice if that information were collected somewhere.   I think that there's more work to be done.   It may be bothersome to folks who don't feel that these questions need to be answered, but I don't think it's realistic to think that if you just protest loudly enough, they will stop getting asked, or that the practice of header redaction will not become more widespread.

---

From: Rich Kulawiec <[email-masked]>
Date: Fri, 4 Dec 2015 15:42:29 -0500

On Fri, Dec 04, 2015 at 02:48:43AM +0000, Ted Lemon wrote:
> There are some ways of fixing this without involving the MUA.   E.g.,
> if a user gets email with links to images, rewrite all of the links to
> point to a proxy that has a mapping between each rewritten link and the
> original; if the MUA fetches against that link, proxy it.   This protects
> the end user's IP address without requiring that they install a new
> MUA, and should be the default behavior of every mail system (but I
> suspect isn't the default behavior of any, although I heard Google was
> contemplating doing something like this).

This doesn't adequately protect privacy.  For example:

1. Such links are often customized on a per-user per-message basis
with unique URLs.  Thus *any* hit on that URL from anywhere must
have come from that user [1] and via that particular message.
It may not disclose their IP address but it *does* disclose that
they read the message and when.  This is bad.

2. Proxying means proxy means proxy log means yet another place where
sensitive information accumulates.  I.e., I don't think it's a good idea
to attempt to fix this issue by MITM'ing connections.

3. How do you rewrite a link over an encrypted connection?

I'm not arguing that there isn't a massive privacy problem here.
There is, and I think it's far more worrisome than IP addresses
in Received lines, because it discloses far more information *and it
does so in real time*.  I just don't think solving it will be this easy.

---rsk

[1] Or someone they forwarded it to, and this is arguably worse.

---

From: Ted Lemon <[email-masked]>
Date: Fri, 04 Dec 2015 21:10:15 +0000

> they read the message and when.  This is bad.

Yup.  You have to always fetch, when the mail arrives.   Which could turn into a DDoS attack if you do it for all messages, so not ideal without additional heuristics.   But I don't see any way around those heuristics without simply deleting all URLs from all email messages.

> to attempt to fix this issue by MITM'ing connections.

You already have the whole email message if it's not encrypted, so I don't see that any additional information is leaking here.   But this is still a good point.

> 3. How do you rewrite a link over an encrypted connection?

If you are running the IMAP server, it doesn't matter whether the connection between the user and the server is encrypted.   If you are not, then it's not your problem.

> does so in real time*.  I just don't think solving it will be this easy.

Agreed on both counts.

---

From: Hector Santos <[email-masked]>
Date: Sat, 05 Dec 2015 13:48:10 -0500

>>From my perspective, quite a bit of useful information has already been shared as a result of this discussion, and it would be nice if that information were collected somewhere.   I think that ther…

Ted, as you know, many packages are quite old and well established -- 
change is not easy.  What is common is that we all need to interop in 
a consistent and persistent protocol required/expected manner. 
Without that, it doesn't work well.

Sure, it will be nice to read reports on methods, ideas, issues but 
for the most part much of this has already been covered.  So what else 
is possibly new after 30+ years of world-wide mail industry?

If it has been shown that the STD10/RFC2821/RFC5321.Received can be 
"exploited" in some negative way, then it doesn't really matter what I 
think, the customer can be potentially harmed and therefore, I am 
ethically obligated to offer an option to disable, hide or mask the 
"harmful" information.  So what are the ideas for this?  In the end, 
it may come down to changing the standard to say "MAY|SHOULD" instead 
of "MUST" IFF there is NO evidence of interop issues.

We do this all the time with product identification during any 
internet application protocol connections. For example, for PCI 
compliance, I have a very large customer whose PCI auditor pushed for 
the removal of all hosting product id/version identifying information. 
We made the option to disable available to the customer quickly and 
for others in the next update.  No more support cost issues along 
those lines whether I thought it as stupid or not.

I can say that PCI Auditors can push for (IETF protocol related) 
technical changes if the customers are hassled by them.  We have 
already begun to see the browser enforcement with the HTTPS only push. 
We long had a "Single Click PCI Compliance" button to enforces HTTPS 
and Session Tracking/Time Management.

However, most of the time, No one have have an answer for "Compromised 
User" issues. In that case, all bets are off.  Like a "Active 
Shooter," learn to track it and basically shut the account or force a 
changing of a password.

If the removal of the "Received:" trace line help mitigate a potential 
exploit, then I would like to see input from people who think it may 
be also a backward compatibility issue where "useful things" may break.

Now that I am thinking about it, I need to see how it could alter our 
SMTP valid RFC header detector during reception.

Technically, we can have Very Simple Mail Transfer Protocol (VSMTP) 
clients sending mail where the RFC 822/2821/5321 header block MAY NOT 
be part of the payload (DATA).  IOW,  you can do see this:

   C: EHLO mail.fugue.com
   S: 250 Welcome
   C: MAIL FROM <[email-masked]>
   S: 250 its all good
   C: RCPT TO: <[email-masked]>
   S: 250 continue
   C: DATA
   S: 353 What do you have to say?
   Hi there!<CR><LF>.<CR><LF>
   S: 250 Mail Accepted!
   C: QUIT
   S: 220 <click>

And that MAY be an acceptable transaction because the system will 
auto-fill or regenerate the required RFC fields or it may not, i.e. 
for a print or fax job, or if its a local message versus a relay:

   5322.From:    <--- 5321.MAIL FROM, Required
   5322.Date:    <--- Current Time Stamp (GMT), Required
   5322.To:      <--- 5321.RCPT TO, Not Required
   5322.Subject: <--- not required

At a minimum, most mail readers systems only needed the above fields 
for the simplest Mail Reader possible. I've written about 5-6 MUAs in 
my time.

However, the regeneration MAY NOT take place if it detects a valid 
internet email header.

So the question now becomes how tight is the SMTP requirements per site?

If the site follow strict RFC822, then you require:

    822.From:
    822.Date:
    822.TO or 822.CC

If you relaxed it to RFC2822 (which is the same as RFC5322), then only 
the 5322.From: and 5322.Date: are required.  The "To:" was relaxed, 
not required.  Once upon a time there was a I-D Proposal to further 
relaxed the "5322.From" header from email.  If that had happen, DKIM 
would probably never had been done even though today, many folks would 
probably not wanted the 5322.From: DKIM binding requirement.  Notice 
how there is a conflict here as well with Received since it also part 
of the Binding recommendations (but not a requirement).

In any case, in our SMTP RFC detector, we also use the the required 
"Received" line  depending on what level of 822/2822/5322 support is 
enabled.  I have to check.

So overall, it is not cut and dry about removing a long time 
"standard" required feature in SMTP.   It has to be studied before a 
recommendation can be made to effectively change a long time standard.

-- 
HLS

---

From: Rich Kulawiec <[email-masked]>
Date: Sat, 5 Dec 2015 16:51:10 -0500

On Wed, Dec 02, 2015 at 03:09:49AM +0000, Ted Lemon wrote:
> I don't think you could.   You've said enough things that don't actually
> make sense at this point [...]

So far, everything Chris has described makes perfect sense to me.
I can surmise some of the details because I've done some things that
are functionally similar, and because I've been reading Chris for years.

All of us who have tackled the problem of defending users from SMTP-borne
threats (of which spam is only one and often not the most important one)
have eventually found ourselves engaged in exercises in pattern recognition
quite similar to what Chris describes.  We may operate at different scales
or with different constraints, but we're all looking for ways to utilize
every/any scrap of information that we have.  (And we all understand why
it would be foolish to disclose the precise details of what we do in
a public forum.)

---rsk

---

From: Paul Smith <[email-masked]>
Date: Fri, 11 Dec 2015 09:57:05 +0000

On whether IP addresses are useful in Received headers...

This is something that happened to me yesterday:

A customer contacted me to say they'd been blocked by their ISP for 
sending spam. The ISP was less than helpful. The customer wanted to know 
if their network or mail server had been compromised in some way.

All they could send me was a bounce message they had received - the 
(redacted) headers are below:

Received: from zdku.org (unknown [14.176.165.34]) (using TLSv1 with 
cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate 
requested) by mx4.customers-isp.net (Postfix) with ESMTP id 
7424419CA0549; Sun,  6 Dec 2015 09:42:33 +0000 (GMT)
From:  <[email-masked]>
To: <various random people>
Subject: Fw: important message

 From that information I could instantly tell that the problem wasn't 
with the customer's mail server or a compromised PC on their network, 
but it was probably a compromised ISP password. The IP address was in 
Vietnam; our customer was in the UK - ergo the message didn't come from 
our customer.

If the ISP had put a cryptographic blob instead of the IP address, then 
ONLY the ISP could have identified where the message came from. If they 
had been willing to do that, they'd have looked at the IP address in the 
first place and realised what the problem was, rather than accusing our 
customer of spamming.

If we couldn't work out where the message came from, we may have spent 
ages virus scanning all our customers' PCs, checking firewalls etc, and 
still not fixed the problem.

Unfortunately, we see this too often where the ISP either doesn't know 
how, or can't be bothered, to perform basic forensics on email problems, 
leaving it up to those of us who do know how and can be bothered. If the 
information is removed, then that possibility is removed also.

---

From: Martijn Grooten <[email-masked]>
Date: Fri, 11 Dec 2015 13:24:29 +0000

> On whether IP addresses are useful in Received headers...

I don't think anyone has said that IP addresses in general can't be
useful in Received headers. Nor has anyone suggested to remove the
addresses of public facing mail servers from the headers.

I believe your example concerns such an IP address.

Martijn.

---

From: Paul Smith <[email-masked]>
Date: Fri, 11 Dec 2015 13:28:17 +0000

> I believe your example concerns such an IP address.
No, it was the IP address of a 'user' from the ISP's point of view. 
Something was logging into the ISP's mail server using a 
username/password. It was that 'something' whose IP address we needed to 
see to be able to tell whether it was coming from the authentic user's 
network, or somewhere else.

As far as I can tell, it's exactly that IP address which it is being 
suggested to obfuscate.

---

From: Martijn Grooten <[email-masked]>
Date: Fri, 11 Dec 2015 14:30:33 +0000

> No, it was the IP address of a 'user' from the ISP's point of view.

Ah yes, I see now.

I think a good ISP should show its customers which IP addresses were
used to log into the mail server. Doing so by adding them to the
Received header sounds like an unnecessarily complicated and noisy
way of doing that.

It's a good one for the still hypothetical BCP.

Martijn.

---

From: Ted Lemon <[email-masked]>
Date: Fri, 11 Dec 2015 14:38:41 +0000

> Received header sounds like an unnecessarily complicated and noisy

I think this is right.   A lot of what I am seeing here as examples are situations where someone with some technical know-how and a bunch of leaked info is able to give an end-user help that they otherwise would have not been able to get without the help of their service provider, with the result that the end-user continues to use the service provider that has utterly failed them.

What should actually happen here is that the end-user should say "huh, my service provider isn't helping me, I should switch to someone who provides better service."   By making it possible for Marlin B. Rando to diagnose their problem (at the expense of _everybody's_ privacy), you are not really helping them.   You are short-circuiting a feedback channel that would, if you didn't short-circuit it, actually do a better job of correcting the problem.

---

From: Paul Smith <[email-masked]>
Date: Fri, 11 Dec 2015 14:40:44 +0000

> What should actually happen here is that the end-user should say "huh, my service provider isn't helping me, I should switch to someone who provides better service."   By making it possible for Mar…
Unfortunately, the rest of us live in the real world...

---

From: Ned Freed <[email-masked]>
Date: Fri, 11 Dec 2015 06:32:26 -0800 (PST)

> addresses of public facing mail servers from the headers.

Actually, draft-josefsson-email-received-privacy-01 suggests just that. It
says:

   There may be other situations where adding Received headers would
   leak unintended information to an observing party.  For example, an
   organization may use different SMTP relays depending on the category
   of a customer.  By knowing the mapping between SMTP relay and
   customer category, an observing party would learn the customer
   category for the organization.

It then goes on to say that IP address information MUST NOT be added
by "SMTP entities concerned with the privacy of their clients".

				Ned

---

From: Ted Lemon <[email-masked]>
Date: Fri, 11 Dec 2015 14:48:42 +0000

> Unfortunately, the rest of us live in the real world...

As far as I know it's not possible to live in an unreal world.  But if your point is that most of us just have to accept garbage service, that's incorrect.   Mail service is widely available from competent providers.   There is no reason at all why anybody who is dissatisfied with the service they are getting from their service provider needs to stick with that provider.   Sure, it's nice that you're able to do your friend a favor by looking at the headers and telling them it's not an infected PC, but if you couldn't do that it would not _actually_ be a serious problem.   It would just be a different problem, with a different solution that wouldn't involve you.

---

From: Ned Freed <[email-masked]>
Date: Fri, 11 Dec 2015 06:48:37 -0800 (PST)

> What should actually happen here is that the end-user should say "huh, my
> service provider isn't helping me, I should switch to someone who provides
> better service." 

And give up the email address they've had for many years, which they have given
to all their friends and customers, printed on their business cards, subscribed
to mailing lists, and perhaps most importantly, attached to all of their
online accounts, some of which can only be changed by abandoning the account,
with all that implies?

Yeah, that's gonnna happen.

And this presupposes that the same user who wasn't knowledgeable about
email matters actually knows what services they should expect to get from
a "good" provider.

I've lost track of the number of times I've patiently explained to someone that
their problem was the result of crap service from their provider. I can count
on the fingers of no hands the number of times this has resulted in them
changing providers.

> By making it possible for Marlin B. Rando to diagnose their problem (at the
> expense of _everybody's_ privacy), you are not really helping them.   You are
> short-circuiting a feedback channel that would, if you didn't short-circuit it,
> actually do a better job of correcting the problem.

In an ideal world, maybe. But here in the real world we have to take factors
like provider lock-in into account in assessing these tradeoffs.

				Ned

---

From: Paul Smith <[email-masked]>
Date: Fri, 11 Dec 2015 15:23:46 +0000

On 11/12/2015 14:48, Ted Lemon wrote:
> As far as I know it's not possible to live in an unreal world.  But if your point is that most of us just have to accept garbage service, that's incorrect.
Yes it is incorrect that we have to accept garbage service. We don't. We 
use good service providers.

But that's not what I was saying. Trying to get a *customer* to change 
provider doesn't work. We suggest it all the time - there are many BIG, 
crap, providers in the UK, and most people use them, even though they 
are obviously crap. The users won't change, however much you tell them 
to. I think I could count on one hand the number of our customers who 
have changed from a rubbish provider to a good one in the past 10 years. 
I've lost count of the number who have gone the other way, against our 
recommendation, because the new provider is 'cheaper', or it's who the 
MD uses at home or something.

If we say, "we can't help, that's a problem with your ISP, you might 
want to consider changing", then the customer just thinks we're passing 
the buck, and gets annoyed with us, because there's no way that Big ISP 
Inc. can possibly have useless technical support. After all, it's a huge 
company and we're only a small one - thus the big company MUST be right.

---

From: Ted Lemon <[email-masked]>
Date: Fri, 11 Dec 2015 15:31:28 +0000

> online accounts, some of which can only be changed by abandoning the account,

Yes, once, so as to get out of the trap.   Honestly, this is not rocket science.   My sister, who is really not fond of computers, runs a nonprofit with its own domain, and her email address is in that domain.   She has a fully functional mail setup which, if Google stopped doing a good job, would be immediately transferable to another mail service provider.

My wife, who is a good web designer but not particularly conversant in mail headers, gets her mail service from a web hosting provider.   They have been doing a perfectly adequate job.   She has her own domain.   If they start sucking, she can switch to Google, or have me operate her mail service, or take some other option.   She is not locked in.

> on the fingers of no hands the number of times this has resulted in them

Right, you've been providing them with free support.  Why would they switch?   This is precisely my point.   You are their service provider, and you are protecting them from the hassles they would otherwise endure at the hands of their nominal service provider.   If you could no longer provide the help you have been providing because we closed down this privacy loophole, they would suddenly have some clarity about their situation, and maybe take action to do something about it.   And you could provide them with really good advice on how to do that in a way that avoids them being locked in again to their next mail service provider, if that provider should turn out to suck.

> like provider lock-in into account in assessing these tradeoffs.

I don't think that we should design protocols to account for provider lock-in.   It's not that hard to get out of a lock-in situation: start a new mail account that's not locked in, and gradually switch to it.   Use a high-entropy password on the old account so that the botnets can't crack it.   Done.   This is really just _not_ a hard problem, Ned.   Even if you have to keep the old account around in a read-only state for a decade, it's not a significant amount of money or effort.

---

From: Paul Smith <[email-masked]>
Date: Fri, 11 Dec 2015 15:31:42 +0000

On 11/12/2015 14:30, Martijn Grooten wrote:
> used to log into the mail server.
Yes, a good ISP probably should.

Can you tell me one who does?

When you have all ISPs/MSPs doing that, and all of them having at least 
one person who understands at least RFCs 5821 and 5822 on their customer 
support staff, and all of them having a human who will respond in a 
timely fashion to support or abuse requests, THEN maybe we can start 
looking at what that will allow us to remove from trace information.

In my experience, most ISPs (especially the popular ones) currently fail 
on all three of those things.

---

From: Martijn Grooten <[email-masked]>
Date: Fri, 11 Dec 2015 15:41:40 +0000

> by "SMTP entities concerned with the privacy of their clients".

I read this as talking about internal routes an email takes, otherwise I
wouldn't see who "their clients" refers to. 

(But my comment was wrong because I had misread Paul's email.)

Martijn.

---

From: Peter Bowyer <[email-masked]>
Date: Fri, 11 Dec 2015 15:43:33 +0000

On 11 December 2015 at 15:23, Paul Smith <[email-masked]> wrote:
>> As far as I know it's not possible to live in an unreal world.  But if
>> your point is that most of us just have to accept garbage service, that's
>> incorrect.
>
> Yes it is incorrect that we have to accept garbage service. We don't. We use
> good service providers.
>
> crap, providers in the UK, and most people use them, even though they are
> obviously crap. The users won't change, however much you tell them to. I
> think I could count on one hand the number of our customers who have changed
> from a rubbish provider to a good one in the past 10 years. I've lost count
> of the number who have gone the other way, against our recommendation,
> because the new provider is 'cheaper', or it's who the MD uses at home or
> something.

I've worked for several of them (the crap ones). Almost all of the
staff use a much better provider for their own services.

I've also seen some of the economics involved in the support operation
of BigISP - you can easily see how much the price of the service would
have to go up in order to provide people who know something about the
internet on the end of the phones. And the customer won't pay for
that.

(I'm guessing you knew this).

So the 'this won't work in the real world' is absolutely true. Much as
we would wish it wasn't.

Peter

---

From: John C Klensin <[email-masked]>
Date: Fri, 11 Dec 2015 10:48:42 -0500

--On Friday, December 11, 2015 06:48 -0800 Ned Freed
<[email-masked]> wrote:

>> What should actually happen here is that the end-user should
>> say "huh, my service provider isn't helping me, I should
>> switch to someone who provides better service." 
> 
> And give up the email address they've had for many years,
> which they have given to all their friends and customers,
> printed on their business cards, subscribed to mailing lists,
> and perhaps most importantly, attached to all of their online
> accounts, some of which can only be changed by abandoning the
> account, with all that implies?
>...

Yeah.

And _that_, if we really care about usability and privacy,
rather than proposing symbolic actions that decrease one and
don't help significantly with the other, is where we might
usefully concentrate some effort.  The use of an email address
as a primary account identifier and exclusive personal
identifier is a bad idea.  Most of us know it.   Mail provider
(or ISP) lock-in is high on the list of reasons, but think about
how most of us would react if someone told us that our street
addresses were now our identifier and therefore we could not
move, ever again, no matter what the reasons.

I share the general pessimism about trying to educate users, but
educating regulators to see forcing people to use email
addresses as identifiers as an anti-competitive action;
companies and financial institutions to understand that, if the
user switches email addresses, they may not be back; etc., might
be more plausible.  It isn't a protocol problem (although there
are protocols we could make more hostile to the use of email
addresses and other inappropriate strings as long-term
identifiers), but this is an area in which a clear
recommendation from the IETF or IAB might actually be helpful.

    john

---

From: Martijn Grooten <[email-masked]>
Date: Fri, 11 Dec 2015 16:01:38 +0000

> Can you tell me one who does?

MAGY, I believe (I've confirmed Gmail and Yahoo).

What I've been suggesting is not some kind of document that tells people
to remove submission addresses and other privacy sensitive information
from email headers. Rather, I am in favour of a document that explains
what mechanisms you need to have in place if you want to remove such
information.

Martijn.

---

From: Dave Crocker <[email-masked]>
Date: Fri, 11 Dec 2015 08:02:10 -0800

On 12/11/2015 6:48 AM, Ted Lemon wrote:
> As far as I know it's not possible to live in an unreal world.  

Arguably, that statement demonstrates the possibility...

> But
> if your point is that most of us just have to accept garbage service,
> that's incorrect.   Mail service is widely available from competent
> providers.  

Ned's 6:48am note explained rather clearly why the above is the wrong
line of analysis.

I saw two points in his note:

     1. "Switching costs"[*] for changing providers is high enough to be
a fundamental impediment.

     2. Average consumers lack the ability to do reasonable assessments
of providers.

Both of those assertions are factually and demonstrably correct.

> There is no reason at all why anybody who is
> dissatisfied with the service they are getting from their service
> provider needs to stick with that provider.  

In real-world terms, that statement is unrealistic.  To believe that
statement is to live in an unreal world, one that is simplistic and
populated by perfect actors who are not burdened with considering tradeoffs.

d/

---

From: Ted Lemon <[email-masked]>
Date: Fri, 11 Dec 2015 17:01:53 +0000

>> because the new provider is 'cheaper', or it's who the MD uses at home or

ISP != Mail Service Provider.   So this isn't really a response to what I said.   Most people I correspond with use gmail, which works very well--that's why most people use it.

> So the 'this won't work in the real world' is absolutely true. Much as

In the real world, if the dependability of your mail service is important to you, you will switch.  If it isn't, you get what you pay for, and that's okay.   It's not our job to be enablers for people who want to get something for nothing.

---

From: Ned Freed <[email-masked]>
Date: Fri, 11 Dec 2015 08:41:51 -0800 (PST)

> staff use a much better provider for their own services.

That's amusing.

> internet on the end of the phones. And the customer won't pay for

Another factor is how the service provider views the service. For some, usually
in the ISP space where providing basic email capabilities is an obligation,
email is a cost center, nothing more. In such coaes they'll do whatever they
can to keep costs down. And they don't care about customer retention for their
email service - in fact they'd prefer it if they would use another email
service provider.

For this sort of provider it's really all about support calls. Just having
a warm body at end of the phone line is expensive enough. Putting someone
there with anything other than a handful of scripts to read is just not
going to happen.

In fact the goal is to give service that's just good enough to keep customers
from switching to another ISP (assuming that's even a possibility), but not
good enough that they will ever bother to call in again.

And yet people still refuse to switch away from such services. Even the ones
that only offer POP, not IMAP and who force you to download all your mail.

				Ned

---

From: Paul Smith <[email-masked]>
Date: Fri, 11 Dec 2015 17:33:36 +0000

> ISP != Mail Service Provider.   So this isn't really a response to what I said.   Most people I correspond with use gmail, which works very well--that's why most people use it.
OK, so we're designing a system which only takes gmail into account? 
Sounds sensible...

I'm fairly sure that 'most' people do not use gmail. They have 900 
million "users", which is a lot, but given that many of those users will 
have multiple accounts, and will have accounts outside of gmail as well, 
saying that most people use gmail is a big assumption. Personally, I 
have 4 gmail accounts - they are all just used for testing, not for real 
life use, because it's not reliable enough for that for us.

For most people whom we encounter, their mail service is provided by 
their ISP, so while ISP != MSP,  most ISPs are also MSPs. So, discussion 
about mail standards doesn't just include gmail (and Yahoo and 
Microsoft), but thousands of big and small ISPs.

---

From: Ted Lemon <[email-masked]>
Date: Fri, 11 Dec 2015 17:40:04 +0000

Friday, Dec 11, 2015 12:33 PM Paul Smith wrote:
> OK, so we're designing a system which only takes gmail into account? Sounds sensible...

Paul.   That's a straw man argument.   I didn't say that.   I said that there are alternatives for people who are dissatisfied with the email service that's included with their ISP subscription.   So the fact that some services suck is not an argument in favor of privacy-compromising workarounds.   I even gave an example of another non-sucky service, and Martijn has also mentioned several.   Please retract your claws.

---

From: Rich Kulawiec <[email-masked]>
Date: Fri, 11 Dec 2015 12:54:50 -0500

> on the fingers of no hands the number of times this has resulted in them

Likewise.  Users are unwilling to accept that their choice of email
provider is very poor *and* they're unwilling to pay even a small amount
to switch from bottom-feeding "freemail" providers to paid services
that at least make a plausible try at being responsible/competent.

Note as well that many operations that should know better are also
miserable at getting even the basics right: as one example of thousands,
I have a user who's a customer of a credit union that has had broken
rDNS in place for over a decade, has been notified multiple times
about it, and still hasn't managed to fix it.  (And of course they
don't have a working "postmaster" address either.)

Expecting users to do something, no matter how rational we might all
concur it would be, is a known-failed strategy.

---rsk

---

From: Ned Freed <[email-masked]>
Date: Fri, 11 Dec 2015 09:04:33 -0800 (PST)

> My wife, who is a good web designer but not particularly conversant in mail
> headers, gets her mail service from a web hosting provider.   They have been
> doing a perfectly adequate job.   She has her own domain.   If they start
> sucking, she can switch to Google, or have me operate her mail service, or take
> some other option.   She is not locked in.

So the solution is for everyone to get their own domain, so their address
is portable? 

I'm sorry, but this is nothing short of delusional.

> Right, you've been providing them with free support.

And once again you have demonstrated that attempting to have a sensible
discussion with you is a total waste of time. 

Rather than acknowledge the demonstrable reality of provider lock-in,
you start strawmanning and moving the goalposts around.

I never said I provided anyone with anything resembling a substitute
for the support their ISP/MSP should have provided. I never even implied it.

Since you seem to be big on anecdotes, here are a few of my own:

Q. "Hey Ned, I'm having problems again sending to the X list you maintain.
   Why didn't it get through?"

A. (After checking logs.) "Because your provider botched their DNS setup and
   attempts to validate your message failed, resulting in a temporary error
   your provider apparently interpreted as permanent. I can't fix this and it's
   the fifth time it's happened; you need to switch to a better provider."

--

Q. "Hey Ned, you never sent me the stuff I asked for. Why?"

A. "I sent it; it bounced because your mailbox is full and I couldn't tell you
   what happened because, well, your mailbox is full.

Q. "What does "mailbox full" mean and how do I fix it?"

A. (30 seconds of googling.) "Your mailbox is full because your quota looks to
   be about 1/100 what modern email systems typically provide. You need to
   switch to a provider with reasonable quotas."

--

Q. "Hey Ned, I'm no longer getting mail from the Y list you maintain. What's
   going on?"

A. "I had to remove your address from the list because everything I sent to
   it bounces with a completely nonspecific error. You'll need to talk to
   your provider and find out what's going on. It's possible it's a problem
   on my end, but I can't fix it unless I know what it is."

Q. "OK, I called them and after an hour on the phone they say they don't know
   why it is happening and they can't do anything to fix it. What now?"

A. "Well, absent some kind of explanation of why they are rejecting the
   message, there's nothing I can do. You might want to consider switching
   to a provider that actually provides assistance when you call."

None of those people have switched providers. All of them continue to 
have problems with their current providers.

> Why would they switch?

Oh, I don't know, maybe because their ability to send and/or receive mail
reliably has been severely compromised by their provider and there's nothing
anyone else can do about it?

> This is precisely my point.   You are their service provider, and you are
> protecting them from the hassles they would otherwise endure at the hands
> of their nominal service provider.

Except that I'm not. I can't possibly perform the function, and the cases
where I've actually been able to solve a problem for somebody, as opposed to
telling them what the problem is, are so rare as not to matter.

> If you could no longer provide the help you have been providing because we
> closed down this privacy loophole, they would suddenly have some clarity about
> their situation, and maybe take action to do something about it.

Seriously? You actually think eliminating my currently nonexistent use of this
privacy loophole to provide an alternative support channel for people I know
would actually convince someone to switch providers? When the actual issues
they are demonstrably willing to live with are vastly more serious?

> And you could provide them with really good advice on how to do that in a way
> that avoids them being locked in again to their next mail service provider, if
> that provider should turn out to suck.

Right, so that instead of dealing with mail providers they'll instead be
dealing with a domain provider - a space I personally have considerable trouble
navigating?

> I don't think that we should design protocols to account for provider
> lock-in.

If we were designing protocols here I would say that it would make sense to
at least try to design things to make it harder for lock-in to happen.

But we're not designing protocols here. We're talking about advising
and/or tweeaking existing protocols, once which are deployed at vast
scale and which are highly constrained in a bunch of different ways.

A very different thing.

				Ned

---

From: Richard Clayton <[email-masked]>
Date: Fri, 11 Dec 2015 18:13:07 +0000

In message <[email-masked]>, John C Klensin
<[email-masked]> writes

>there
>identifiers

actually, as a community we have made it easier for organisations to use
email addresses as long term identifiers with the advent of RRVS

        https://tools.ietf.org/html/rfc7293

>, but this is an area in which a clear

I suppose we could deprecate it ?

- -- 
richard                                                   Richard Clayton

---

From: Chris Lewis <[email-masked]>
Date: Fri, 11 Dec 2015 13:24:14 -0500

> As far as I know it's not possible to live in an unreal world.  But if your point is that most of us just have to accept garbage service, that's incorrect.   Mail service is widely available from c…

By this measure, all the large free mail services are garbage because 
they simply cannot afford to provide the level of service you're 
implying - a single phone call puts them well into the negative income zone.

This also implies that you're introducing an economic/knowledge bias 
into the equation and an element of elitism (those who can afford). 
This is a really bad idea when we're talking about personal 
safety/privacy of people who are likely to be at the lower end of the 
income spectrum is it not?

Furthermore, if my comment about the wide availability of privacy 
protection systems (eg: email anonymizers, tor etc) wasn't good enough, 
why is "just switch to a better provider" (_if_ you know it's the right 
choice and can afford it) acceptable?

The reality is that very few providers are capable or willing to provide 
the level of service you postulate, paid for or not, for end-users. 
Doesn't matter what size they are.

In the real world most providers make it hard to make contact with a 
human, and at best you get access to a level 1 support person who has a 
script and is completely lost if you diverge off it.  There is no 
substitute for a level 3 or 4 or 5 who has a bit more personal interest 
in your success.

I don't see that changing any time soon, nor is it anything the IETF can 
do anything about.

---

From: Steve Atkins <[email-masked]>
Date: Fri, 11 Dec 2015 10:43:28 -0800

(Not replying to anyone, just injecting this into the thread)

A) This thread seems to have scattered into a a bunch of subthreads, none of which have anything to do with the subject line. Could we edit that when the thread drifts too far?

B) Is there an update to the proposed charter, based on the feedback so far?

C) Is there a community that's proposing this charter other than Ted? 

Cheers,
  Steve

---

From: John C Klensin <[email-masked]>
Date: Fri, 11 Dec 2015 14:53:56 -0500

--On Friday, December 11, 2015 18:13 +0000 Richard Clayton
<[email-masked]> wrote:

> In message <[email-masked]>, John
> C Klensin <[email-masked]> writes
> 
>> there
> actually, as a community we have made it easier for
> organisations to use email addresses as long term identifiers
> with the advent of RRVS
> 

I would categorize that work as "if one is going to do that, it
is better to get it right" rather than "making it easier" or
"encouraging it".  So I don't see any inconsistency between that
spec and a recommendation that use of email addresses as primary
personal identifiers is a bad idea.  YMMD.

    john

---

From: Ted Lemon <[email-masked]>
Date: Fri, 11 Dec 2015 20:35:16 +0000

Friday, Dec 11, 2015 1:24 PM Chris Lewis wrote:
> By this measure, all the large free mail services are garbage because they simply cannot afford to provide the level of service you're implying - a single phone call puts them well into the negative income zone.

I have a gmail account.   It gets very little spam, gets the email that real people send me, and delivers email from me to them fairly reliably.   And it's "free".   The test of a good service is not how good the customer service is when you call them: it's whether you need to call them.   In practice, I do not.

> This also implies that you're introducing an economic/knowledge bias into the equation and an element of elitism (those who can afford). This is a really bad idea when we're talking about personal safety/privacy of people who are likely to be at the lower end of the income spectrum is it not?

This argument seems like a non-sequitur to me.   It's certainly unfair that not everybody has the resources I do to bring to bear on this problem, but they do have very good options available to them, and TBH it's actually a royal PITA for me operating my non-gmail service.   I do it as a matter of principle, not because it's better.   If I were a little less annoyed about being spied on, I would just redirect fugue.com to gmail, and it would be a hell of a lot less trouble and work really well.

This is not to say that gmail is a universal panacea which will always be great.   It could start sucking next week.   But the point is that if you are going to claim that I am somehow privileged, I don't think you actually have much of a case to make.

> Furthermore, if my comment about the wide availability of privacy protection systems (eg: email anonymizers, tor etc) wasn't good enough, why is "just switch to a better provider" (_if_ you know it's the right choice and can afford it) acceptable?

If your email service is sucking, that's readily apparent.   You don't know that you need more privacy than you have until it's too late.

> In the real world most providers make it hard to make contact with a human, and at best you get access to a level 1 support person who has a script and is completely lost if you diverge off it.  There is no substitute for a level 3 or 4 or 5 who has a bit more personal interest in your success.
> 
> I don't see that changing any time soon, nor is it anything the IETF can do anything about.

I agree with everything here except the implication that if you can't talk to a person on the phone, the service sucks.   I would argue that if you are on the phone with a support person, that's the evidence that the service sucks.

A concierge-style email service that provides genuinely useful phone support really is going to be too expensive for regular folks.   What has brought the Internet to the masses is not the replication of what we all enjoyed as Internet users in 1995.   It's been the systematic removal of support costs from the system so that the price of service is low enough for regular folks to afford it.

Of course, we do occasionally hear horror stories who have been badly screwed by the inability to talk to a human, but that's actually good: those people (a) now understand why good email service is worth paying for and (b) are telling all their friends, or at least (c) are learning to be more careful about how they use the service (i.e., taking the support cost on themselves).

---

From: "John Levine" <[email-masked]>
Date: 11 Dec 2015 20:35:49 -0000

>I'm sorry, but this is nothing short of delusional.

I have to say I'm impressed at the way it allows us to move seamlessly
from the current argument between people who believe themselves to be
privacy advocates and people with actual experience who know it's more
complicated to the WHOIS contact proxy argument between people who
believe themselves to be privacy advocates and people with actual
experience who know it's more complicated.

R's,
John

PS: The reason I am a domain reseller is that it was easier to do that
than to keep providing free support to my users and friends who were
having problems with other registrars.

---

From: "John Levine" <[email-masked]>
Date: 11 Dec 2015 22:03:16 -0000

>>there are protocols we could make more hostile to the use of email
>>identifiers ...

>I suppose we could deprecate it ?

Not until we come up with something better.

People usually* know what their e-mail addresses are, and this avoids
a step where people try to invent a user name and keep being told
nope, already taken.  So I'm jlevine, jrlevine, jrlevine2, and so on
and so forth.  That's not going to fly.

OpenID would be nice if it worked better and it weren't usually tied
to an e-mail address.

R's,
John

* - give or take all the ones who imagine that my gmail address is
their gmail address

---

From: Ned Freed <[email-masked]>
Date: Sat, 12 Dec 2015 06:25:54 -0800 (PST)

>         https://tools.ietf.org/html/rfc7293

I have to say I never thought of it that way before, but of course you're
right.

> > but this is an area in which a clear

> I suppose we could deprecate it ?

You're joking, of course, but this is worth a moment of serious consideration.

Provider and thus email address lock-in is clearly to the advantage of ISPs and
MSPs that view their email service as a source of revenue (ads, branding,
marketing data, whatever). As such, not only will they have no interest
in any move towards eliminating that lock-in, they may well be actively
antagonistic towards it.

And at this point I fear that the shift to the use of such providers has
reached a point where anything the IETF says or does is going to be irrelevant.

				Ned

---

From: Dave Crocker <[email-masked]>
Date: Sat, 12 Dec 2015 07:11:32 -0800

> reached a point where anything the IETF says or does is going to be irrelevant.

You are probably correct on both counts, but I suspect neither point
matters very much.

There is such a strong, general, natural proclivity for using email
addresses as identifiers, nothing has shown even the slightest ability
to replace them, unless one counts a few different identifiers like
Twitter hashtags, which really are roughly equivalent to email addresses
(where the hashtag itself serves as the @twitter.com semantic.)

My point is that the fact that an address is unique and is heavily used
for regular interaction, makes it an identifier.

There have been various efforts to create 'permanent' identifiers that
are independent of email addresses, or the like.  None has succeeded.  I
believe ISP market pressures were irrelevant to those failures.

d/

---

From: Hector Santos <[email-masked]>
Date: Sat, 12 Dec 2015 11:30:19 -0500

On 12/3/2015 8:29 PM, Robert A. Rosenberg wrote:
> For the latter, please indicate if the header's existence in a message
> is under the control of the user's MUA.

Hi Robert,

Taking a step back, at a minimum, based on the history of the mail 
systems in my multi-network 30+ years of design, developing, marketing 
and support experience of mailers (MSA/MDA/MTA, gateways) and 
readers/writers (MUAs), again, at a minimum, all that was needed were:

   From:
   To:
   Date:
   Subject:

At a local, centralized level, you don't need any other header.  In 
other words, if you were brand new in writing any mail system, not 
necessarily RFC-based, that is what you will begin with in your UI.

Only when we began to "network" mail systems, added additional 
"Network Control Lines"  were helpful and fundamentally, the goal was 
to be able communicate back and forth (replies).  Back in the day, if 
you couldn't send mail directly, perhaps it was more costly, i.e. toll 
calls,  you routed the mail via your "hubs" during non-prime time hours.

These headers were the common denominator. Everything else was 
"optional" and even the subject line can be blank and incidentally, 
what are required by RFC5222 are the From: and Date: headers.  The To: 
was relaxed in RFC2822. That's it!

At the end of the day, we are talking about three different things:

  -  Transport Requirement (minimum basic communications framework)
  -  Administrator Requirements (Operator/Local Policy Options)
  -  End User Requirements  (Offline, Online, Hybrid MUAs)

The IETF has been mostly concerned about the transport protocol. 
Making sure all the SMTP, POP3, NNTP, IMAP systems can communicate. 
While implementation details and end-user requirements has always been 
challenging and in conflict over the years (because each vendor has a 
"preferred" way of doing things), we try to extract the commonality by 
minimizing conflict of interest.  I call it "Cooperative Competition."

The key thing to remember is the main goal of this mail tool -- to 
communicate to someone and to allow for an respond mechanism.

Look at the MUA, there are various types; OFFLINE, ONLINE and HYBRIDS. 
  From a UI, standpoint, the above headers would be the first headers 
to add to your interface. They are what most users will need and what 
most people are familiar with.

So the question is what additional headers are needed and why?

Well, we do have the "Reply-ID" and by design, it overrides the 
"From:" for a response.    It works well for One to One mail systems, 
and you know the history of how it is been leveraged in One to Many, 
Group-ware systems, i.e. Mailing list.

Is the Message-ID required?  Who adds it?  It is dependable as a "Dupe 
Detector?"  It probably is, but our system does bot depend on this 
header for dupe detection, Our system has a proprietary dupe detection 
mechanism because its not just about a RFC based mail storage system. 
Someone or something can post a duplicate message online before any 
RFC headers are added which by the way are only added when they 
exported for an RFC-based network!! :)

DKIM-Signature also leaks information. USer-Agent,  X-Mailer, and 
basically the X-xxxxx headers do, especially the "Anti-Spam" ones. 
There are slew of headers that leak information about a transaction.

Anyway, I think we can have a BCP that is basically a table of all the 
headers accumulated over time, with a new view of RFC2119 level of 
compliance with technical information, common implementation and 
interop details.    Just start with all the headers in your message, 
sorted:

Archived-At:
Cc:
Date:
From:
Sender:
Subject:
To:

There is a lot of junk there.

But to answer your MUA question, which header(s) it has control of.

The short answer is none. Unless, you want to say the Reply-ID is 
probably an important header the MUA is inserting into the transaction 
(if the user prepared it). But as we know, the MUA doesn't really have 
control of it in many MLS (Maiing List System/Server).

Think about it. By the time I get your message from my hosting server, 
the MDA, it is already authorized mail in order to accept it.  Many 
filters are applied and by the time the import takes place, it has two 
ADMIN (and relatively recent an USER) options at my server:

   (o) Preserve MIME mail (Keep RFC intact)
   (_) Convert to Wildcat! Format

The default was to convert to the proprietary format of the box. So 
you have to set it if you want the RFC overhead.  Only with the advent 
of the OFFLINE mail readers and greater WYSIWYG (HTML/MIME) needs, 
users required the preservation of "raw" RFC mail as it came in.   So 
by the time the host server passes it to my reader during a mail 
pickup, all I have to make sure is set the above headers in a 
reconversion back to simplified RFC MIME 1.0 format.   That is 
OFFLINE.  In an ONLINE MUA (i.e. web browser, Telnet, etc), the 
backend has full control of the display.  It has the freedom to do 
much more without compatibility conflicts.  No conversion back to RFC 
necessary.

Of course, it had become more complicated when you want the NATURAL 
"Reply" button to do the right thing. But before List-ID became 
popular with the MLS,  many MUAs did not support this.  So that is one 
reason the Reply-ID was added with the list address. If the List-ID 
was prevailing early on, perhaps the MLS would not had redesign to use 
the Reply-ID.  Now the the List-ID is widely popular, perhaps in the 
next MLS update, we can disable using the Reply-ID out of the box.

But the point is, that no other header is simply not required and I 
think, at best, because we have many disciplines to deal with,  all we 
can do is go thru all the headers and provide guideline regarding the 
MUST, SHOULD and MAYS for current and future developers.  Its good to 
know what the "big guys" are doing, but that doesn't necessarily mean 
it should be made into a IETF mail standard or mandate.  In fact, we 
have to be careful of the potential conflict of interest.

I know our system is probably unlike others, and we can state we are 
only dealing with pure RFC to RFC networking, sure, but the reality is 
that its not always that cut and dry.  There are an awful lot of local 
proprietary processing that can do anything to the mail, and the the 
time the user sees it, they might be just the above headers for the 
most part, and perhaps a MODIFIED body with a special BODY HEADER:

   From: Hector
   To:  Robert
   Date: ...
   Subject: ....

   *THIS MESSAGE WAS DKIM VALIDATED BY SO AND SO and other MSA/MDA,
    User information tacked on as a BODY header*
   *To see Authentication/IP information, click here, password required*

   My actual message.

   ---
   HLS

I actually did this for a NNTP Bridge/Gateway (WCLEX, Wildcat! Live 
eXchange http://opensite.winserver.com/wclex) I wrote for Microsoft 
when they deprecated the Microsoft NNTP Newsgroup support servers for 
a MSDN WEB-BASED system.  Fortunately, MS provided the .NET-based API 
hooks and WCLEX provided a great transition tool.   But what it did 
was to add the BODY HEADER to show some the Web-Based User Data 
points, i.e. number of replies, how many stars you have, etc because, 
of course, the MUA was not ready for these type of new interfaces.

-- 
HLS

---

From: Hector Santos <[email-masked]>
Date: Sat, 12 Dec 2015 12:13:51 -0500

> (where the hashtag itself serves as the @twitter.com semantic.)

I have seen a common "change" with many popular sites with the push to 
grab cell phone numbers. Facebook is constantly peppering the user to 
allow it to use the PHONE NUMBER it has already grabbed from you.  It 
doesn't understand the concept of "No! Stop Asking for it!"  and  it 
doesn't understand the concept "Who gave you permission to grab it in 
the first place."   Lots of "lost ethics" in the new generation of 
programmers!!

That said, for future updates, I have also penciled in idea of looking 
at using additional identifiers, including the cell phone once I find 
an public domain method for sending a notification. <g>

> for regular interaction, makes it an identifier.

+1.

> believe ISP market pressures were irrelevant to those failures.

A few years ago, the NIST had been trying to push the idea of a 
National ID (or more so the trust vendors were proposing new NIST 
initiatives). But I think the strategy has changed to a 
"De-Indentification" strategy according to my quick review.

De-Identification of Personally Identifiable Information
http://csrc.nist.gov/publications/drafts/nistir-8053/nistir_8053_draft.pdf

-- 
HLS

---

From: "Robert A. Rosenberg" <[email-masked]>
Date: Sat, 12 Dec 2015 14:19:49 -0500

At 22:03 +0000 on 12/11/2015, John Levine wrote about Re: [ietf-smtp] 

>* - give or take all the ones who imagine that my gmail address is

I know have you feel. I have an AOL address that I have had since AOL 
started and I have at least lots of people who seem to think it is 
theirs and use it. Right now I am getting email from a Doctor's group 
and a Condo in California. Worse I get credit card statements, hotel 
reservation, etc. to that address. I wonder what they think when they 
never get their email. I have given up on sending a message to the 
contact for a list to contact the person some other way to get their 
correct email address. Once or twice when the message has had a Phone 
Number or Snail Mail address I make the effort to contact them to 
tell them but in most cases I do not bother to contact them or to 
unsub from the list.

---

From: "Robert A. Rosenberg" <[email-masked]>
Date: Sat, 12 Dec 2015 15:12:41 -0500

At 09:57 +0000 on 12/11/2015, Paul Smith wrote about Re: [ietf-smtp] 
[Shutup] Proposed Charter for the "SMTP Hea:

>sending spam. The ISP was less than helpful. The customer wanted to 
>know if their network or mail server had been compromised in some 
>way.

The Message-ID might also help point at the message not coming from 
the user. It is not an IP Address but it does show which mail server 
which was used to inject the message,

---

From: Steve Atkins <[email-masked]>
Date: Sat, 12 Dec 2015 12:30:18 -0800

> On Dec 12, 2015, at 7:11 AM, Dave Crocker <[email-masked]> wrote:
> 

> believe ISP market pressures were irrelevant to those failures.

Your cellphone number, your facebook GUID and, to a
lesser degree, your twitter name are used as identifiers (and so also
authentication) in a lot of places. For many services your facebook
GUID or cellphone number is preferred, and use of an email address
as identity may not be supported in MVP (or in some cases, at all).

Those are centralized[1], though, which makes it easy for them to be
unique.

It's possible to create a unique identifier without any checking for
uniqueness - you could use a type 4 GUID, for instance. Not terribly
memorable, though, so unless you want to require people to carry
key stores around and copy them to every device - including public
access points - they want to use it's not going to work well for
real users.

If you want an identifier that is globally unique and federated then
you need some part of the identifier to be a unique identifier for
the identity provider you use, along with some additional information
per identity provider to guarantee uniqueness within that identity
provider. (e.g. OpenID, which uses DNS hierarchy to create IDs).

Any federated identity system is going to have all the portability disadvantages
email has, as well as some additional ones.

Cheers,
  Steve

[1] Phone numbers are kinda federated, but as an implementation detail.
They're effectively centralized from a users perspective, as far as "Put
a quarter into the ITU, get a unique number back" is concerned.

---

From: Dave Crocker <[email-masked]>
Date: Sat, 12 Dec 2015 17:10:38 -0800

> lesser degree, your twitter name are used as identifiers (and so also

1. Phone number:  in theoretical terms it works as an identifier.
However there have been attempts to get it used as an alternative to an
email address and there's been no traction.  The string has two strikes
against it.  First, it's not human friendly, compared with a string that
has sematnics.  Second, people don't see or use it all that often. (I
suppose these days, given email UI design, the same could be said for an
email address... mumble.)  And BTW, phone number only sometimes -- maybe
even often, but not always -- maps to a specific individual...

2. Facebook, google, etc. identifiers.  These are independent
namespaces, but ultimately translate into an email address.  The
invocation character (hash, at-sign, whatever, replaces the
@<service-provider>.com string.  I'm not quibbling here.  These really
are alternate encodings for the same construct.

> as identity may not be supported in MVP (or in some cases, at all).

I'm not sure the security uses of these qualify as 'identifier' rather
than getting used for a confirmation exchange, which means using them as
an address.

> memorable, though, so unless you want to require people to carry

Exactly.  Usability is an essential feature.  Email addresses seem to
strike a reasonable balance in that regard, absent left-hand-side
conventions at a provider that gives you a serial number.

> the identity provider you use, along with some additional informatio"

"identity provider" that is independent of a regular service provider is
an excercise that's been attempted a few time.  None got traction.
Maybe openid will.  Heh.

> email has, as well as some additional ones.

Yeah, like maintaining synchrony with an adddress...

d/

---

From: "John Levine" <[email-masked]>
Date: 13 Dec 2015 02:18:34 -0000

>email address and there's been no traction.

>And BTW, phone number only sometimes -- maybe

How many apps do you use on a phone or tablet?  Lots and lots of them
use your mobile phone number as the identifier, since everyone knows
his own number, and mobile phones are quite personal.  Of course, bad
programmers are everywhere, and since my tablet has no phone number,
well, um.

I'm certainly not saying it's a great idea, but it's got plenty of
traction.

R's,
John

---

From: "Robert A. Rosenberg" <[email-masked]>
Date: Sun, 13 Dec 2015 00:44:26 -0500

At 09:04 -0800 on 12/11/2015, Ned Freed wrote about Re: [ietf-smtp] 

>    switch to a provider with reasonable quotas."

If they are unwilling to switch providers, there is also the option 
(if using POP) of checking more often since (unless you say Leave on 
Server) that will clean out the Server Mailbox as you download. I 
helped a user who had this issue as well as a connection that would 
drop. I set the account to check often enough that the Server Mailbox 
did not fill up, marked it as "Leave On Server", and set a filter 
that marked the messages as "Delete From Server". That caused the 
successfully downloaded messages to get deleted during the next 
capture pass. I admit that it was a 2nd class Band-Aid but so long as 
the user would not change connectivity and hosting services it was 
the only viable solution (other than have GMAIL scrape the mailbox to 
keep it empty).

---

From: "Robert A. Rosenberg" <[email-masked]>
Date: Sun, 13 Dec 2015 01:13:23 -0500

At 11:30 -0500 on 12/12/2015, Hector Santos wrote about Re: 
[ietf-smtp] [Shutup] Proposed Charter for the "SMTP Hea:

>systems in my multi-network 30+ years of design, developing, 
>marketing and support experience of mailers (MSA/MDA/MTA, gateways) 
>and readers/writers (MUAs), again, at a minimum, all that was needed 
>were:

THANK YOU VERY MUCH for taking the time and effort to issue the 
detailed reply to my query. I now have a much better idea of your 
views on leaking and headers.  Due to email and handling there of has 
evolved, we must live with the result and things that would have been 
done and/or supported if the system had been designed from scratch 
are not possible. Note that this comment is not intended to imply we 
should start all over with a replacement email infrastructure but 
just acknowledging the situation. All things considered I think we 
have done a great job of evolving the original text-only email system 
to what we have now (MIME Support being a good example).

---

From: Dave Crocker <[email-masked]>
Date: Sun, 13 Dec 2015 07:11:39 -0800

On 12/12/2015 6:18 PM, John Levine wrote:
> his own number, 

The problem is that everyone does not know /every else's/.  That's the
usability issue.  Acquisition and recall by /others/.

d/

---

From: "John Levine" <[email-masked]>
Date: 13 Dec 2015 15:26:41 -0000

>Server) that will clean out the Server Mailbox as you download.

For the large fraction (probably a majority now) of people who read
their mail on their phones, the only option is IMAP and there is
nowhere but the server to keep the mail.  For reasons already
discussed people don't want to abandon an address that all their
friends have in their address books, so they resort to painful kludges
like setting up another "secret" address at a provider with a giant
quota and forwarding the mail there that they want to keep.

Ned's point remains that the pain of switching addresses is
substantial, expecting everyone to get their own vanity domain is
absurd, so there is and will continue to be considerable friction
even for lousy mail providers.

R's,
John

---

From: Ned Freed <[email-masked]>
Date: Sun, 13 Dec 2015 07:43:22 -0800 (PST)

> the only viable solution (other than have GMAIL scrape the mailbox to

Telling people they can't use their mobile device as an email client is an
even bigger nonstarter than telling them to switch providers.

				Ned

---

From: Dave Crocker <[email-masked]>
Date: Sun, 13 Dec 2015 08:20:16 -0800

> even bigger nonstarter than telling them to switch providers.

Heuristic:

  If the vast majority of users behave a certain way, telling them that
they must change produces an effort that is both useless to the industry
and irritating to the users.

  When that majority is millions or billions of users, the suggestion
moves from impractical waste to silly insult.

Anyone taking exception to this view needs to provide very explicit
analysis of the adoption and use scenario that will make the proposal
successful -- and they need to cite the evidence for its practicality.

d/

---

From: Ned Freed <[email-masked]>
Date: Sun, 13 Dec 2015 08:37:16 -0800 (PST)

> successful -- and they need to cite the evidence for its practicality.

Nicely put.

				Ned

---

From: Paul Smith <[email-masked]>
Date: Sun, 13 Dec 2015 17:38:37 +0000

On 12/12/2015 19:19, Robert A. Rosenberg wrote:
> Number or Snail Mail address I make the effort to contact them to tell 
> them but in most cases I do not bother to contact them or to unsub 
> from the list.
>
It's not just gmail.

We get people using our pscs.com domain as if it's theirs as well... I 
frequently get emails asking me to approve access to websites on 
pscs.com addresses. I also have emails thanking me for booking Hilton 
Hotel rooms and various US airline tickets, as well as several US banks 
sending me statements. (These aren't spam, but actual real messages for 
real bookings or real bank accounts). The problem is that it's nigh on 
impossible to sort it out. I don't know the person's actual email 
address, and if I email Hilton, the airlines or the banks to say that 
the email address is wrong, I get accused of all sorts... I've given up now.

The scary thing is that I suspect I could go to at least some of the 
websites, attempt to log in and ask for a password reset email !

The fact is that most people do not really care about privacy! Them 
volunteering to send me their credit card statements proves that. Hiding 
IP addresses pales into insignificance alongside that.

---

From: Martijn Grooten <[email-masked]>
Date: Sun, 13 Dec 2015 19:02:37 +0000

On Sun, Dec 13, 2015 at 05:38:37PM +0000, Paul Smith wrote:
> volunteering to send me their credit card statements proves that.
> Hiding IP addresses pales into insignificance alongside that.

While it's true that many people are quite clueless when it comes to
email security, I don't think that is a reason not to remove privacy
sensitive information that may not be needed. The fact that many people
quite happily enter personal information on random websites, hasn't
stopped many bigger and smaller sites from serving content over HTTPS.

Moreover, my ideal outcome isn't one where an IETF [WRE]G tells email
providers all over the world which bits to remove. If anything, I think
email is far too established for the IETF to have this kind of
influence.

What we can do is guide email providers who want to remove privacy
sensitive information, for reasons that we may or may not agree with, to
do it in a way that doesn't harm our ability to fight other kinds of
abuse. I still think that's possible.

Martijn.

---

From: Ned Freed <[email-masked]>
Date: Sun, 13 Dec 2015 14:13:42 -0800 (PST)

> sensitive information that may not be needed.

But that's exactly the problem - there's no way to tell whether or not
it will be needed. And the uses for which it is needed include some
that can assist users in maintaining their privacy.

> The fact that many people

For this to be a sensible comparison to the inclusion/omission of IP
information in Received: fields the use of HTTPS  would have to have some
deleterious consequences. Those consequences are ... what, exactly?

Like it or not, there are privacy tradeoffs in the decision to include or omit
this information. The continued refusal to acknowledge that these tradeoffs
exist has us all circling around and around and is making it impossible to
move forward in this discussion.

> email is far too established for the IETF to have this kind of

I don't think anyone is proposing that the IETF do anything like this. The
current charter text and draft are both deeply flawed, but neither of them do
this.

> abuse. I still think that's possible.

I started out in this discussion by expressing the belief that redacting IP
address from Received: fields during submission was a good idea and redaction in
other contexts was not [1].

But not only has the discussion so far failed to provide the strong support for
my original belief that I expected would emerge, it has shown me that there's a
much stronger case for retaining the information that I previously thought.

				Ned

[1] http://mailarchive.ietf.org/arch/msg/perpass/olIpnc_N1Vu46k0X_Rc74XMlYZE

---

From: Paul Smith <[email-masked]>
Date: Mon, 14 Dec 2015 09:12:00 +0000

On 12/12/2015 20:12, Robert A. Rosenberg wrote:
>> know if their network or mail server had been compromised in some way.
>
Unfortunately, that wouldn't have helped one iota in this instance.

The mail server was the 'correct' mail server.

Also, the message-id can be generated by the message sender, so the 
spambot could generate that, wherever it was.

To solve this, this IP address had to be available, either in the 
message headers, or some other way via the mail service provider.

---

From: Paul Smith <[email-masked]>
Date: Mon, 14 Dec 2015 09:21:24 +0000

> I have a gmail account.   It gets very little spam, gets the email that real people send me, and delivers email from me to them fairly reliably.   And it's "free".   The test of a good service is n…
We do need to call them. Frequently.

We frequently would LOVE to be able to communicate with them to ask why 
they are rejecting messages legitimate randomly, or whatever. Or, we'd 
like to tell them that one of their customers has set up forwarding from 
a proper email address to one of theirs, so THAT is why they're 
receiving so much spam from this IP address. And so on.

We can't call them (or email them), so we just end up telling people not 
to use gmail.

It's not just customers who need to contact mail administrators. It's 
people trying to send mail to them as well. That was the whole point of 
the 'postmaster' requirement (which still stands, and has not been 
deprecated, BTW). If gmail has such wonderful, perfect, spam filtering 
then they could easily put that onto their 'postmaster' address, and 
they wouldn't have any problems.

---

From: "John Levine" <[email-masked]>
Date: 14 Dec 2015 15:31:14 -0000

>receiving so much spam from this IP address. And so on.

No doubt all of your mail is fine and virtuous (although if you let
your users forward without filtering, it's a self-inflicted wound),
but I can assure you that the vast majority of people who would want
to make such calls are dodgy ESPs and spammers, to whom the answer is
we're not accepting your mail because our users don't want it, and no,
we don't care about your business model.

Talk about something that doesn't scale.

R's,
John

---

From: Paul Smith <[email-masked]>
Date: Mon, 14 Dec 2015 16:07:06 +0000

>  Talk about something that doesn't scale.

Oh, I know it won't scale. But if the assertion is that "gmail is so 
amazing that no one ever needs to contact them" (which it was), then 
I'll dispute that.

Given that offering helpful support doesn't scale, so gmail can't/won't 
answer 'postmaster' emails with a helpful reply, then maybe that's a 
reason why information needs to be available to people so they can help 
themselves, rather than hiding even more.

---

From: John C Klensin <[email-masked]>
Date: Mon, 14 Dec 2015 11:43:26 -0500

--On Monday, December 14, 2015 16:07 +0000 Paul Smith
<[email-masked]> wrote:

> Oh, I know it won't scale. But if the assertion is that "gmail
> is so amazing that no one ever needs to contact them" (which
> it was), then I'll dispute that.
> 
> Given that offering helpful support doesn't scale, so gmail
> can't/won't answer 'postmaster' emails with a helpful reply,
> then maybe that's a reason why information needs to be
> available to people so they can help themselves, rather than
> hiding even more.

Paul,

In principle, I agree.  In practice, until and unless gmail
users start voting with their feet and do so in large
quantities, Google has every reason to believe that what they
are doing (including delivering a service that could easily
become costly to run if saddled with requirements for support)
for free[1], I can't even imagine the situation changing and
can't see how speculating on such changes moves us forward.

I wouldn't recommend holding your breath waiting for that mass
exodus of users.

You don't like it.  I don't like it.  I think that, in some
alternate universe in which "free" email accounts were
forbidden, a lot of economics would change and operational
changes would soon follow.  But I don't know how to do it in
this universe/ reality.

   best,
    john

[1[ Of course, in the Google case and some others, "free" really
means "in exchange for the right to display advertising to you
and to deduce your profile and sell that to advertisers".
Excuse me if, against the background of users voluntarily
agreeing to that sort of privacy compromise any time they send
mail to or from a gmail (or several others -- they are certainly
not unique), this discussion about disclosure or privacy-related
information in trace fields strikes me as a bit of "privacy
theatre" to complement the "security theatre" we've seen for
years -- doing something to say that action has been considered
and taken, but picking what to do because it seems easy, helps
people claim that they care and are taking action, and looks
like action even if it is actually almost completely pointless.
Just as the airport version of security theatre has made a major
contribution toward turning travel into an unpleasant experience
without adding much actual security, reducing the information
content of trace fields seems to me to be likely to reduce the
efficiency, reliability, and effectiveness of email without
significant improving on privacy about things that a determined
attacker cannot figure out in other ways.

---

From: Brandon Long <[email-masked]>
Date: Mon, 14 Dec 2015 11:13:42 -0800

> and to deduce your profile and sell that to advertisers".

Interrupting a rant is probably pointless, but to be clear, Gmail doesn't
sell your profile to advertisers, they show you ads based on your profile.
The distinction is fairly meaningful, even in your theatre context.
Choosing to believe that a particular vendor is trustworthy to have that
information is quite different from assuming they share that information
with everyone.

And the information disclosed and to whom is also very different.  One of
the examples given was stalkers, who definitely don't have access to your
Google advertising profile much less your location, unless they compromise
your account.

Brandon

> ietf-smtp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-smtp
>

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Mon, 14 Dec 2015 19:47:09 +0000

> From: ietf-smtp [mailto:[email-masked]] On Behalf Of Paul
> Smith
> Sent: Monday, December 14, 2015 11:07 AM
> To: [email-masked]
> Subject: Re: [ietf-smtp] [Shutup] chatting with big gorillas, was Proposed
> Charter
> 
> Oh, I know it won't scale. But if the assertion is that "gmail is so amazing that
> no one ever needs to contact them" (which it was), then I'll dispute that.
> 
> answer 'postmaster' emails with a helpful reply, then maybe that's a reason
> why information needs to be available to people so they can help

I do not work for gmail/google/alphabet but I have had the opportunity to see their responsiveness evolve over the years. Given that a lot of the contacts to them are on the level of "People really really really want my email so you need to put it in the inbox (rather than some other tab or the spam folder or rejected)", I can understand why they aren't generally more responsive. As both a sender and someone that has a gmail account (among other accounts), I believe they disposition pretty much correct. As a sender, in the last 8 - 10 years or so I've only found 2 (non recent) instances where it was something borked on their side that caused problems. Then again, my philosophy is that most people get the delivery they deserve - which fits nicely with their data driven approach. And then again, I'm an anti-abuse person, not a deliverability person so my perspective is biased.

Mike

---

From: Rich Kulawiec <[email-masked]>
Date: Tue, 15 Dec 2015 16:14:50 -0500

> move forward in this discussion.

Agreed, strongly.  I think the way forward (or perhaps, better,
*a* way forward) is to form an EG or a RG and try to create
a survey of the privacy issues -- including the tradeoffs.
I think that there are far more serious issues in play and that it would
be a useful exercise to try to enumerate all of them in one place --
well before we think about deciding *which* to address and *how* to
address them.

---rsk

---

From: Ned Freed <[email-masked]>
Date: Tue, 15 Dec 2015 15:08:04 -0800 (PST)

> well before we think about deciding *which* to address and *how* to

I agree that this seems like the best way forward given the discussion. But I
have two concerns.

First, while there's at least some chance that moving to an EG/RG format can
get things past the disconnect, it's far from a certainty.

Second, this will take a fair bit of time, and as I've noted previously, things
are already on the move. We may have lost our chance at relevance by the time
we're done.

But frankly, nothing else seems like to reach any sort of consensus, so unless
someone has a really bright idea they haven't voiced yet, this looks to me to
be as good as it's going to get.

				Ned

---

From: Rich Kulawiec <[email-masked]>
Date: Wed, 16 Dec 2015 07:26:52 -0500

> even for lousy mail providers.

I can attest to this, having expended a great deal of effort attempting
to get people to migrate from broken/bad/ignorant/etc. mail providers
to ones that are less broken/bad/ignorant/etc.  The investment in time
and effort required for users to switch is nearly always much larger
than they're willing to make.  Even getting them to switch mail *clients*
is difficult, and it remains difficult even when their current choice
has been shown to be the cause of serious issues.

The expectation that users will behave rationally and in their own best
interest has no basis in reality.

---rsk

---

From: Ted Lemon <[email-masked]>
Date: Wed, 16 Dec 2015 17:26:21 +0000

> interest has no basis in reality.

I am baffled by statements like this.   I feel that I have to criticize what you have said.   I know this is going to come across as unkind, but that's not my intention--I really am just baffled.   The problems with what you have said are several:

- It is not based on a statistically valid survey
- It suffers from squeaky-wheel confirmation bias
- What you mean by "in their own best interest" is almost certainly not an accurate understanding of how the people in your anecdotal sample actually perceive their interests, and that is why you find their behavior puzzling and have developed such a degree of cynicism and disrespect toward them.

This is not a good way for us to reason about any problem.   Please let us not do so.