Subject: Re: [ietf-smtp] [Shutup] Proposed Charter for something

From: "John Levine" <[email-masked]>
Date: 7 Dec 2015 02:34:26 -0000

>Perhaps one of the most important things in the WG is to decide whether 
>the output is a document, and whether the document is an informational, 
>a BCP or standard or STD.  My current thinking is that we're going to 
>hit BCP at best.

This is increasingly looking like a RG, not a WG.  There's a lot of
speculation about what aspects of mail messages and SMTP sessions have
what privacy implications, with an extremely premature focus on IP
address logging.  I'd much rather back up a step or two and see if we
can catalog the aspects of mail messages with estimates of the privacy
benefits and risks of each, keeping in mind the context.  

For example, how much new information is there in the date stamp in a
Received header in the usual case that it's a few seconds after the
timestamp in the Date: header?  On the other hand, most Received
headers have a unique ID that's really handy to identify the message
and the path it took (That's how you tell who's sending spam reports
from AOL and Yahoo, even though they redact all the addresses.)

That would be a useful catalog, and we can think about models that
look at the net personal information, and diagnostic and anti-abuse
information provided by various combinations of features or the lack
thereof.  That would be interesting on its own, and would give us a
much better foundation from which to consider changes that could
produce an actual overall privacy improvement.

R's,
John

---

From: Ted Lemon <[email-masked]>
Date: Mon, 07 Dec 2015 03:44:04 +0000

> from AOL and Yahoo, even though they redact all the addresses.)

Bear in mind that the date header field isn't modified in transit, so it can in principle be in the encrypted blob, and not in the postcard headers.

> produce an actual overall privacy improvement.

Agreed, but I don't see why you think this is an RG and not a WG.

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

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

---

From: Dave Crocker <[email-masked]>
Date: Sun, 6 Dec 2015 20:35:13 -0800

> Agreed, but I don't see why you think this is an RG and not a WG.

Please re-read his note and one or another of my earlier notes.  They
explain why.

At the moment, proposals for taking specific actions represent a random
walk down a large and complex set of possibilities, with no serious
analysis of benefits, risks, likelihoods or anything other than intuition.

Before modifying infrastructure operations of a critical Internet
resource, perhaps we should develop some credible basis for taking any
specific action?

Individuals are free to take whatever random path strikes their whimsy.
 Standards groups should have rather more basis for moving the whole
ship in a particular direction.

d/
-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: John C Klensin <[email-masked]>
Date: Mon, 07 Dec 2015 02:31:28 -0500

--On Monday, December 07, 2015 02:34 +0000 John Levine
<[email-masked]> wrote:

>...
> This is increasingly looking like a RG, not a WG.  There's a
> lot of speculation about what aspects of mail messages and
> SMTP sessions have what privacy implications, with an
> extremely premature focus on IP address logging.  I'd much
> rather back up a step or two and see if we can catalog the
> aspects of mail messages with estimates of the privacy
> For example, how much new information is there in the date
> stamp in a Received header in the usual case that it's a few
> seconds after the timestamp in the Date: header?  On the other
> hand, most Received headers have a unique ID that's really
> handy to identify the message and the path it took (That's how
> you tell who's sending spam reports from AOL and Yahoo, even
> though they redact all the addresses.)
> 
> That would be a useful catalog, and we can think about models
> that look at the net personal information, and diagnostic and
> anti-abuse information provided by various combinations of
> features or the lack thereof.  That would be interesting on
> its own, and would give us a much better foundation from which
> to consider changes that could produce an actual overall
> privacy improvement.

This strikes me as a really good idea.  This is probably what
John has in mind but, to be explicit, if it could also catalog
(not just allow "thinking about"), for each item, the
substantive uses to which any relevant aspect or datum is being
legitimately put today, differentiating things that are
specifically anti-spam from anti-phishing and mitigation of
malware and other types of attacks, that would be even better.
As many people have suggested in the previous threads, "more
privacy", whether about location or other information, is not
free but involves tradeoffs with other priorities and it is
important to consider the tradeoffs and balance.   

For me at least, Dave Crocker's subsequent comments reinforce
that view.

     john

---

From: Martijn Grooten <[email-masked]>
Date: Mon, 7 Dec 2015 07:44:14 +0000

