Subject: [perpass] draft-josefsson-email-received-privacy

From: Linus Nordberg <[email-masked]>
Date: Tue, 20 Oct 2015 20:28:34 +0200

Hi,

draft-josefsson-email-received-privacy-00 has been submitted, see
https://datatracker.ietf.org/doc/draft-josefsson-email-received-privacy/

I'd be interested in hearing what people on the perpass list think of
this.

---

From: "Christian Huitema" <[email-masked]>
Date: Tue, 20 Oct 2015 13:28:28 -0700

Sent: Tuesday, October 20, 2015 11:29 AM, Linus Nordberg wrote:
> ...

Happy to see this! The text about email's Received field metadata has been
in drafts leading to RFC 7624 for more than a year, and it is very good that
someone active in the email working groups actually proposes a solution.

Now for a suggestion. Maybe that's a difference in personal writing styles,
but I found the draft a bit dry. I would have appreciated a discussion of
the scenarios, and a bit of emphasis on the "submission" part, which is the
most concerning for privacy.

-- Christian Huitema

---

From: Nick Doty <[email-masked]>
Date: Tue, 20 Oct 2015 15:10:44 -0700

Thanks for writing this up and for sharing!

> On Oct 20, 2015, at 11:28 AM, Linus Nordberg <[email-masked]> wrote:
> 
> Hi,
> 

I believe the introduction is trying to provide the use cases, but I think it would be worth elaborating in Section 2 as to why or when an operator should not add the Received header.

If the use cases are reasonably broad, then what would be the implications of recommending that all agents should not add a Received header unless engaged in debugging relay problems? If that were feasible, it seems like it would be more useful to those interested in privacy of this header if removing the header were common, rather than a positive indicator of the agent's choosing to maintain a special level of privacy.

Regarding the security considerations section, I don't think we should rely on a specification note that systems should be robust. In terms of implementations, do spam or abuse-filtering systems currently use the Received header in practice to identify and mitigate against email spam? What would be the security implications if widespread implementations removed the Received header?

Hope this helps,
Nick

---

From: Brian Trammell <[email-masked]>
Date: Wed, 21 Oct 2015 08:02:26 +0200

hi Linus,

+1 to the chorus of "thanks for writing this up".

I can't believe I'm going to pick 2119 nits on a -00, but here goes:

"If you care about X, MUST NOT" is a weird construct. MUST is "an absolute prohibition", so putting it next to a conditional isn't quite right. What I think you mean is covered exactly by SHOULD NOT:

  "there may exist valid reasons in particular circumstances when the
   particular behavior is acceptable or even useful, but the full
   implications should be understood and the case carefully weighed
   before implementing any behavior described with this label."

