- Test - lists.nanog.org

Architectural Solutions to Internet Congestion Based On SS7 and Intelligent Network Capabilities
by Sharif Torpis 06 Nov '97

06 Nov '97

I thought more than a few here would be interested in this press release and referenced white paper: http://www.bellcore.com/DISCOVER/PRESS/internetpr.html

3 2

Re: New MAE-EAST
by Richard Irving 06 Nov '97

06 Nov '97

Richard Irving wrote: > > Paul D. Robertson wrote: > > > > On Wed, 5 Nov 1997, Adam Hersh wrote: > > > > > With all of the problems with MAE-EAST..... > > > > > > Any plans from anyone to create a ATM exchange point in the DC area? > > > > Given the latency we've seen over some ATM backbones, I certainly hope not. I > > agree with Paul that MTU sizes in gigabit ethernet make it very > > attractive as a next step, Our nets *Scream*. > > I'd certainly be interested in seeing anything > > anyone has on fragmentation related delays going from a large MTU switched > > environment to a small MTU switched environment though. Overall, I've > > been less-than-pleased with latency when I've been transited that way. > > Uh... Doctor , it hurts when I do this. Doctor: So don't do that! Hint, it is *pretty* foolish to run mixed MTU's on switched fabric. *Most* people on ATM exchanges run with common MTU's. > > Paul > > ------------------------------------------------------------------------- > > Paul D. Robertson > > gatekeeper(a)gannett.com

1 0

Re: zone transfers
by Edward Vielmetti 05 Nov '97

05 Nov '97

I am running an audit of the in-addr zone to determin the extent of defective delegations. If your systems have delegations for zones under in-addr.arpa, they will be probed during the course of the audit. It is expected that the audit will complete within the next 8-10 days, if there are no interuptions. This would be a very useful report to run at appropriate (monthly?) intervals, with results posted as far and wide as Tony Bates's CIDR Report. thanks Ed Edward Vielmetti emv(a)umich.edu (alumni)

2 1

Re: moving to IPv6
by Pedro Marques 05 Nov '97

05 Nov '97

phil(a)charon.milepost.com (Phil Howard) writes: > The transition to IPv6 is clearly going to have some difficulties. We are > waiting on: > > 1. Network equipment, with translation > > 2. End user software > > 3. Address space assignment nice list. > IPv6-only space is of less value than IPv4-private space until IPv6 > becomes at least fully routeable over the Internet. So the backbone > networks are going to have to take the lead to make it happen. Even > when it is routeable, it has to work on all the ends, which will thus > have to have translations to make their IPv4 space appear as IPv6sub4 > space. > > The best workable scenario I can see so far is one where IOS and other > routing software includes translation between IPv4 and IPv6 IOS IPv6 prototype does include that facility. It translates to and from an arbitrary v4 network and an arbitrary v6 network. > Something is thus needed to encourage customers to move into IPv6 even > when it is fully routeable. That is really the key issue... because even with IPv6 NAT (protocol translation) working, IPv6 is as actractive as using IPv4 NAT, unless it brings some value added to the end customers... The potential advantage i see is autoconfiguration support. But DHCP can actually do the same job reasonably well. > But just having IOS translating IPv4 <-> IPv6s4 is not enough. Agreed. > We will need to manage the new IPv6 network. All the various tools we > use will need to understanding IPv6 and how it it configured on the > network. Routing will have to work right even during the transition > to this, which means BGP4v6 has to be there capable of understanding > IPv6 space at some point in time. BGP4 + Multiprotocol Extensions is able to do the job. And it is working resonably well... > > Routing issues will become different in IPv6. How ? > > If IPv6 allocations will have varying sizes like CIDR, then we might > continue to have issues of size based route filtering. OTOH, with the > right methods of allocating IPv6 space, no one should ever have to come > back to get more space. Eventually that should mean fewer routes as > IPv4/IPv6s4 closes down. Route filtering should be encouraged on IPv4 > space and prohibited on IPv6 space, at that point, IMHO. I don't think i really understand your point here.... The only "difference" when it comes to routing information i can think off is that in IPv6 there isn't suppose to be address ownership (which creates holes into CIDR blocks)... but it seems to me that the same policy is being adopted for IPv4. Pedro.

