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
- Re: [marf] Reviewers for draft-kucherawy-marf-sou… Steve Atkins
- [marf] Reviewers for draft-kucherawy-marf-source-… Murray S. Kucherawy
- Re: [marf] Reviewers for draft-kucherawy-marf-sou… Steve Atkins
- Re: [marf] Reviewers for draft-kucherawy-marf-sou… Scott Kitterman
- Re: [marf] Reviewers for draft-kucherawy-marf-sou… Murray S. Kucherawy
- Re: [marf] Reviewers for draft-kucherawy-marf-sou… John Levine
- Re: [marf] Reviewers for draft-kucherawy-marf-sou… Murray S. Kucherawy
- Re: [marf] Reviewers for draft-kucherawy-marf-sou… Steve Atkins
- Re: [marf] Reviewers for draft-kucherawy-marf-sou… Scott Kitterman
- Re: [marf] Reviewers for draft-kucherawy-marf-sou… John Levine
- Re: [marf] Reviewers for draft-kucherawy-marf-sou… Steve Atkins
- Re: [marf] Reviewers for draft-kucherawy-marf-sou… Douglas Otis