Of course, this sounds weaker than the nice hefty MUST NOT. But unless we want to deprecate the Received header completely and replace it with a less privacy-odious method to achieve operational debugging of SMTP (which i'd be fully in favor of, though I'm not an SMTP geek so I'm not sure what would be involved), this is as good as it gets.

What is unconditional, and can be specified as such for implementations, is that operators need a knob. So I'd suggest splitting this out, replacing section 2 in its entirety with:

SMTP protocol entities, including transfer agents and submission agents, MUST provide operators with a mechanism to configure whether a Received header will be added to the messages they handle. Operators of these protocol entities SHOULD disable the Received header using this mechanism in order to reduce risks to the privacy of the submitting entity.

Thanks again, cheers,

Brian

> On 20 Oct 2015, at 20:28, Linus Nordberg <[email-masked]> wrote:
> 
> Hi,
> 
> _______________________________________________
> perpass mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/perpass

---

From: [email-masked]
Date: Wed, 21 Oct 2015 21:27:02 -0700 (PDT)

> I'd be interested in hearing what people on the perpass list think of

It looks to me like the IETF is belatedly coming up to speed on a problem that
the email community - the large scale providers at least - is already in the
process of solving. And while it would be nice to write down some best
practices here so everyone knows what to do, the method described  in this
draft is *not* that best practice in any way, shape or form.

In fact its adoption would cause widespread damage to the email infrastructure.

Getting down to specifics: This proposal effectively makes the addition of
Received: fields optional: You only do it when you feel like it. The
obstensible purpose of this change is to prevent exposure of the sender's IP
address in the context of pervasive  surveillance.

However, this removal, were it to occur, is not terribly effective in achieving
this specific goal. Why? Because this does nothing prevent the IP address from
being logged elsewhere. And those logs often enjoy far less legal protection -
in some cases no protection at all - than actual message content. And good luck
convincing ISPs and MSPs not to collect this information.

If anything the removal of this information from messages for this claimed
result may create a false sense of security in regards to persuasive
surveilance.

All that said, there is a real privacy gain in not including this information
in messages. State actors with subpeona powers may have easy access to ISP/MSP
logs, but other players, including legitimate message recipients, do not. And
my location at the time I send a piece of mail really isn't the concern of any
of the message's recipients unless I choose to reveal it.

So where is the information stored and how can eliminate it safely? It's in the
from clause of the Receved: field generated by the SUBMIT server. The from
clause is mandatory, but there's noting that says the clause has to actualy
contain anything meaninful. So the obvious solution is to dummy information.
(My personal preference would be to define a well known name or names for this
purpose and use that without any IP address information at all, which the ABNF
in RFC 5321 explicitly allows.)

And this approach has already been deployed, successfully AFAICT. (To be fair,
gmail appears to have done it by dropping from clauses entirely - a syntax
violation.) We added an option to override the from clause to our product a few
months ago. (And I'm told we're fairly late to this particular party.)

Now, received fields are, as the draft notes, generated at other times, and the
name/address information in them can reveal internal network topology to some
extent. This concern is, IMNSHO, considerably overblown, but sanitizing from
clauses generated by internal relay steps may make sense in some specific cases.

And what about other aspects of the Received: field? The remainder of the (all
optional) clauses that Received: fields support also reveal information to some
extent and a detailed security analysis of all of them should be undertaken as
part of any work undertaken in this area.

That leaves the presence of the Received: field itself and the timestamp. The
former is critical to the proper functioning of the email transport
infrastructure: Received: field counting is the primary mechanism used to
prevent mail loops. And there's ample operational experience in the field with
the bad things that happen when the requirement to add Received: fields is
ignored or agents remove them willy-nilly.

The timestamp is quite useful in tracking routing delays after the fact. It
also doesn't reveal all that much given how it's going to be brackted by the
Date: field and the IMAP internaldate.

In summary, the present proposal as presently written is a nonstarter because
it breaks critical email functionality: The ability to detect and block mail
loops. In also unnecessarily causes the removal of highly useful timing and
trace information. An approach based on current inductry practices should be
considered instead and specific guidance on when the mechanism should be
employed needs to be given.

				Ned

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 22 Oct 2015 10:27:42 +0100

Ned,

> employed needs to be given.

I have to say that conclusion, or something like it, seems reasonable
even if the presentation of the argument leading up to it read to me
as being quite needlessly aggressive.

Ned - Is that an offer to help the authors e.g. by offering new text
or describing to them in more detail what others have done (maybe
via pointers) so the authors can document that better?

S.

PS: I would assume this draft will end up being processed via dispatch
(or however the art area continue handling small-new-work) so that it
will definitely get review from appropriate folks before being done.

---

From: [email-masked]
Date: Thu, 22 Oct 2015 03:47:41 -0700 (PDT)

Correction to my previous posting: The by clause is also mandatory in
Received: fields, and contains a domain and optionally an IP address.
To the extent it represents a privacy exposure, it can be handled in the
same fashion as the from clause.

				Ned

---

From: Simon Josefsson <[email-masked]>
Date: Fri, 23 Oct 2015 14:39:15 +0200

> someone active in the email working groups actually proposes a solution.

Thank you.

> most concerning for privacy.

Agreed -- the draft was written hastily before the IETF -00 cut-off date
and could surely benefit from a better introduction of the problem.  If
you have concrete suggestions on what to (or not) focus on in more
detail, that would be appreciated.  We will make a stab at improving
this section shortly.

/Simon

---

From: Simon Josefsson <[email-masked]>
Date: Fri, 23 Oct 2015 15:12:44 +0200

Hi Ned,

Thanks for looking at the document!

We are happy to make this more inline with what you and others are doing
or suggest to do.  With the -00 we wanted to get the ball rolling, to be
able to discuss what to do about the problem.  We don't care strongly
what the particlar approach is as long is it does its job.  Given the
responses so far, I believe we even have some work to do on getting the
problem statement itself right, let alone the proposed solution.

I agree with you about the problem related to loop detection (RFC 5321
section 6.1), so agree that it is a valid argument for not making the
header optional.

Jacob Appelbaum brought up that the trace information about what
authentication parameters were used can be interesting and does not
appear to be a significant privacy violation.  So that's another
argument for retaining the header.  He also mentioned that timestamp
information are problematic due to netflow related data.

I agree with your recommendation to retain the Received header but
modify what to put in it.  I believe the FROM clause should be removed
completely, or we put in a "magic" (syntactically valid but semantically
invalid) IPv4 or IPv6 address in it.  Similarily, implementations could
put a magic time-stamp value in the field if they don't want to reveal
when they received a particular message.

When I look at the ABNF for Received in RFC 5322 I'm confused as I don't
see how the normally used Received: headers on the Internet (i.e., with
'FROM', 'BY' etc clauses) actually conform to the 'received' ABNF token
or the 'obs-received' token.  Is this a RFC 5322 bug?  The BNF in RFC
822 and RFC 2822 appears to work.

We could use your help here :-)