> benefits and risks of each, keeping in mind the context.  

I would be in favour of such a RG.

Martijn.

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 7 Dec 2015 10:50:42 +0000

On 07/12/15 02:34, John Levine wrote:
> This is increasingly looking like a RG, not a WG.

Hmm, not sure. A good RG is one that'd attract an active
research community and be relatively long lived whereas
this seems like a bit of work where we need to do a relatively
small and discrete amount of research on one topic. (Which
is roughly "What'd happen if you mucked with received headers
the MSA passes on to the rest of the mail infrastructure?")

The way I think of it is a good RG would produce a stream
of academic publications and then some stuff that'd be of
use to the IETF. This sounds more like one paper's worth
of research then stuff would be done in the IETF or not,
depending on the findings.

So I don't think an RG would be a good plan and a WG
can be chartered to investigate things before proposing
things.

But if folks think an RG is better, the first step would be
to talk to Lars about it.

S.

---

From: Rich Kulawiec <[email-masked]>
Date: Mon, 7 Dec 2015 09:09:47 -0500

> benefits and risks of each, keeping in mind the context.  

I strongly concur with this.  We need to define the problem(s) before
we can discuss possible solution(s).

---rsk

---

From: John C Klensin <[email-masked]>
Date: Mon, 07 Dec 2015 11:13:42 -0500

--On Monday, December 07, 2015 09:09 -0500 Rich Kulawiec
<[email-masked]> wrote:

> I strongly concur with this.  We need to define the problem(s)
> before we can discuss possible solution(s).

Rich,

Looking at one other comment and anticipating more, it is common
these days for IETF WGs to do "problem statement" or "problem
definition" work as part of their charters.    It seems to me
that there are two arguments for an RG instead:

(1) As others have pointed out, this is really a complex
analysis problem, involving tradeoffs with other concerns and
the very fundamental question of whether dropping, e.g., the
"from" clause would actually provide an increase in privacy that
is significant enough to justify changing systems even if there
were no other issues.  Those are research problems.  Given
history, one might predict that an IETF WG asked to do a problem
statement might say "problem: get rid of the 'from' clause
because it gives out potentially-private information".  And that
sort of thinking is, IMO, exactly what got us to this point.

(2) I believe there has been a tendency in recent years that,
once a WG is chartered, there is a sense that it is entitled and
obligated to produce standards.  "No problem here" is not a
plausible outcome, nor is the community completely rejecting a
draft as likely to cause more problems than it solves.  The best
way to avoid that issue is to not get started, and RG is the
right answer for that.

I don't think we are disagreeing; I just think that, given
experience, the point and preference are worth making clearly.

   john

---

From: Chris Lewis <[email-masked]>
Date: Mon, 7 Dec 2015 14:41:13 -0500

> depending on the findings.

One could envision a RG constituted to long-term specifically work on 
privacy implications of IETF RFCs in general, with a view towards 
improving privacy via future RFCs.  There is at least some precedent 
given the requirements about security area oversight of new RFCs, and 
the required SECURITY sections of RFCs now.  Which would be a "good 
thing", but huge, unwieldy, and perhaps unsustainable long-term (given 
that most people may only have narrow topic-area interests).

You could, instead, have it focus on specific areas for periods of time. 
  Like, "today SMTP, 6 months from now web" etc.  May still be 
unwieldy/ineffective for the same reasons.

Or finally, make it narrow - "RG on email privacy leakage" - a WG with a 
stronger research/analysis mandate.

OTOH, if we stayed with the WG approach, the mandate still has to be 
adjusted to do the research for guiding output documents w.r.t. privacy 
vs other tradeoffs.

I'm tending more towards RG on email privacy leakage.  Even just a 
document outlining where the potential leaks are, and outlining the 
threat landscape tradeoffs (both privacy and other) of 
eliding/not-eliding the info.

So put me up as a strongish vote for a narrow RG.

---

From: Hector Santos <[email-masked]>
Date: Mon, 07 Dec 2015 14:59:42 -0500

> can be chartered to investigate things before proposing

+1.

I think a working group is sufficient with faster high quality results 
than a longer term research effort.  We have enough 
ietf-industry-man-years, especially in the mail industry, to determine 
what is necessary.