3 2

Overloaded semantics (was Re: moving to IPv6)
by rja＠corp.home.net 05 Nov '97

05 Nov '97

At the risk of stating the obvious, an observation about NAT and security... The problem is that IP addresses have overloaded semantics. Security needs an identifier. NAT and routing need locators. At present IP addresses serve both functions. We need to move to a world where locating a node is decoupled from identifying a node. In such a world, NAT could happen without causing IPsec to get broken by the NAT function. The overloaded semantics are broken. Noel has probably been the most outspoken in making this observation, but others have also noted the issue. Ran rja(a)Home.net

2 1

MAE-East update
by J.D. Falk 05 Nov '97

05 Nov '97

Just got a call from Worldcom; here's what they told me. Apparently the core gigaswitch will periodically reset and switch to another processor, which may cause brief outages. Worldcom and DEC techs are trying to reproduce this in a lab so that they can figure out exactly what's causing it. Life on the bleeding edge is /so/ much fun. (NOT!) ********************************************************* J.D. Falk voice: +1-650-482-2840 Supervisor, Network Operations fax: +1-650-482-2844 PRIORI NETWORKS, INC. http://www.priori.net "The People You Know. The People You Trust." *********************************************************

7 6

zone transfers
by bmanning＠ISI.EDU 05 Nov '97

05 Nov '97

I am running an audit of the in-addr zone to determin the extent of defective delegations. If your systems have delegations for zones under in-addr.arpa, they will be probed during the course of the audit. It is expected that the audit will complete within the next 8-10 days, if there are no interuptions. --bill

2 2

Re: moving to IPv6
by Sean M. Doran 05 Nov '97

05 Nov '97

I apologize that the quality of this message will be somewhat limited by pressures of time and having to use a really weird Microsoft keyboard that leaves me prone to speeling mistakes, but I couldn't resist some of the things being talked about in this thread. Phil Howard <phil(a)charon.milepost.com> writes: > The transition to IPv6 is clearly going to have some difficulties. We are > waiting on: > > 1. Network equipment, with translation > translation > have to have translations > routing software includes translation Bingo! The thing that amazes me about people who are fans of IPv6 is that they have realized that NAT is THE fundamental scaling technology for the Internet. Translation of addresses, whether it is between IPv4 and IPv4 or involves protocol translations as well (as is the case in IPv4->IPv6->IPv4, or IPv6->IPv4->IPv6), is simply the most practical and effective way of overcoming the two principal scaling problems of the Internet, namely the narrowness of the IPv4 address and the fact that deployed routing protocols simply suck. Observe that so long as a translatable subset of transport layer options are used, there is absolutely no difference between NAT between IPv4 addresses and protocol translation between IPv4 and IPv6. Moreover, in the latter case, you are not restricted to IPv6s4 (who comes up with these acronyms anyway? Does anyone mind if I call IPv4 IP? If you do, well, tough.) The technical goal is that end to end services will work, period, in all cases. This is possible provided that the higher order protocols do not make invalid assumptions about the transport layer. Most importantly, just as CIDR requires that protocol implementations respect that IP addresses may change over time, NAT as THE new fundamental scaling technology requires that protocol implementations respect that IP addresses may change over space as well. That is, so long as protocols do not assume that an IP address is the same from the point of view of all locations throughout the concatenated Internet, they will do just fine with either NAT or protocol translation or both. Returning to the observation that NAT and protocol translation are semantically equivalent from an end-to-end perspective, we now need to consider whether simple address translation or protocol translation is a better idea. > But just having [network routing software] translating IPv4 <-> IPv6s4 is not enough. > We will need to manage the new IPv6 network. Deployed base is a strong engineering consderation in an industry which is experiencing enormous growth. NAT has the advantage that reasonably designed existing technologies ought not even notice that NAT is happening. Protocol translation, on the other hand, requires, as you say, new management techniques, which will generally involve lots of learning time on the part of lots of engineers and operators, wherever the new protocol is deployed. The fact is, that there may be a reason to deploy a new protocol that makes this worthwhile, however, you should also note that so long as a translation between transport layers is straightforward, there is no reason why the new protocol needs to be IPv6. In fact, I welcome IPv6's fan base working on protocol translation because there are also some more interesting experimental protocols which could be deployed in precisely the same fashion that do not suffer some of the brokenesses of IPv6. Most notably: > Routing issues will become different in IPv6. This is simply untrue. Routing issues are EXACTLY the same in IP and IPv6, the only difference is the width of the addresses, which worsens the poor scaling properties of IP with current routing protocols. The only attractive (and this is very very very speculative) aspect of the IPv6 address scheme is that it may be wide enough to experiment with something like using a modified IS-IS that works on multiple hierarchical areas encoded as fields in the IPv6 address, with the thought of using that to supplant current interdomain routing protocols. I'm sure this thought will go over well with the IPv6 crowd... > If IPv6 allocations will have varying sizes like CIDR, then we might > continue to have issues of size based route filtering. Please understand that the size-based filtering is done to limit the number of prefixes carried, and that this is completely independent of IP vs IPv6. If the number of prefixes must be kept to some maximum by filtering at, say, the 19 bit mark, the same maximum will be maintained even if the address space is much wider, and the straightforward way of doing that is to retain filters at the 19 bit mark. > OTOH, with the > right methods of allocating IPv6 space, no one should ever have to come > back to get more space. Eventually that should mean fewer routes as > IPv4/IPv6s4 closes down. Route filtering should be encouraged on IPv4 > space and prohibited on IPv6 space, at that point, IMHO. Could you pleace elaborate? I am completely lost by your logic here. Sean.

