[53506] in North American Network Operators' Group
What? : Delivery Status Notification (Failure) (fwd)
daemon@ATHENA.MIT.EDU (Stephen J. Wilcox)
Sat Nov 16 07:29:29 2002
Date: Sat, 16 Nov 2002 12:28:56 +0000 (GMT)
From: "Stephen J. Wilcox" <steve@telecomplete.co.uk>
To: nanog@merit.edu
Errors-To: owner-nanog-outgoing@merit.edu
This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.
Send mail to mime@docserver.cac.washington.edu for more info.
--9B095B5ADSN=_01C26BF46D7492C60013CF7Ashure.shure.com
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-ID: <Pine.LNX.4.21.0211161226142.23418@MrServer>
anyone else receiving a large number of bounces from nanog deliveries to the
below address dated over the past 3 months?
anyone at shure.com care to stop it as they're still coming!
---------- Forwarded message ----------
Date: Fri, 11 Oct 2002 20:01:45 -0500
From: postmaster@shure.com
To: steve@telecomplete.co.uk
Subject: Delivery Status Notification (Failure)
This is an automatically generated Delivery Status Notification.
Unable to deliver message to the following recipients, due to being unable to connect successfully to the destination mail server.
Administrator@shure.com
--9B095B5ADSN=_01C26BF46D7492C60013CF7Ashure.shure.com
Content-Type: MESSAGE/DELIVERY-STATUS; CHARSET=US-ASCII
Content-ID: <Pine.LNX.4.21.0211161226143.23418@MrServer>
Content-Description:
Reporting-MTA: dns;shure.shure.com
Received-From-MTA: dns;shure.shure.com
Arrival-Date: Wed, 9 Oct 2002 20:00:37 -0500
Final-Recipient: rfc822;Administrator@shure.com
Action: failed
Status: 4.4.7
--9B095B5ADSN=_01C26BF46D7492C60013CF7Ashure.shure.com
Content-Type: MESSAGE/RFC822; CHARSET=US-ASCII
Content-ID: <Pine.LNX.4.21.0211161226144.23418@MrServer>
Content-Description:
Received: from shure.shure.com ([206.126.224.29]) by shure.shure.com with Microsoft SMTPSVC(5.0.2195.5329);
Wed, 9 Oct 2002 20:00:37 -0500
Received: by shure.shure.com (Microsoft Connector for POP3 Mailboxes 5.00.2195) with SMTP (Individual POP3 Download)
id MSG10092002-200027-3176.MMD@shure.com for <Administrator@shure.com>; Wed, 9 Oct 2002 20:00:27 -0500
Return-Path: <owner-nanog@merit.edu>
Delivered-To: sayler@speedsite.com
Received: (qmail 12284 invoked from network); 9 Oct 2002 19:15:32 -0500
Received: from trapdoor.merit.edu (198.108.1.26)
by ghanima.speedsite.com with SMTP; 10 Oct 2002 00:15:32 -0000
Received: by trapdoor.merit.edu (Postfix)
id 697F491205; Wed, 9 Oct 2002 18:01:16 -0400 (EDT)
Delivered-To: nanog-outgoing@trapdoor.merit.edu
Received: by trapdoor.merit.edu (Postfix, from userid 56)
id D6B0C91207; Wed, 9 Oct 2002 18:01:13 -0400 (EDT)
Delivered-To: nanog@trapdoor.merit.edu
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
by trapdoor.merit.edu (Postfix) with ESMTP id 7C58091205
for <nanog@trapdoor.merit.edu>; Wed, 9 Oct 2002 18:00:39 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
id BE9675E0E3; Wed, 9 Oct 2002 18:00:36 -0400 (EDT)
Delivered-To: nanog@merit.edu
Received: from mail.telecomplete.net (unknown [193.0.249.129])
by segue.merit.edu (Postfix) with ESMTP id 61D335DEF3
for <nanog@merit.edu>; Wed, 9 Oct 2002 18:00:36 -0400 (EDT)
Received: from steve (helo=localhost)
by mail.telecomplete.net with local-esmtp (Exim 4.10)
id 17zOxr-0005eE-00; Wed, 09 Oct 2002 23:05:59 +0100
Date: Wed, 9 Oct 2002 23:05:59 +0100 (BST)
From: "Stephen J. Wilcox" <steve@telecomplete.co.uk>
X-Sender: steve@MrServer
To: Joe Abley <jabley@isc.org>
Cc: "Greg A. Woods" <woods@weird.com>,
Sean Donelan <sean@donelan.com>, nanog@merit.edu
Subject: Re: Who does source address validation? (was Re: what's that smell?)
In-Reply-To: <401DA51B-DBAA-11D6-9DEC-00039312C852@isc.org>
Message-ID: <Pine.LNX.4.21.0210092252340.21704-100000@MrServer>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-nanog@merit.edu
Precedence: bulk
Errors-To: owner-nanog-outgoing@merit.edu
X-Loop: nanog
X-UIDL: 796150dd2d520559e6384aa5e65a1eeb
X-OriginalArrivalTime: 10 Oct 2002 01:00:37.0937 (UTC) FILETIME=[72432210:01C26FF8]
On Wed, 9 Oct 2002, Joe Abley wrote:
>
>
> On Wednesday, Oct 9, 2002, at 11:36 Canada/Eastern, Stephen J. Wilcox
> wrote:
>
> > On Tue, 8 Oct 2002, Greg A. Woods wrote:
> >
> >> Such things REALLY _NEEED_ to be broken, and the sooner the better as
> >> then perhaps the offenders will fix such things sooner too, because
> >> they
> >> are by definition already broken and in violation of RFC 1918 and good
> >> common sense.
> >
> > Ok but real world calling. I have tried this and when customers find
> > something
> > doesnt work on your network but it does on your competitor you make it
> > work even
> > if that means breaking rules.
>
> What services require transport of packets with RFC1918 source
> addresses across the public network?
None afaik which is why they should be blocked - on ingress from customer links.
Dont get me wrong, I'm just sharing experience not ethics and saying we should
all adhere to the RFC but if you apply filters that assume others are also doing
so you may be surprised..
Without repeating myself or list archives its all very well strictly following
all the RFC guidelines and saying to tell the planet its Microsoft or @Home's
fault its not working but the customers really dont buy it and they will go
elsewhere and it mightnt be about corporate $$$s but those same $$$s pay your
wages and then it starts to hurt!
> I can think of esoteric examples of things it would be possible to do,
> but nothing that a real-world user might need (or have occasion to
> complain about).
On a related issue (pMTU) I recently discovered that using a link with MTU <
1500 breaks a massive chunk of the net - specifically mail and webservers who
block all inbound icmp.. the servers assume 1500, send out the packets with DF
set, they hit the link generating an icmp frag, icmp is filtered and data
stops. Culprits included several major ISP/Telcos ... I'd love to tell the
customer the link is fine its the rest of the Internet at fault but in the end I
just forced the DF bit clear as a temp workaround before finally swapping out to
MTU 1500!
> Do you have experience of such breakage from your own customers? It
> would be interesting to hear details.
I did attempt strict ingress filtering at borders after a DoS some time ago, I
figured I'd disallow any non public addresses. I took it off within a day after
a number of customers found a whole bunch of things had stopped working...
Unfortunately I cant give you an example as this was a while back and I dont
have the details to hand.
But if anyone with an appreciable sized customer base wants to try implementing
such filters feel free to forward the customer issues to the list as references!
Steve
--9B095B5ADSN=_01C26BF46D7492C60013CF7Ashure.shure.com--