The charter started out with ambitious goals that included 
"well-engineered improvements to the SMTP protocol."

But then it limited itself to specific work items, including DMARC 
related items which is not enough. I believe this effort requires 
liaison with the IETF-SMTP and DNS communities, as well as the DMARC 
and SPF communities.

How about:

   o RFC5321BIS, RFC5322BIS  Working Groups
   o "Email Bible" BCP for Hosting Mail Services Working Group

The latter would produce an Modern Integrated ESMTP guide like RFC1123 
was the "hosting bible" for many internet application hosting 
implementers.

But then again, I can see how the charter may want to keep it simple 
too with the specific work items:

  o New I-D to relax the STD10/RFC5321.Received MUST requirement,
  o New I-D for "Cryptographic Protection of E-mail Headers" (memoryhole)
  o Soliciting new ideas (any I-Ds?) for Loop Detections.

-- 
HLS

---

From: Rich Kulawiec <[email-masked]>
Date: Tue, 8 Dec 2015 14:46:58 -0500

> experience, the point and preference are worth making clearly.

I concur: I think we're on the same page here.

I'm going to have some time starting in January to devote to this.
And I'm willing to put together a laundry list of issues-to-consider,
which will no doubt be incomplete, wrong, and poorly written.  But it
would at least be a revision 0.1 try at enumerating the things we
could/should discuss.

---rsk

---

From: "John Levine" <[email-masked]>
Date: 8 Dec 2015 20:42:27 -0000

>would at least be a revision 0.1 try at enumerating the things we

I recently noticed RFC 5111 which describes an Exploratory Group, sort
of half way between a WG and a RG.  This seems like a good fit.

R's,
JOhn

---

From: Martijn Grooten <[email-masked]>
Date: Wed, 9 Dec 2015 20:33:58 +0000

> of half way between a WG and a RG.  This seems like a good fit.

I wasn't familiar with that concept, but I agree, it seems like a good
fit.

Martijn.

---

From: Dave Crocker <[email-masked]>
Date: Wed, 9 Dec 2015 13:17:53 -0800

> of half way between a WG and a RG.  This seems like a good fit.

Here's why it isn't:

     The distance between the current state of the community and the
ability to start a productive working group is not merely the matter of
clarifying a few issues.

     The community has no overall sense of privacy protection, nor
efficacy of choices, nor... well, many things.

      Absent a basic, systems-approach to guide community effort, for
doing anything but the most blindingly obvious steps for protection, the
community will be executing a random walk through a very complex face.

      This will essentially guarantee spending quite a lot of time and
money on an effort that will have little benefit.

d/

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Thu, 10 Dec 2015 12:32:14 +0000

> efficacy of choices, nor... well, many things.

And there's a significant barrier that may prevent the group from ever 
obtaining that knowledge.

We don't know everything about how spam filters work. But IMO we don't need 
to, because we know that: 1) all of the big four use machine learning and 
feed everything they can into their machine (whatever "can" means in each 
case) 2) there are some things about the details they are not willing to 
disclose.

We know other things but really, it's enough: If the human ops at the four 
biggest sites don't know the ultimate details of what their spam filters 
are doing, and might not be permitted to describe it even if they knew, 
then investigating the interoperability of any proposal with current 
practice is intractable.