13 20

fwd: RealPlayer 5.0/Linux (from RedHat-Announce)
by Jay R. Ashworth 05 Nov '97

05 Nov '97

Pertinent to a conversation played out here just before NANOG. -----Forwarded message from Steven Krikstone <triden(a)scooby.cheney.net>----- From: Steven Krikstone <triden(a)scooby.cheney.net> To: redhat-announce-list(a)redhat.com Subject: RealPlayer 5.0 Beta Message-ID: <Pine.LNX.3.95.971104170549.17532A-100000(a)scooby.cheney.net> Just to let everyone know, RealAudio has released RealPlayer 5.0 Beta 1 for Linux. I've been using it for a few days and haven't come across any glaring bugs. The major difference between 3.0 and 5.0 is that streaming video can be displayed. Even more important than that, you don't have to start netscape with a private colormap; a much needed addition. The gzip'ed tar file is easy to install, and you need only to complete a few steps to get it working on RH. (I'd make a .rpm, but I think the license I read forbids it, someone let me know if I'm wrong) NOTE: Read the README.FIRST that is contained in the tarball. It contains important steps needed to correctly setup RealPlayer. The program can be found at: http://www.real.com/products/player/download_player.html --- Steven Krikstone Cheney Communications -----End of forwarded message----- HTH. Cheers, -- jra -- Jay R. Ashworth jra(a)baylink.com Member of the Technical Staff Unsolicited Commercial Emailers Sued The Suncoast Freenet "Pedantry. It's not just a job, it's an Tampa Bay, Florida adventure." -- someone on AFU +1 813 790 7592

1 0

tcsender email bombing
by Dennis Simpson 05 Nov '97

05 Nov '97