/Simon

---

From: Simon Josefsson <[email-masked]>
Date: Fri, 23 Oct 2015 15:17:25 +0200

> same fashion as the from clause.

Thanks for pointing this out.  We didn't see the BY clause IP/hostname
as serious of a problem, since it is the entity who owns that IP address
who puts the line in there.  If that entity doesn't want its own IP
address in there, it could lie.  The FROM clause contains the IP address
of someone else, who the entity isn't necessarily authorized to store
and forward IP address information about, so it is more problematic.
But I agree that both concerns are relevant and that the document should
allow, and probably encourage, not leaking any of the IP addresses.

/Simon

---

From: Jacob Appelbaum <[email-masked]>
Date: Sat, 24 Oct 2015 21:12:14 +0000

> information are problematic due to netflow related data.

I think it should be possible to produce a general timing and to state
the crypto (or lack of crypto) used for transmission.

> when they received a particular message.

Those both seem reasonable.

> 822 and RFC 2822 appears to work.

A feature!. ;-)

All the best,
Jacob

---

From: "John Levine" <[email-masked]>
Date: 24 Oct 2015 22:46:21 -0000

>when they received a particular message.

I was going to say it would make it impossible for me to send spam
reports, since I would have to way to tell who sent it, but then I
realized it would make no difference, since each received header my
system adds has a sequence number I can look up in the mail logs and
find out the connecting IP and time and a lot of other stuff.

But I'd like to back up a little.  You know how crypto people feel
when someone shows up with a wonderful new crypto scheme?  And then
when the someone says well, just tell me what's wrong with it?  Mail
is a lot like that.  It's much more complex and subtle than it
appears, even to people who've used it casually for a long time.

There are lots and lots of ways that a mail system can leak PII that
are unrelated to Received headers.  For example, MTAs look up the
connecting IP of each message in DNSBLs, they check SPF records, they
look up DKIM key records (which in my mail are unique for every
message), they look up DMARC records, they swap checksums with bulk
counting systems, they put stuff in Authentication-Results: headers,
and that's just what I can think of in two minutes.  When a mail system
is large enough that it has to spread the load across multiple MTAs,
there's more traffic among them to keep things in sync.

My suggestion would be to start by finding people who have experience
in large mail systems (Ned would be a good start if he has the time),
and then state clearly what you're trying to do.  It looks like it's
identifying and minimizing the amount of PII collected, reported (to
downstream consumers), and logged (for internal users) for incoming
mail.  Once you've done that, it'd be quite interesting to try and see
what gets collected, and what the tradeoffs are if you don't collect
it or don't report or log it.

R's,
John

---

From: "Christian Huitema" <[email-masked]>
Date: Sun, 25 Oct 2015 18:42:09 -0700

> it or don't report or log it.

That sounds like a reasonable plan. Let's start, then. What about having
interested parties meet at a bar in Yokohama, say Monday evening, and start
drafting the first solution? I would be happy to pay the first round of
drinks, if that speeds up consensus...

-- Christian Huitema

---

From: "John R Levine" <[email-masked]>
Date: 25 Oct 2015 22:01:05 -0400

> drinks, if that speeds up consensus...

Sounds good to me.  See you there.  Be warned, consensus may be expensive.

