Re: [perpass] SMTP and SRV records

Brian Trammell <> Wed, 25 November 2015 10:20 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id DDFC01A1A42 for <>; Wed, 25 Nov 2015 02:20:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.487
X-Spam-Status: No, score=-2.487 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.585, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id zYLF4L2PL9-N for <>; Wed, 25 Nov 2015 02:20:25 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id CCDB61A1A30 for <>; Wed, 25 Nov 2015 02:20:24 -0800 (PST)
Received: from [IPv6:2001:67c:10ec:52c7:8000::41b] (unknown [IPv6:2001:67c:10ec:52c7:8000::41b]) by (Postfix) with ESMTPSA id 3D2CB1A00B1; Wed, 25 Nov 2015 11:19:53 +0100 (CET)
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
Content-Type: multipart/signed; boundary="Apple-Mail=_18727992-DC6B-43A6-BFF3-F031DA70DDD1"; protocol="application/pgp-signature"; micalg="pgp-sha512"
X-Pgp-Agent: GPGMail 2.5.2
From: Brian Trammell <>
In-Reply-To: <>
Date: Wed, 25 Nov 2015 11:19:52 +0100
Message-Id: <>
References: <> <> <>
To: Derek Fawcus <>
X-Mailer: Apple Mail (2.2104)
Archived-At: <>
Cc: perpass <>
Subject: Re: [perpass] SMTP and SRV records
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 25 Nov 2015 10:20:27 -0000

> On 25 Nov 2015, at 08:11, Derek Fawcus <> wrote:
> On Tue, Nov 24, 2015 at 10:25:03PM +0100, Eliot Lear wrote:
>> Hi Derek,
>> What benefit would this add to the average user?
> 1. the snoopers have to potentially listen to all ports

This adds *zero* cost. The granularity of packet capture for most technologies I know of is interface-level. Ports don't exist here: you have to capture the packet to parse the transport header to know what the port is. Filtering on ports (e.g. with bpf) is a nice bit of syntactic sugar that allows you to have the kernel not bother you with ports you don't care about, but the work of parsing has to be done anyway.

> 2. it makes traffic analysis (for SMTP) more awkward to implement

You simply have to attempt to match SMTP over all the traffic as opposed to just that on port 25. This parallelizes *really* well, though, and I doubt this costs more than a few millipennies of AWS time per gigabit of traffic, because you can reject non-SMTP very early in the flow.

> 3. doesn't require use of a certificate / encryption.

Not necessarily a feature, but I do get that SRV record management is somewhat easier than cert management.

Don't get me wrong, using SRV records for port agility is in general a good idea; MX is simply a pre-SRV hack and it would be cool to see it deprecated (sometime in the late 2030s, perhaps). But I don't know that I'd try to sell it as a privacy technique.



> So assume that tcpinc (or SMTP+TLS) gets wide deployment,
> that still leaves 1 & 2 above.
> Maybe at the moment most users take advantage of an ISP's smart
> host,  and so there would seem to be little benefit wrt 2 above.
> However one of the impacts of the IPB looks to be encouraging
> more people to run their own SMTP server,  or at least one with
> a restricted set of users,  when point 2 becomes more significant.
> DF
> _______________________________________________
> perpass mailing list