What? : Delivery Status Notification (Failure) (fwd)

["Stephen J. Wilcox" <steve () telecomplete co uk>]

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



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
> --- Begin Message ---
>
>
> From: "Stephen J. Wilcox" <steve () telecomplete co uk>
>
> Date: Wed, 9 Oct 2002 23:05:59 +0100 (BST)
>
>
> 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
>
>
>
>
> --- End Message ---