R's,
John

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 26 Oct 2015 02:31:37 +0000

> Sounds good to me.  See you there.  Be warned, consensus may be expensive.

We don't yet need to establish consensus, progress identifying
issues and possible paths forward is all that's needed for now.
And while that could also require N beers, that'd be an entirely
reasonable cost for us all to share;-)

S

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 26 Oct 2015 09:35:22 +0100

> drinks, if that speeds up consensus...

Sounds like a good idea, thanks for suggesting it.  I'm hoping Linus
will be able to make it since I won't be there.

I am concerned about taking on a too wide scope.  I think it may be
possible to reach closure on improving the Received header wrt privacy.
I'm not against taking on the larger problems mentioned above, however I
feel that it should not stand in the way of progress of fixing some
identified problems of the Received header, and I worry that a wider
task may not reach closure.

To have a starting point for a problem statement for what I'd like to
focus on, the Received header, I would propose:

1) The Problem: SMTP agents add IP addresses and timestamp information
   about its clients in the Received header, in a way that clients
   aren't able to influence.

2) Deployment Consideration: Received headers are useful for mail loop
   detection and debugging by humans, and must continue to serve that
   purpose as good possible, so as long as it doesn't violate the
   privacy problem identified in 1).

3) Work-together Consideration: If there are deployment of related ideas
   already, we want to follow and describe them as long as it solves the
   problem in 1) and retain the useful properties in 2).

4) Simplicity: Pick the simplest solution that meets the requirements.

I'd like to get away from the focus on SMTP submissions, the privacy
violation affects all SMTP relaying.  Submission may be the most
critical part, but there are other situations when you don't want your
client's IP address or time of communication to leak.

/Simon

---

From: "John R Levine" <[email-masked]>
Date: 26 Oct 2015 10:31:32 -0400

> possible to reach closure on improving the Received header wrt privacy.

Perhaps, although all of that stuff is also useful for identifying sources 
of malware, phishing, and other online evils.

Assuming you agree that having someone's bank account credentials stolen 
is a privacy problem, this is not a simple question, and any simple answer 
is wrong.

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

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 26 Oct 2015 16:32:51 +0100

"John R Levine" <[email-masked]> writes:

> Perhaps, although all of that stuff is also useful for identifying
> sources of malware, phishing, and other online evils.
>
> Assuming you agree that having someone's bank account credentials
> stolen is a privacy problem, this is not a simple question, and any
> simple answer is wrong.

Agreed.  I'm merely concerned that if we can't come up with a solution
to having someone's bank account credentials stolen, we shouldn't stall
attempting to resolve smaller problems that we can identify, such as a
privacy violation in the Received header.

/Simon

---

From: "John R Levine" <[email-masked]>
Date: 26 Oct 2015 12:51:25 -0400

> privacy violation in the Received header.

I hope you agree with the part where I said that any simple answer is 
wrong.

On my system, most real mail comes from the three gorillas, from ISPs such 
as T-W and Comcast, and from local schools or businesses.  Since we are 
weenies, a certain amount comes through mailing lists.  In every one of 
those cases, the IP address in the received header is the address of the 
server at the mail system, the institution, or the mailing list.  It tells 
you nothing you didn't already know if you looked at the bounce address in 
the SMTP envelope, or the From: or List-ID: in the message body.

The spam mostly comes from compromised servers and botnets, where the IP 
tells you who the legitmate operator is (not the botnet operator) and 
indirectly where to send abuse reports.  Since that mail isn't sent by the 
party legitimately associated with the IP, and the only place the mail 
goes is back to the operator in a spam report, it's hard to see any 
privacy issues there, either.

If you were talking about Received headers added in submission rather than 
SMTP, there are plausible PII issues, but there you will find that as 
often than not the sending MTA already obscures the location of the user, 
particularly when messages are submitted via webmail.  On the other hand, 
for abuse management it's essential that it be there in some form so the 
sending system can figure out which of its users is misbehaving or has 
been compromised.

So I think it is fine to look at the issues and see where we might make 
improvements, but it is a bad idea to rush to naive changes that don't 
address real privacy issues but do cause real problems for operations and 
security.

Regards,

---

From: [email-masked]
Date: Tue, 27 Oct 2015 07:36:33 -0700 (PDT)

> I hope you agree with the part where I said that any simple answer is

