I wouldn't expect the businesses of any size to be interested in blocking bad addresses from being emitted. From what I've seen of mail server installs, it ain't pretty. I would expect their networks to be similar.
Wouldn't the upstream provider to know what netblock(s) are on what incoming interface? If so, why can't they block anything outside that range. They already block traffic to RFC1918 addresses accidentally sent to them. "Dobbins, Roland" <[email protected]> wrote on 10/25/2012 11:33:03 PM: > The problem is that the increase in helpdesk call volume and > trouble-tickets will have a negative economic impact on the > infrastructure vendors. > > Believe me, this has been a source of contentious debate within > major network infrastructure vendors. Like you, I wish it could be > the default; but, absent some mechanism which doesn't cause problems > in some non-isignificant fractions of deployment scenarios, it isn't > going to happen. > > One thing to keep in mind is that a lot of low-end gear which is > really intended for internal enterprise use is deployed on public- > facing networks by folks who either don't know any better or who > just don't care. Same for code trains which are oriented towards > enterprise LAN/WAN rather than Internet use. So, the infrastructure > vendors can't differentiate between 'enterprise' and 'Internet' > boxes/code in order to set the defaults where they'd do the least > amount of harm - and even then, the economic cost of the helpdesk > calls/tickets would still be prohibitive. Confidentiality Notice: This electronic message and any attachments may contain confidential or privileged information, and is intended only for the individual or entity identified above as the addressee. If you are not the addressee (or the employee or agent responsible to deliver it to the addressee), or if this message has been addressed to you in error, you are hereby notified that you may not copy, forward, disclose or use any part of this message or any attachments. Please notify the sender immediately by return e-mail or telephone and delete this message from your system. _______________________________________________ dns-operations mailing list [email protected] https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