(Not saying that four sites is enough, just that those four are too big to 
overlook, and spam filter compatibility is a requirement in today's world.)

> money on an effort that will have little benefit.

+1

Arnt

---

From: John C Klensin <[email-masked]>
Date: Thu, 10 Dec 2015 08:28:58 -0500

--On Wednesday, December 09, 2015 13:17 -0800 Dave Crocker
<[email-masked]> wrote:

> 
>> I recently noticed RFC 5111 which describes an Exploratory
>> Group, sort of half way between a WG and a RG.  This seems
>> like a good fit.
> 
> Here's why it isn't:
> 
>      The distance between the current state of the community
> and the ability to start a productive working group is not
> merely the matter of clarifying a few issues.
> 
>      The community has no overall sense of privacy protection,
> nor efficacy of choices, nor... well, many things.
> 
>       Absent a basic, systems-approach to guide community
> effort, for doing anything but the most blindingly obvious
> steps for protection, the community will be executing a random
> walk through a very complex face.
> 
>       This will essentially guarantee spending quite a lot of
> time and money on an effort that will have little benefit.

And, if we have learned anything from either more traditional
security designs or protocol design for complex systems more
generally, it also predicts to ending up with a "solution" that
is replaces whatever attack vectors we are trying to eliminate
with others -- perhaps new and perhaps latent there already but
not discovered by the process that is used.

    john

---

From: Martijn Grooten <[email-masked]>
Date: Thu, 10 Dec 2015 14:48:14 +0000

On Thu, Dec 10, 2015 at 12:32:14PM +0000, Arnt Gulbrandsen wrote:
> We don't know everything about how spam filters work. But IMO we
> don't need to, because we know that: 1) all of the big four use
> machine learning and feed everything they can into their machine
> (whatever "can" means in each case) 2) there are some things about
> the details they are not willing to disclose.
> 
> We know other things but really, it's enough: If the human ops at
> the four biggest sites don't know the ultimate details of what their
> spam filters are doing, and might not be permitted to describe it
> even if they knew, then investigating the interoperability of any
> proposal with current practice is intractable.

I think it's fair to assume every bit of the email headers (and body) is
used by spam filters in one way or another. I have anecdotal evidence of
spam filters detecting a campaign based on something as tiny as an extra
space in one of the headers.

But I don't think that's a good reason not to remove certain headers
and/or remove parts of some of them that potentially contain privacy
sensitive information. The real question is: would spam filters still be
able to do a good enough job if we removed these things?

I think the RG/WG/EG could ultimately lead to some kind of BCP that says
something like: to comply with this BCP document you MUST sign your
emails with DKIM and follow other good practices and then you MAY remove
internal routes and other information from the email headers. You SHOULD
add a cryptographic blob to identify customers and add a mechanism to
prevent loops.

Of course, we're a long way away from reaching such a conclusion, and
perhaps we never will. But I think we may; hence I think it's worth the
effort (and time, and money).

My personal motivation is that I care about privacy (fundamental human
right, etc.) and that I think some easy and harmless improvements can be
made in email. But I also think that as privacy has become a hot topic,
there is a chance that individual organisations are going to be slagged
off for revealing too much in their headers. A BCP could help them make
the right changes, rather than remove headers or parts thereof at
random.

Martijn.

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Thu, 10 Dec 2015 15:29:33 +0000

Martijn Grooten writes:
> sensitive information.

"X is a good idea" ≠ "X is a good idea for a standards body".

> The real question is: would spam filters still be

There are two thresholds: The line above which enough information is 
removed to effectively protect whatever is to be protected, and the line 
above which best-in-class spam filters cannot effectively distinguish 
between a blackhat trying to protect his identity and a whitehat doing the 
same.

I can't see any argument that the two differ.

Arnt

---

From: Richard Clayton <[email-masked]>
Date: Thu, 10 Dec 2015 16:08:36 +0000

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

>I can't see any argument that the two differ.

Spam filters do not seek to identify per se -- rather they assign
reputation to an identity, and the best in the class ones use everything
available to them in order to do that...

Where everyone (from some group or other) is given the same identity
then they will, of necessity, share the same reputation (which is a plus
for the black hats, and a minus for the white hats).

So the white hats will wish to be as identifiable as possible (in this
very narrow sense of not mixing their reputation with others) whereas
the black hats will wish to obscure the linkage between their previous
activity and what they are doing today.

Of course this mixing of reputation amongst a group of senders may not
be a long-term problem if someone is actively monitoring the membership
of the group and kicking out the bad guys.

Hence having the large providers (who all do some sort of proactive
monitoring for outgoing badness) do what they have done to obscure
submission IPs has had less of an impact (long-term) than if the small
providers (where monitoring is somewhat more variable) did the same.

However, the changes have not helped -- and it's meant that the extent
to which these large providers are responsive to out-of-band (and of
course very automated) feedback mechanisms matters rather more.

... and of course submission IPs were used for other things than just
spam filtering... fine grained loop control, ad hoc notification of
security issues, assistance in determining email provenance, triage of
crime reports etc.