I certainly do.

> the SMTP envelope, or the From: or List-ID: in the message body.

As I understand it the argument here is that these IP addresses may expose
internal network topology - IMO even if a legitimate concern not a personal
privacy issue and hence out of scope - or perhaps might be usable in some sort
of correlation attack aimed at determining the user's general location. The
latter, even if it's in the remote realm of possibility, is not something
that's going to come close to passing cost/benefit muster.

> privacy issues there, either.

Agreed.

> sending system can figure out which of its users is misbehaving or has

I actually did a little checking of this the other day, and found the
following:

Gmail:   webmail does not disclose originating client IP, apparently using
         invalid Received: field to avoid doing so
         submit discloses originating IP
Yahoo:   Neither webmail nor submit disclose originating IP, some Received:
         fields are invalid but this looks like an unrelated issue
Outlook: Neither webmail nor submit disclose originating IP, valid Received:
         fields
AOL:     webmail discloses originating client IP, can't test submit due to AOL
         brokenness
GMX:	 Both webmail and submit dislose originating client IP

I'm fairly sure that in the past there were more cases where original client
IPs were exposed. So what we're seeing is an industry that looks to already on
the way to addressing this concern, albeit in a fairly haphazard manner.

> address real privacy issues but do cause real problems for operations and

Agreed again.

				Ned

---

From: "John R Levine" <[email-masked]>
Date: 27 Oct 2015 11:16:45 -0400

> internal network topology -

Actually, at this point I don't understand what the IP address is supposed 
to expose beyond the location of a server which generally tells you 
nothing new about the location of the user.  Perhaps Simon can clarify.

> AOL:     webmail discloses originating client IP, can't test submit due to 
> AOL brokenness

I managed to configure Pine to send AOL mail, it logs the IP in both the 
Received: and X-AOL-IP headers.  But it uses TLS both on submit and 
outbound.

Regards,

---

From: [email-masked]
Date: Tue, 27 Oct 2015 09:31:36 -0700 (PDT)

> I am concerned about taking on a too wide scope.

There are possible issues either way. On the one hand, a wider scope has the
potential of getting too wide and losing focus on what can be accomplished. But
on the other hand, Received: fields do not exist in isolation, and if you don't
understand their context you're not going to be able to craft viable privacy
considerations recommendations for them.

> I think it may be

Not to put too fine a point on it, but you're a ways away from pinning down the
actual problem you want to solve here.

I already pointed out that Received: fields are, to a large extent, irrelevant
as far as state actors with access to transaction logs are concerned. This
leaves a rather different set of privacy concerns than the ones cited in the
current draft.

There's also the issue of submit versus relay. As far as I'm concerned you have
yet to elaborate a meaningful privacy case for routine suppression of
information in Received: fields generated by relay operations.

>    aren't able to influence.

First, you continue to fail to distinguish between SMTP (relay) and SUBMIT
(submission) here. These are separate protocols for a lot of very good reasons,
and you need to deal with them separately.

Second, the inability of of clients to influence the generation of Received:
fields is actually a feature, not a bug. And unless you are prepared to
substantiate a claim based on actual evidence of widely deployed email clients
acting in the interest of their user's privacy, it's almost certainly going to
be a privacy win as well.

Or, to put this another way, which do you think is easier to change: The
behavior of thousands of different clients currently in the hands of billions
of users, or the behavior of a handful of service providers?

>    privacy problem identified in 1).

This list is far from complete - the obvious omission is the use of Received:
fields for spam checks. Another is identifying sources of delays - transaction
logs are better for this but they only work within an administrative domain.
It's also the case that nobody - including all the email exports in the IETF -
are going to be able to create anything like a complete list of the uses of
Received: header fields out there.

Like it or not, this is what happens when something has been widely deployed
for over 25 years.

And despite the huge variability of the Received: fields that are generated,
it's entirely possible to write robust processing software for them. (The
assorted tricks for doing this are well known in the community.)

>    problem in 1) and retain the useful properties in 2).

The problem you're going to run into here is that ISPs/MSPs are generally not
very sharing about their plans. And folks like me that work with various
different ISPs /MSPs can't talk about the specifics of what's going on due to
nondisclosure arrangements.

> 4) Simplicity: Pick the simplest solution that meets the requirements.

