On 04/01/08 09:59, David F. Skoll wrote:
> I can understand perfectly why someone might *want* to hide that
> information. I can also understand perfectly that it's *stupid* to
> think that hiding the information actually makes you more secure.

I believe (my opinion) that each and every little thing that you do to
not expose information on top of all other security measures makes you a
little bit more secure by making you a harder target to hit. We are
both human and allowed to have different opinions. For now I think we
can both agree to disagree and move forward.

> Sorry; I misread your post.

I figured as much which is why I restated. There may be some stinky
opinions flying back and forth, but seeing as how there are no insults,
we can still discuss / debate / banter back and forth until one or the
other of us gets tired of this thread.

> Received: headers are the *standard* way. Some of us think standards
> actually matter.

I'll agree that Received: headers are the standard way to do it on the
open internet where SMTP is the standard protocol. However inside of
closed environments, where SMTP is optional, so is said method of
detecting loops.

> If you don't think breaking RFC: and mail-loop detection/prevention
> are good enough reasons... then fine; we are at an impasse.

I do not believe that removing Received: headers from outbound messages
at the SMTP edge of a network breaks mail-loop detection/prevention like
you are saying. However I am interested in having a discussion where
one or the other or both of us proposes our scenarios where things will
work and have the other poke holes in it if you are as well.

> I call bullshit.

If you have not altered or provided mis-information in your headers,
then I do indeed have some information about your set up. How useful
that information is can not be determined by its self. But I do still
have some purported information.

> That's right.

*nod*

> Ehm... not exactly.

Vanadium may not be an edge SMTP like I said, but I'm still sticking to
the fact that it appears that it has directly routable access to the
192.168.2.x network.

> Yep.

*nod*

> Yep.

*nod*

> Go ahead and try. shishi and vanadium both have private IP
> addresses, so if you pull that trick off, I will be most impressed.

Adding that tidbit of information I'm guessing that there is a NATing
firewall between Vanadium and the internet that I would have to get
through if I was to attack from the internet its self. However I do
have more information. Again the viability of the information is still
questionable.

> On a 192.168 address? Good luck. On the 64.26.171 address? That's
> a public IP address anyway that you could find pretty quickly with
> other means.

I can not directly attack your private range IP addresses. However I
could see how good your NATing firewall is. I wonder how much of a
reflected attack would get in. (Again, I'm just thinking out loud as I
will *NOT* do any of these things.)

> Mmm... yeah... go ahead and try. :-) Good luck...

I will do some more thinking about this and contact you off list if I am
more interested and you are willing to participate in a test (can I send
my someone a "Hello World" message or not).

> Once again, I call BS. The exploits you mentioned are completely
> infeasible.

Depending on what other forms of security you have in place, the things
I've mentioned may indeed be completely infeasible. How good is your
defense against social engineering? What about others in your house?
What would I gain if something was run from with in your network knowing
what you have exposed via your Received: headers and this news group?

To me, these are all crumbs along a long trail that can be used to
exploit someone. My simple opinion is that not leaving (exposing) these
crumbs (Received: headers) does indeed provide some (limited) additional
security by making you much harder to find and attempt to exploit.

> Regards

Thank you for taking the time to respond politely with decent though out
facts / opinions in a non insulting manner (unlike some other posters in
this group as of late).



Grant. . . .