- -- 
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: Chris Lewis <[email-masked]>
Date: Thu, 10 Dec 2015 11:16:40 -0500

On 12/10/2015 10:29 AM, Arnt Gulbrandsen wrote:

> between a blackhat trying to protect his identity and a whitehat doing
> the same.

I wish it were as simple as just two, if only because "best-in-class" 
filters are not something that even the average or merely above average 
installation can afford/practically deploy.

There are many filtering things you can do at enterprise (and above) 
scale that are simply not doable at the merely "big".  If nothing else, 
you simply may not get a big enough signal (of multiple campaigns) to 
chew upon.  Even "magic" ML can't learn if there's not enough to learn.

There really are no technical differences whatsoever between a blackhat 
and a whitehat trying to protect their identity. The ONLY saving grace 
is that (in the spam space) the blackhat is forced to resort to methods 
that scale high enough for an adequate ROI, while the whitehat usually 
doesn't care that much.

Tor, for example, being a case in point.  Tor would be ideal for spam. 
And it was for a bit.  Slow, but worked.  I don't know whether the fact 
that the tor network became so slow as to be unuseable, or that the 
screams from the "spammed" turned the day, but so few tor exit nodes 
support outbound port 25 nowadays that it isn't a big problem.

But it can be an abuse problem in other ways.  Tor exit operators don't 
like getting blacklisted, and they have a canned template to send to 
DNSBL operators with the usual heart-tugging verbiage as a plea to get 
permanently whitelisted.  The only possible reply is "you simply don't 
want to be known as a safe harbour for abuse, because if you do the 
problem becomes orders of magnitude worse until everyone considers tor 
itself too much of a risk and everybody loses.  So consider this listing 
a method of preserving the future of tor.".

Fortunately for tor, it's relatively slow.  If it weren't, it would be 
doomed.

---

From: Martijn Grooten <[email-masked]>
Date: Thu, 10 Dec 2015 16:40:41 +0000

On Thu, Dec 10, 2015 at 03:15:41PM -0000, John Levine wrote:
> No, it's not.  The question is whether there would be an overall
> gain in users' privacy since providers would likely be less able
> to combat phishing and other privacy attacks.
> 
> Spam filtering is just part of it, and in this case not where the
> most important effects would be.

I meant "spam filters" in the broad sense, including all human and
non-human activity against spam, though should have made that clear.

Are there other parts of the email headers that are important to
combat phishing and other "privacy attacks", apart from the submission
IP address? And how much does the actual IP address matter, as opposed
to a "cryptographic blob" of said address, that can be "decrypted" by
the ISP and is constant for some time for a given (user,IP) combination.

Martijn.

---

From: Richard Clayton <[email-masked]>
Date: Thu, 10 Dec 2015 16:56:29 +0000

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

>And how much does the actual IP address matter, as opposed

an IP address generally indicates the ISP and country of origin (but
there's a number of edge cases)

for many individuals there is only a short-term linkage between
themselves and the IP address (think dialup, DHCP systems for broadband
and carrier grade NAT solutions for mobile) so you can seldom use it for
long-term tracking of activity ("what else has this person done")

- -- 
richard                                                   Richard Clayton

---

From: Martijn Grooten <[email-masked]>
Date: Thu, 10 Dec 2015 17:11:22 +0000

On Thu, Dec 10, 2015 at 11:16:40AM -0500, Chris Lewis wrote:
> There really are no technical differences whatsoever between a
> blackhat and a whitehat trying to protect their identity. The ONLY
> saving grace is that (in the spam space) the blackhat is forced to
> resort to methods that scale high enough for an adequate ROI, while
> the whitehat usually doesn't care that much.

Most spam filtering - again used in the broad sense - only cares about
the identity of the sending organisation (ISP, company, etc.). And
sometimes not even that. If an email body matches some (fuzzy)
signature, it gets blocked, often regardless of who sent it from where.

It's only when said organisation doesn't do a good enough job of
checking the identity (or the hat colour) of the sender, that being able
to find the actual sender matters to everyone else.

> Tor, for example, being a case in point.  Tor would be ideal for
> spam. And it was for a bit.  Slow, but worked.  I don't know whether
> the fact that the tor network became so slow as to be unuseable, or
> that the screams from the "spammed" turned the day, but so few tor
> exit nodes support outbound port 25 nowadays that it isn't a big
> problem.

If they hadn't all blocked that port (it's the default, I believe) then
every DNSBL would add the exit nodes; Tor, by design, doesn't hide the
nodes' IP addresses and it's easy to check if a certain IP address is
or was a Tor exit node at a given time.