Extensibility often trumps simplicity in the email space. It certainly does/did
in the design of Received: fields, and that's another thing that's going to
have to be dealt with by any specification that's written.

> violation affects all SMTP relaying.

You *really* need to substantiante this claim.

> Submission may be the most

Before I get into the timestamp issue, I want to reiterate John's excellent
point:

  You know how crypto people feel

There was a time when email was truly a heterogeneous store and forward system
spanning many protocols, message formats, gateways, and lots of other junk.
Messages were often delayed, sometimes by substantial amounts of time, and
routinely transited multiple administrative domains before being delivered. And
there were probably some things that could be discovered by looking at
Received: field timestamps at that point.

Those days are long gone. These days the majority of email messages are handled
in their entirely by a small number of large service providers. Of the
remainder, most are intra-domain business email handled by enterprise mail
systems like Microsoft Exchange. Tied to that is the inter-domain email from
those enterprise email systems. The vast majority of messages now only transit
one or two administrative domains.

All of these systems employ sophisticated queuing systems and storage
technologies and are highly optimized to transfer massive amounts of
email with exceptionally low latency. (Low latency is not just a user
experience win, it's also a win in terms of not needing as much queue storage.)
And by massive I mean tens of thousands of messages a second or more,
delivering to millions of users (or more), scattered across data centers all
over the world.

And even the tiny fraction of systems that are left are typically using
high quality open source like Exim, Postfix, or sendmail. These packages also
offer very good perfomance.

The result is that typical email delivery times have been driven down into the
tens of seconds range; a couple of minutes at most. And if there's more of a
delay, it's usually at the point of final delivery, which has no privacy
implications that I can see.

And when the times are higher than this, it's usually deliberate. For example,
I noticed when I did the testing I reported in a previous message that Yahoo
seems to consistently insert a three minute delay. (It's probably part of their
spam checks.)

And since the Received: fields are, modulo clock skew (now usually a nonissue
due to the widespread use of NTP) and coding errors, going to be bracketed by
the Date: field and the delivery timestamp, the amount of information conveyed
by the timestamps in normal operation is quite low, especially in terms of
privacy. (Their utility arises when things aren't normal, e.g., when you want
to know the reason for an abnormal delay or you use mistakes in their
construction as a spam indicator.)

The possible exception to this is the time zone. I'm having trouble coming
up with a scenario where the time zone of the Received: field provides
more insight than the one in the Date: field, but I suppose it's possible.
But if there's actually reason to care about this it can be dealt with simply
by saying "use UTC".

Now, this begs the question of what, if anything, to do about the Date: field.
It's required, and if the client doesn't insert it the submit server will. (Or
the message may be rejected as spam. And sending out bogus Date: field values
is *very* likely to trigger spam detectors.)

This makes it impossible to use regular email to send messages with an
indeterminate submission time, but with all due respect, that's not something
the regular email service is designed to provide, and given the low standard
deviation of end-to-end message tranfer with the use of extensions like
FUTURERELEASE, it's not something the regular email service can provide
in any meaningful way anyhow.

If you want to build such a service on top of regular email, it would have
to be done as some sort of remailer. Which is entirely possible to do, but
is entirely out of scope of what's being proposed here.

tl;dr Unless I'm missing something, timestamps are not a privacy concern.

				Ned

---

From: Linus Nordberg <[email-masked]>
Date: Thu, 29 Oct 2015 08:20:08 +0100

Simon Josefsson <[email-masked]> wrote
Mon, 26 Oct 2015 09:35:22 +0100:

| "Christian Huitema" <[email-masked]> writes:
[...]
| > That sounds like a reasonable plan. Let's start, then. What about having
| > interested parties meet at a bar in Yokohama, say Monday evening, and start
| > drafting the first solution? I would be happy to pay the first round of
| > drinks, if that speeds up consensus...
| 
| Sounds like a good idea, thanks for suggesting it.  I'm hoping Linus
| will be able to make it since I won't be there.

Meeting in person would be valuable. Monday is the only night I'm
unavailable though. I'd like to suggest Tuesday but I realise that this
might be a futile attempt. If you all go for Monday, I'll do my best to
catch up during the week.

Thanks,
Linus

---

From: "John R Levine" <[email-masked]>
Date: 30 Oct 2015 06:57:31 +0900

> unavailable though.

Any evening Mon-Thu is OK for me.

Regards,