Subject: [seamoby] Re: Spam idiots

From: Pat Calhoun <[email-masked]>
Date: Mon, 5 Mar 2001 07:40:53 -0800 (PST)

An investigation is underway as we type...

PatC
> 
> 
> 
> Hi Pat,
> 
> Did you complain to the domain admins?  They can  almost always find
> spammers originating from their domains since they leave all kinds
> of digital footprints.
> 
> regards,
> 
> Phil
> 
> 
> 
> 
> 
> Pat Calhoun <[email-masked]> on 03/04/2001 06:22:29 PM
> 
> Please respond to Pat Calhoun <[email-masked]>
> 
> Sent by:  Pat Calhoun <[email-masked]>
> 
> 
> To:   Pat Calhoun <[email-masked]>
> cc:   "Andrew T. Campbell" <[email-masked]>, "'Gary Kenward'"
>       <[email-masked]>, "'James Kempf'" <[email-masked]>,
> Phil
>       Neumiller/MW/US/3Com, [email-masked]
> Subject:  RE: [seamoby] Yet Another BOF?
> 
> 
> 
> All,
> 
> This is an old e-mail that was resent by someone at m018.com. Somehow, this
> site is resending old e-mail from both seamoby and mobileip lists. I have had
> to shutdown my list (as has mobileip), as we are being attacked quite
> viciously by this site. I do not know of a way to re-enable the site and not
> be attacked.
> 
> This morning I had over 1800 e-mails resent from this site to my box. I am
> getting quite annoyed.
> 
> In short, disregard these e-mails.
> 
> PatC
> > > >  However, as I have stated
> > > > numerous times,
> > > > statements like "MIP is too slow" just doesn't cut it.
> > >
> > > Lets try it this way then - please shoot me down.
> >
> > ok
> >
> > >
> > > We clearly believe that micro-mobility means not invoking
> > > the MIP HAs each time we handoff? So all the action must be local.
> > > That excludes vanilla MIP as a solution and under those
> > > conditions its slow and lossy, etc.
> > >
> > > So what is this local protocol? I would claim that trees,
> > > levels of FAs and tunneling (the base MIP class) are
> > > costly (tunnel/detunel overhead/complexity)
> > > and not robust (the tree of FAs, single gateways).
> > > I'm not digging here; just some unsubstantiated
> > > thoughts off the top of my head.
> > >
> > > The point that a number of people are making (and
> > > developing solutions for, e.g., CIP, Hawaii, etc.)
> > > is that if I'm forced to use FAs (trees and levels of them),
> > > tunneling and MIP signaling to solve every new
> > > wireless problem (e.g., QOS, fast handoff, etc.)
> > > that surfaces in IETF, then, how do we innovate
> > > and deliver new wireless IP technologies?
> >
> > Ahhh..... technical arguments. Good. This is all good. This is what we need.
> > They are alot harder to defend than the "MIP is too slow" argument.
> >
> > > Is this because people think that the investment in MIP
> > > is so great that must reap dividend at no end? sister of
> > > MIP, cousin of MIP, etc.
> >
> > Sure, and I do understand where they stand, but our charter is not to save
> > engineering work. It is to build what we need.
> >
> > > Coupling each development to the base MIP mechanisms
> > > (FAs, tunneling, MIP signaling) as a perquisite to
> > > the development of new wireless IP protocols is a
> > > little like driving a car with a straight-jacket on.
> > >
> > > Building fast/seamless handoff, paging, context,
> > > QOS, etc. etc., on MIP is where we are heading today;
> > > consensus or not; it looks to me its all engineered
> > > that way?
> >
> > well, I haven't seen paging, context nor QoS being built on top of MIP, but
> > perhaps I've missed something. Of course, I've seen individual contributions
> > that propose this, but this is hardly a WG's work item.
> >
> > >
> > > The goals should to let MIP be the macro-mobilty
> > > protocol to interwork with and allow
> > > new and innovative technologies with
> > > (for fast handoff, seamless, fast security,
> > > QOS, context, etc. etc.) to be created.
> >
> > Sounds reasonable to me.
> >
> > PatC
> 
> 
> 
> 
> 
>

---

From: [email-masked]
Date: Mon, 5 Mar 2001 09:42:35 -0600

Hi Pat,

regards,

Phil

      <[email-masked]>, "'James Kempf'" <[email-masked]>, Phil

All,

PatC

---

From: "T.J. Kniveton" <[email-masked]>
Date: Tue, 06 Mar 2001 19:24:52 -0800

> > In short, disregard these e-mails.

Wow, nasty problem. Maybe I don't fully understand it, but it sure seems like it
could be solved by upgrading your version of Sendmail to one that supports an
"access" database and spam controls.. Then, you can add an entry to your access
file, such as "naughtydomain.com REJECT" and rebuild the database. Works for me..
--
T.J. Kniveton