Tor in an email context should be used to connect to an ISP's or
corporate mail server. It's up to them to decide whether they have
enough reason to believe youare a whitehat. Many believe they are able
to do so, though they often require a one-time phone verification.

If being able to hide (the geolocation of) your submission IP address is
of vital importance, then this is the way to use email. For most people,
this isn't necessary, but it is my belief that at the very least we
should help organisations that wish to protect personal data for all of
its users to do so in a way that doesn't seriously harm the existing
email infrastructure.

Martijn.

---

From: Martijn Grooten <[email-masked]>
Date: Thu, 10 Dec 2015 17:23:36 +0000

> there's a number of edge cases)

The email address does at least indicate the former. Personally, I don't
think country of origin is significant personal information (though here
too there are edge cases).

> long-term tracking of activity ("what else has this person done")

I have been told that in the case of a home ISP, the linkage lasts long
enough that if you send me a job application email from 1.2.3.4 that a
visit to our website three days ago from 1.2.3.4 was quite likely made
from the same house.

I believe this is in part why some legislations consider an IP address
personal data.

A "crypgraphic blob" would still be linked to the customer, but not to
any other activity.

Martijn.

---

From: Steve Atkins <[email-masked]>
Date: Thu, 10 Dec 2015 09:36:41 -0800

> On Dec 10, 2015, at 9:23 AM, Martijn Grooten <[email-masked]> wrote:
> 
> The email address does at least indicate the former.

Only in the cases where the email address is provided by the access ISP
of the user. That's not as common as it was (and the case where all the email addresses
in the domain are used solely by users of the same access ISP is vanishingly
rare).

Cheers,
  Steve

---

From: Richard Clayton <[email-masked]>
Date: Thu, 10 Dec 2015 17:42:30 +0000

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

>visit to our website three days ago from 1.2.3.4 was quite likely made

My home cable connection has had the same IP for 15 months... but I
would expect to get a different IP if I powered the cable modem down for
more than a few minutes.

There are no general rules here and almost every possible case is common

>I believe this is in part why some legislations consider an IP address

It's not to do with lifetimes per se because there may exist
organisations that can link the IP to a person....  the test is

        any information
        relating to
        an identified or identifiable
        natural person

and you should read

<http://ec.europa.eu/justice/policies/privacy/docs/wpdocs/2007/wp136_en.
pdf>

for a detailed analysis of each of those four elements.

And then you can amuse yourself for seeing how the UK failed to
transcribe this especially well (so the test is different here) and then
note that the EU is almost certainly going to go forward with a
Regulation next week (so that the UK can't "cheat" in future)

>A "crypgraphic blob" would still be linked to the customer, but not to

all recipients of the email (and the blob) will of course become
processors of personal data (but we all knew that already, didn't we)

- -- 
richard                                                   Richard Clayton

---

From: Chris Lewis <[email-masked]>
Date: Thu, 10 Dec 2015 12:50:47 -0500

> signature, it gets blocked, often regardless of who sent it from where.

I would contend that very little spam filtering cares what the identity 
is at all.  The identifier tokens just being more grist for the 
filtering engine that may help or may not.

For example, Bayes doesn't care what the words it scans mean, it looks 
for statistical similarity with stuff it knows is bad and stuff it knows 
is good.

> to find the actual sender matters to everyone else.

Or, sometimes, when you're trying to figure out where it's going to pop 
up next and/or warn providers of the toxic customer.

> If they hadn't all blocked that port (it's the default, I believe)

Newbie ;-)  It wasn't always that way.  How do you think that came to be 
that way?

> then every DNSBL would add the exit nodes;

Precisely.

> Tor, by design, doesn't hide the

The aforementioned boilerplate describes that in copious detail so as to 
make it easier for the DNSBL operator to use their exit node list to 
whitelist them unconditionally no matter what comes out of them.

Er, no.  We're very polite.  We have boilerplate for that too.

