[mdlug] Here's my idea and rough sketch plan, is it feasible?

[Robert Adkins]

> -----Original Message-----
> From: mdlug-bounces at mdlug.org 
> [mailto:mdlug-bounces at mdlug.org] On Behalf Of Joseph C. Bender
> Sent: Wednesday, October 03, 2007 3:24 PM
> To: MDLUG's Main discussion list
> Subject: Re: [mdlug] Here's my idea and rough sketch plan, is 
> it feasible?

> 	I have doubts about it making it any more secure.  
> You're just adding a hop to the process.  Unless you're 
> sharing login session data from the portal page to the 
> webmail server, it would be fairly trivial to fake a HTTP 
> referrer in the request, if one wanted to take on the webmail 
> server directly.
> 

	Yes, it would be trivial to fake a referrer.

	Maybe I am incorrect in thinking this, I was under the impression
that the referrer could also include the full page of where the link came
from. If that's correct, then whoever would be faking the HTTP referrer
would first need to know that the server is only allowing referrals from
somewhere and then also need to know the full string of the referring page.
(Which I could change periodically.)

> 	The time would be better spent looking into a SSL VPN 
> device that allows for proxying/gatewaying into the 
> application, where it presents a far different set of session 
> variables to the end-user, and filters the requests heading 
> to the webserver.  They often include IDS/IPS functionality 
> to detect for vunerability attempts against the device.
> 

	Spending Zero dollars is more of what is expected than anything
else.

	Last year, I wanted to replace a server roughly 3 to 4 months before
the time I figured we would be on borrowed time with it. My request was
refused, the server died (The HD crashed roughly around the time I predicted
it would fail), practically all business activities ground to a halt and
still there was nitpicking costs on the replacement server.

	This isn't about running out and finding a perfect solution. This is
about necesity causing the "invention" of a cheap solution that is mostly
going to work.

> 
> 	Rove (nee Idokorro) Mobile SSH doesn't do port 
> forwarding.  Can't say about the free mobile SSH client 
> either (can't recall the name of it).
> 
> 	You'd also have the problem of making sure the device 
> would run both apps in a true multitasking mode as well.  
> Many phones make the background app sleep most of the time, 
> if not outright pausing it.
> 

	Thank you. I'll definitely need to find this out.

> > 
> 	If this is a corporate mandate, there needs to be a 
> corporate standard. 
>   Anything that's outside of the standard doesn't get supported. 
> Otherwise you'll run into phones that don't display the 
> webmail correctly, and it becomes much much more of a support 
> nightmare than you ever suspected.
> 

	I am very aware of this.

	Here's the scenario: 

	Our "standard" is to replace a computer when it fails or when the
boss or a key employee needs something with more power. If something with
more power is brought in, then the replaced PC is repurposed by removing and
installing the software needed for another job and is given to another
employee. (I try and replace the slowest machines with hand me downs if
possible.)

	This scenario extends to phones, with one caveat, if the boss
loses/breaks his phone or goes out and says "Oooh... shiny!" and comes back
with a new toy, I have to make that work. This happened when the Razr came
out and I had to run back out and pick up a new "Internet Connectivity Kit"
and resetup their laptops to use their new toy phones.

	I anticipate that this standard will continue for the forseeable
future. 

> 	Honestly, if they're going to do this, the Blackberry 
> Internet service and their push email system works 
> wonderfully.  Compatible with IMAP and POP3, including 
> syncronization with IMAP folders.  Managers love Blackberries.  *grin*
> 

	Blackberry phones might be nice.

	Are they compatible with "any" email server?

	-Rob