Having seen fairly heavy loading on our mail server today, I decided to see what might be going on. Is anyone else seeing concerted bombing from tcsender@<a couple of addresses> where the relayhost covers many hosts? I have attached a tiny bit of today's mail syslog contents below to illustrate. Approximately one third of our email traffic today has come from this. I am going to be blocking a number of the ip's at our router, due to the heavy load this is causing us. Is anyone else having to handle this nonsense (tcsender specifically) or should I be looking for someone attacking us? Thx, dennis Nov 4 04:05:48 bconnex.net sendmail[4697]: Ruleset check_mail (<tcsender(a)get-more-hits.com>) rejection: 451 <tcsender(a)get-more-hits.com>... Domain must resolve Nov 4 04:05:48 bconnex.net sendmail[4697]: EAA04697: from=<tcsender(a)get-more-hits.com>, size=0, class=0, pri=0, nrcpts=0, proto=ESMTP, relay=root(a)astra.genghis.com [205.139.15.34] Nov 4 04:05:54 bconnex.net sendmail[4698]: Ruleset check_mail (<tcsender(a)get-more-hits.com>) rejection: 451 <tcsender(a)get-more-hits.com>... Domain must resolve Nov 4 04:05:54 bconnex.net sendmail[4698]: EAA04698: from=<tcsender(a)get-more-hits.com>, size=0, class=0, pri=0, nrcpts=0, proto=SMTP, relay=root(a)busche.com [206.83.162.16] Nov 4 04:05:57 bconnex.net sendmail[4703]: Ruleset check_mail (<tcsender(a)get-more-hits.com>) rejection: 451 <tcsender(a)get-more-hits.com>... Domain must resolve Nov 4 04:05:57 bconnex.net sendmail[4703]: EAA04703: from=<tcsender(a)get-more-hits.com>, size=0, class=0, pri=0, nrcpts=0, proto=SMTP, relay=root(a)www.fredrick.com [209.113.166.92] Nov 4 04:06:04 bconnex.net sendmail[4705]: Ruleset check_mail (<tcsender(a)need-hits.com>) rejection: 451 <tcsender(a)need-hits.com>... Domain must resolve Nov 4 04:06:04 bconnex.net sendmail[4705]: EAA04705: from=<tcsender(a)need-hits.com>, size=0, class=0, pri=0, nrcpts=0, proto=ESMTP, relay=bay.wiznet.ca [207.139.40.1] Nov 4 04:06:08 bconnex.net sendmail[4712]: Ruleset check_mail (<tcsender(a)get-more-hits.com>) rejection: 451 <tcsender(a)get-more-hits.com>... Domain must resolve Nov 4 04:06:08 bconnex.net sendmail[4712]: EAA04712: from=<tcsender(a)get-more-hits.com>, size=0, class=0, pri=0, nrcpts=0, proto=ESMTP, relay=root(a)[204.254.231.160] Nov 4 04:06:22 bconnex.net sendmail[4723]: Ruleset check_mail (<tcsender(a)get-more-hits.com>) rejection: 451 <tcsender(a)get-more-hits.com>... Domain must resolve Nov 4 04:06:22 bconnex.net sendmail[4723]: EAA04723: from=<tcsender(a)get-more-hits.com>, size=0, class=0, pri=0, nrcpts=0, proto=ESMTP, relay=root(a)linked.net [209.24.1.201] Nov 4 04:06:27 bconnex.net sendmail[4731]: Ruleset check_mail (<tcsender(a)need-hits.com>) rejection: 451 <tcsender(a)need-hits.com>... Domain must resolve Nov 4 04:06:27 bconnex.net sendmail[4731]: EAA04731: from=<tcsender(a)need-hits.com>, size=0, class=0, pri=0, nrcpts=0, proto=ESMTP, relay=emke.com [204.152.178.10] Nov 4 04:06:43 bconnex.net sendmail[4758]: Ruleset check_mail (<tcsender(a)get-more-hits.com>) rejection: 451 <tcsender(a)get-more-hits.com>... Domain must resolve Nov 4 04:06:43 bconnex.net sendmail[4758]: EAA04758: from=<tcsender(a)get-more-hits.com>, size=0, class=0, pri=0, nrcpts=0, proto=ESMTP, relay=adzone.com [205.147.5.1] Nov 4 04:06:50 bconnex.net sendmail[4776]: Ruleset check_mail (<tcsender(a)get-more-hits.com>) rejection: 451 <tcsender(a)get-more-hits.com>... Domain must resolve Nov 4 04:06:50 bconnex.net sendmail[4776]: EAA04776: from=<tcsender(a)get-more-hits.com>, size=0, class=0, pri=0, nrcpts=0, proto=ESMTP, relay=[209.63.20.193] Nov 4 04:07:12 bconnex.net sendmail[4800]: Ruleset check_mail (<tcsender(a)need-hits.com>) rejection: 451 <tcsender(a)need-hits.com>... Domain must resolve Nov 4 04:07:12 bconnex.net sendmail[4800]: EAA04800: from=<tcsender(a)need-hits.com>, size=0, class=0, pri=0, nrcpts=0, proto=SMTP, relay=mercury.webserve.net [206.96.226.5] Nov 4 04:07:13 bconnex.net sendmail[4802]: Ruleset check_mail (<tcsender(a)need-hits.com>) rejection: 451 <tcsender(a)need-hits.com>... Domain must resolve Nov 4 04:07:13 bconnex.net sendmail[4802]: EAA04802: from=<tcsender(a)need-hits.com>, size=0, class=0, pri=0, nrcpts=0, proto=ESMTP, relay=root(a)server3.homecom.com [204.198.149.6] Nov 4 04:07:16 bconnex.net sendmail[4804]: Ruleset check_mail (<tcsender(a)get-more-hits.com>) rejection: 451 <tcsender(a)get-more-hits.com>... Domain must resolve Nov 4 04:07:16 bconnex.net sendmail[4804]: EAA04804: from=<tcsender(a)get-more-hits.com>, e=0, class=0, pri=0, nrcpts=0, proto=ESMTP, relay=metallus.ias.net [206.214.209.8] Nov 4 04:07:23 bconnex.net sendmail[4808]: Ruleset check_mail ) rejection: 451 <tcsender(a)get-more-hits.com>... Domain must resolve Nov 4 04:07:23 bconnex.net sendmail[4808]: EAA04808: from=<tcsender(a)get-more-hits.com>, e=0, class=0, pri=0, nrcpts=0, proto=ESMTP, relay=france-travel.com [192.41.4.181] Nov 4 04:08:04 bconnex.net sendmail[4852]: Ruleset check_mail ) rejection: 451 <tcsender(a)get-more-hits.com>... Domain must resolve Nov 4 04:08:04 bconnex.net sendmail[4852]: EAA04852: from=<tcsender(a)get-more-hits.com>, e=0, class=0, pri=0, nrcpts=0, proto=SMTP, relay=fox.plaza.nl [195.108.180.1] Nov 4 04:08:05 bconnex.net sendmail[4858]: Ruleset check_mail ) rejection: 451 <tcsender(a)get-more-hits.com>... Domain must resolve Nov 4 04:08:05 bconnex.net sendmail[4858]: EAA04858: from=<tcsender(a)get-more-hits.com>, e=0, class=0, pri=0, nrcpts=0, proto=ESMTP, relay=dnai.com [140.174.162.28] Nov 4 04:08:17 bconnex.net sendmail[4865]: Ruleset check_mail (<tcsender(a)need-hits.com>) jection: 451 <tcsender(a)need-hits.com>... Domain must resolve Nov 4 04:08:17 bconnex.net sendmail[4865]: EAA04865: from=<tcsender(a)need-hits.com>, class=0, pri=0, nrcpts=0, proto=ESMTP, relay=virtual.icanect.net [208.202.14.126] Nov 4 04:08:45 bconnex.net sendmail[4881]: Ruleset check_mail ) rejection: 451 <tcsender(a)get-more-hits.com>... Domain must resolve Nov 4 04:08:45 bconnex.net sendmail[4881]: EAA04881: from=<tcsender(a)get-more-hits.com>, e=0, class=0, pri=0, nrcpts=0, proto=SMTP, relay=100t.lauderdale.net [207.141.140.10] Nov 4 04:09:09 bconnex.net sendmail[4895]: Ruleset check_mail ) rejection: 451 <tcsender(a)get-more-hits.com>... Domain must resolve Nov 4 04:09:09 bconnex.net sendmail[4895]: EAA04895: from=<tcsender(a)get-more-hits.com>, e=0, class=0, pri=0, nrcpts=0, proto=ESMTP, relay=fred.ic2do.com [38.218.186.11] Nov 4 04:09:14 bconnex.net sendmail[4902]: Ruleset check_mail (<tcsender(a)need-hits.com>) jection: 451 <tcsender(a)need-hits.com>... Domain must resolve Nov 4 04:09:14 bconnex.net sendmail[4902]: EAA04902: from=<tcsender(a)need-hits.com>, class=0, pri=0, nrcpts=0, proto=ESMTP, relay=ch.promega.com [198.150.28.10] Nov 4 04:09:15 bconnex.net sendmail[4905]: Ruleset check_mail (<tcsender(a)need-hits.com>) jection: 451 <tcsender(a)need-hits.com>... Domain must resolve Nov 4 04:09:15 bconnex.net sendmail[4905]: EAA04905: from=<tcsender(a)need-hits.com>, class=0, pri=0, nrcpts=0, proto=ESMTP, relay=root(a)ns.falconsoft.com [206.112.39.112] Nov 4 04:09:28 bconnex.net sendmail[4916]: Ruleset check_mail ) rejection: 451 <tcsender(a)get-more-hits.com>... Domain must resolve Nov 4 04:09:28 bconnex.net sendmail[4916]: EAA04916: from=<tcsender(a)get-more-hits.com>, e=0, class=0, pri=0, nrcpts=0, proto=ESMTP, relay=root(a)web12.ntx.net [209.1.144.158] Nov 4 04:09:45 bconnex.net sendmail[4928]: Ruleset check_mail ) rejection: 451 <tcsender(a)get-more-hits.com>... Domain must resolve Nov 4 04:09:45 bconnex.net sendmail[4928]: EAA04928: from=<tcsender(a)get-more-hits.com>, e=0, class=0, pri=0, nrcpts=0, proto=ESMTP, relay=root(a)realbeer.com [204.152.97.15] Nov 4 04:09:45 bconnex.net sendmail[4929]: Ruleset check_mail ) rejection: 451 <tcsender(a)get-more-hits.com>... Domain must resolve Nov 4 04:09:45 bconnex.net sendmail[4929]: EAA04929: from=<tcsender(a)get-more-hits.com>, e=0, class=0, pri=0, nrcpts=0, proto=ESMTP, relay=gost3.indirect.com [165.247.198.3] Nov 4 04:09:46 bconnex.net sendmail[4930]: Ruleset check_mail ) rejection: 451 <tcsender(a)get-more-hits.com>... Domain must resolve Nov 4 04:09:46 bconnex.net sendmail[4930]: EAA04930: from=<tcsender(a)get-more-hits.com>, e=0, class=0, pri=0, nrcpts=0, proto=ESMTP, relay=[205.217.137.150] Nov 4 04:09:54 bconnex.net sendmail[4936]: Ruleset check_mail (<tcsender(a)need-hits.com>) jection: 451 <tcsender(a)need-hits.com>... Domain must resolve Nov 4 04:09:54 bconnex.net sendmail[4936]: EAA04936: from=<tcsender(a)need-hits.com>, class=0, pri=0, nrcpts=0, proto=ESMTP, relay=root(a)jab1.roc.servtech.com [204.181.4.152] Nov 4 04:10:31 bconnex.net sendmail[4956]: Ruleset check_mail (<tcsender(a)need-hits.com>) jection: 451 <tcsender(a)need-hits.com>... Domain must resolve Nov 4 04:10:31 bconnex.net sendmail[4956]: EAA04956: from=<tcsender(a)need-hits.com>, class=0, pri=0, nrcpts=0, proto=ESMTP, relay=wcc.wcc.net [208.6.232.10] Nov 4 04:10:45 bconnex.net sendmail[4972]: Ruleset check_mail ) rejection: 451 <tcsender(a)get-more-hits.com>... Domain must resolve Nov 4 04:10:45 bconnex.net sendmail[4972]: EAA04972: from=<tcsender(a)get-more-hits.com>, e=0, class=0, pri=0, nrcpts=0, proto=ESMTP, relay=root(a)vp2.netgate.net [204.145.147.60] Nov 4 04:10:48 bconnex.net sendmail[4974]: Ruleset check_mail ) rejection: 451 <tcsender(a)get-more-hits.com>... Domain must resolve Nov 4 04:10:48 bconnex.net sendmail[4974]: EAA04974: from=<tcsender(a)get-more-hits.com>, e=0, class=0, pri=0, nrcpts=0, proto=ESMTP, relay=root(a)kitchen.virtual-cafe.com 3] Nov 4 04:10:58 bconnex.net sendmail[4980]: Ruleset check_mail ) rejection: 451 <tcsender(a)get-more-hits.com>... Domain must resolve Nov 4 04:10:58 bconnex.net sendmail[4980]: EAA04980: from=<tcsender(a)get-more-hits.com>, e=0, class=0, pri=0, nrcpts=0, proto=ESMTP, relay=[151.196.85.2] Nov 4 04:11:04 bconnex.net sendmail[4985]: Ruleset check_mail ) rejection: 451 <tcsender(a)get-more-hits.com>... Domain must resolve Nov 4 04:11:04 bconnex.net sendmail[4985]: EAA04985: from=<tcsender(a)get-more-hits.com>, e=0, class=0, pri=0, nrcpts=0, proto=SMTP, relay=www.fixation.com [206.144.185.101] Nov 4 04:11:06 bconnex.net sendmail[4991]: Ruleset check_mail (<tcsender(a)need-hits.com>) jection: 451 <tcsender(a)need-hits.com>... Domain must resolve Nov 4 04:11:06 bconnex.net sendmail[4991]: EAA04991: from=<tcsender(a)need-hits.com>, class=0, pri=0, nrcpts=0, proto=SMTP, relay=ns2.kalamazoo.net [206.31.33.2] Nov 4 04:11:26 bconnex.net sendmail[5016]: Ruleset check_mail ) rejection: 451 <tcsender(a)get-more-hits.com>... Domain must resolve Nov 4 04:11:26 bconnex.net sendmail[5016]: EAA05016: from=<tcsender(a)get-more-hits.com>, e=0, class=0, pri=0, nrcpts=0, proto=SMTP, relay=fox.plaza.nl [195.108.180.1] Nov 4 04:12:07 bconnex.net sendmail[5042]: Ruleset check_mail ) rejection: 451 <tcsender(a)get-more-hits.com>... Domain must resolve Nov 4 04:12:07 bconnex.net sendmail[5042]: EAA05042: from=<tcsender(a)get-more-hits.com>, e=0, class=0, pri=0, nrcpts=0, proto=ESMTP, relay=[151.196.88.4] Nov 4 04:12:08 bconnex.net sendmail[5043]: Ruleset check_mail ) rejection: 451 <tcsender(a)get-more-hits.com>... Domain must resolve Nov 4 04:12:08 bconnex.net sendmail[5043]: EAA05043: from=<tcsender(a)get-more-hits.com>, e=0, class=0, pri=0, nrcpts=0, proto=SMTP, relay=yakko.x-statik.com [198.68.248.2] Nov 4 04:12:13 bconnex.net sendmail[5046]: Ruleset check_mail (<tcsender(a)need-hits.com>) jection: 451 <tcsender(a)need-hits.com>... Domain must resolve Nov 4 04:12:13 bconnex.net sendmail[5046]: EAA05046: from=<tcsender(a)need-hits.com>, class=0, pri=0, nrcpts=0, proto=ESMTP, relay=root(a)[140.174.206.23]

5 4