They also get told that at least we don't treat tor nodes any 
differently than any other, and a reminder to not co-locate a tor node 
with their own servers/network and thus share the reputation of the exit 
node.

> its users to do so in a way that doesn't seriously harm the existing

The tor "group" had to make a similar decision, when it came to the 
serious harm to the viability of their own infrastructure by what, at 
the time, was unfettered spam.

I2P is going through a similar revolution now - going from a theology of 
the "bits must be free and more importantly private" to a realization 
that their future relevance relies on not becoming an infamous source of 
harm.  They have to come up with innovative ways to preserve what they 
want it to be, in the face of those wishing to pervert it to being a 
safe haven conduit for their abuse.

---

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

On 12/10/2015 12:42 PM, Richard Clayton wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>

I will be surprise if it did.  For my home system, my "dynamic" IP has 
not changed unless the box itself was replaced by my ISP (AT&T).  That 
has happened twice (box replaced) over the last 8-10 years and only 
then did the IP change.  Over those years, there has been times where 
the boxes were powered off for lengthy periods and to my surprise, and 
unlike the earlier days, there was never a new IP assigned.

> There are no general rules here and almost every possible case is common

I personally think the ISP has a contract and business deals with the 
advertising market to make sure to keep dynamic IP boxes "static" for 
as long as possible.   I'm sure they have deals with the "Facebooks" 
and "Yahoos" of the world.

In any case, I am going to pencil in an new SMTP option in our SMTP 
server product:

    [X] Add Receiver Trace Line
        (o) Show Client IP
        (_) Mask Client IP

I think it is important enough because of the improved (and society 
acceptable) BI (business intelligence) software in the market today.

Thanks

-- 
HLS

---

From: Rich Kulawiec <[email-masked]>
Date: Thu, 10 Dec 2015 14:53:08 -0500

On Thu, Dec 10, 2015 at 12:32:14PM +0000, Arnt Gulbrandsen wrote:
> And there's a significant barrier that may prevent the group from
> ever obtaining that knowledge.
> 
> We don't know everything about how spam filters work. [snip]

The utility of various bits of information for spam/phish/abuse filtering
is certainly an issue.  However, in the big picture, the four huge
operations you refer to (in the rest of your comment that I elided for
brevity) are transient and unimportant -- heck, two of them are failing
as corporations and may not be around in a few years.  I don't think
the IETF should tailor its research or standards efforts around anyone,
no matter how big (or small) they are.

And just to be clear, I don't think we should exclude anyone because
they're big (or small), or ignore what they're doing, or refuse to learn
from their experience.  In particular, there are things that large
providers observe that are very difficult to see at smaller scales,
and I think some of those things are important.  So I'm not arguing
that that those huge four shouldn't have a seat at the discussion
table: absolutely they should, if they wish.

---rsk

---

From: Rich Kulawiec <[email-masked]>
Date: Thu, 10 Dec 2015 14:58:30 -0500

> community will be executing a random walk through a very complex face.

I somewhat agree/disagree with this.  I think that an EG tasked with
attempting to enumerate privacy issues in the email ecosystem (and to
provide at least some vague hand-waving guesstimate of their impact)
could produce as its work product a document which provides a starting
place.  I'm willing to make a try at it because AFAIK right
now we've got nothing.  (If such a document or paper already exists
and I'm unaware of it, I'd appreciate a pointer.)

---rsk

---

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

> acceptable) BI (business intelligence) software in the market today.
We have this already in our server (and have had for at least 15 years). 
We've generally found that people turn it on because it looks like a 
good idea, then turn it off the first time they have a problem and the 
IP address would have been useful. Then it stays off.

Yes, server logs COULD take the place of the IP in the header, but (a) 
the bounce message is there in front of you; you need to search through 
the logs, (b) logs may not last long enough given that bounce messages 
may arrive days after the message was sent, (c) they realise that the 
internal IP address of the user is a negligible security risk.

A "cryptographic blob" may be useful (so we may look at that instead of 
just redacting the address), but that makes things even more complicated 
for users who struggle to understand message headers anyway. In my 
experience people tend to speak about security & privacy, but when it 
comes down to it, they'll choose convenience over those factors pretty 
every time when they can.