Re: [marf] Reviewers for draft-kucherawy-marf-source-ports

Steve Atkins <steve@wordtothewise.com> Fri, 20 April 2012 15:45 UTC

Return-Path: <steve@wordtothewise.com>
X-Original-To: marf@ietfa.amsl.com
Delivered-To: marf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94B4021F87A2 for <marf@ietfa.amsl.com>; Fri, 20 Apr 2012 08:45:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Mh457ZQcxXB for <marf@ietfa.amsl.com>; Fri, 20 Apr 2012 08:45:15 -0700 (PDT)
Received: from m.wordtothewise.com (misc.wordtothewise.com [184.105.179.154]) by ietfa.amsl.com (Postfix) with ESMTP id D12CC21F8726 for <marf@ietf.org>; Fri, 20 Apr 2012 08:45:14 -0700 (PDT)
Received: by m.wordtothewise.com (Postfix, from userid 1003) id E292A2EB29; Fri, 20 Apr 2012 08:45:13 -0700 (PDT)
Received: from platter.wordtothewise.com (204.11.227.194.static.etheric.net [204.11.227.194]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: steve) by m.wordtothewise.com (Postfix) with ESMTPSA id 0D8782DECF for <marf@ietf.org>; Fri, 20 Apr 2012 08:45:11 -0700 (PDT)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Apple Message framework v1257)
From: Steve Atkins <steve@wordtothewise.com>
In-Reply-To: <20120420123909.19568.qmail@joyce.lan>
Date: Fri, 20 Apr 2012 08:45:11 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <1DE48267-9D57-42C8-A46D-0B1DEAD02326@wordtothewise.com>
References: <20120420123909.19568.qmail@joyce.lan>
To: marf@ietf.org
X-Mailer: Apple Mail (2.1257)
Subject: Re: [marf] Reviewers for draft-kucherawy-marf-source-ports
X-BeenThere: marf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Message Abuse Report Format working group discussion list <marf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/marf>, <mailto:marf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/marf>
List-Post: <mailto:marf@ietf.org>
List-Help: <mailto:marf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/marf>, <mailto:marf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 20 Apr 2012 15:45:15 -0000

On Apr 20, 2012, at 5:39 AM, John Levine wrote:

>> Sure it is.  Additional complexity doesn't come for free, so it shouldn't be 
>> accepted without reason.
> 
> Having added Source-Port to my reporting scripts yesterday, I can say that
> the additional complexity involved is quite small.
> 
> Remember that this draft is just implementing the logging advice in
> RFC 6302, whose authors work at Juniper, Yahoo, Facebook, and AT&T.  I
> would assume that their employers wouldn't have given them time to
> work on it if they didn't think it would be of some value.

Email through dynamic NAT is not the same as HTTP through dynamic
NAT, though.

Source port only provides useful information to the report recipient if
there are at least two SMTP sessions from the NAT to the same MX
initiated (SYN) within a second or two of each other, and one of those
SMTP sessions is a cause for complaints and one of those SMTP
sessions is legitimate email. And the mail that's causing complaints
needs to be "direct-to-MX" bot-style spoor, most likely, or there'll
be plenty of information in the Received headers of the mail that's
being complained about to identify the customer more easily than
going through NAT logs.

Adding source port information to an ARF report only benefits the
sender of the report if all the above are true, and the report recipient
is going to expend the effort to grovel through their NAT logs to identify
the rooted machine that's spewing spam, despite them not caring about
emitting spam to the extent of blocking port 25 outbound from their
NAT. 

(I deal with a lot of customers who dynamically assign their
customers IP addresses, and the effort involved in dealing with
that data as part of complaint handling is significant, and it's painful
enough that they cannot do it in anything close to real time. NAT
logs are going to be much larger, and much more dynamic. Groveling
through them is going to take *significant* effort.)

When you combine the technical and the social, I don't think adding
the source port is going to change the result of the ARF report in a
significant number of cases.

Cheers,
  Steve