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

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

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

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: Ted Lemon <[email-masked]>
Date: Tue, 01 Dec 2015 17:29:16 +0000

Tuesday, Dec 1, 2015 12:11 PM Steve Atkins wrote:
> > On Dec 1, 2015, at 8:54 AM, Ted Lemon <[email-masked]> wrote:
>> 

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

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

Tuesday, Dec 1, 2015 12:57 PM Ned Freed wrote:
> 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.

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.

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

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: 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: 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: "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: Ted Lemon <[email-masked]>
Date: Tue, 01 Dec 2015 21:29:09 +0000

Tuesday, Dec 1, 2015 4:10 PM Richard Clayton 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.

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: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: 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: 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,
> 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?"

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 20:09:18 -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, er, 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: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

Tuesday, Dec 1, 2015 6:52 PM Al Iverson wrote:
> 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.

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: 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: Ted Lemon <[email-masked]>
Date: Wed, 02 Dec 2015 03:35:04 +0000

Tuesday, Dec 1, 2015 10:25 PM Rich Kulawiec wrote:
> 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.

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: 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.
> 
> So, training HAS to be done, otherwise people will lose privacy.

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

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

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

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

Thursday, Dec 3, 2015 4:26 AM Paul Smith wrote:
> 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: Steve Atkins <[email-masked]>
Date: Tue, 1 Dec 2015 09:11:23 -0800

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

Well, I'll be the first, then.

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

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

Regards,
Al Iverson

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

---

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: "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: Chris Lewis <[email-masked]>
Date: Tue, 1 Dec 2015 19:38:29 -0500

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

---

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

---

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

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: Ted Lemon <[email-masked]>
Date: Fri, 04 Dec 2015 21:10:15 +0000

Friday, Dec 4, 2015 3:42 PM Rich Kulawiec wrote:
> 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.

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.

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

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.

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

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