Hi,
I received the following message:
>From: IN%"blu @
jericho .
mc .
com" 4-MAR-1994 12:28:33.70
>To: NITTMANN @
UWLAX .
EDU
>CC:
>Subj: Re: Interlock bug
>
>Received: from firewall.mc.com by vaxb.acs.uwlax.edu; Fri, 4 Mar 94 12:28 CDT
>Received: from jericho.mc.com by firewall.mc.com with SMTP id AA21237
> (5.65c/IDA-1.4.4 for <NITTMANN @
uwlax .
edu>);
> Fri, 4 Mar 1994 13:27:17 -0500
>Received: from darkstar by jericho.mc.com (4.1/1.34/indent-1.0 for mc.com)
> id AA14186; Fri, 4 Mar 94 13:27:16 EST
>Received: by darkstar (4.1//ident-1.0) id AA22237; Fri, 4 Mar 94 13:27:15 EST
>Message-Id: <9403041827 .
AA22237 @
darkstar>
>Date: Fri, 4 Mar 94 13:27:15 EST
>From: blu @
jericho .
mc .
com
>Subject: Re: Interlock bug
>To: NITTMANN @
UWLAX .
EDU
>
>My point is merely that noting a discrepancy between the RFC and a software
>product does not constitute suspicious behavior. The fact that the RFC
>requires what you consider to be a security problem does not mean that the
>person reporting the bug meant to use it in any fashion whatsoever. The mere
>fact that it is a bug makes it worth reporting.
>
>I understand that you meant that you were going to contact Mr. Davis' contact,
>not mine, but as say above, I question whether reporting a bug is just cause
>for attempting to contact the Internet contact. And my mention of privacy is
>in reference to you statement that you are going to request information on his
>activities.
>
>Mr. Davis states that he was not in possesion of the ANS contact info. In my
>experience, most people do not think of the tools to find addresses and phone
>numbers very easily.
>
>I am in full agreement with you about the RFC. Security can and should be
>built into protocols, but when it is not, simply citing the RFC does not
>make you a criminal.
>
>Brian Utterback blu @
mc .
com Manager Technical Networks
>Mercury Computer Systems, Inc. (508) 256-1300x168
>199 Riverneck Road (508) 256-3599 FAX
>Chelmsford, MA 01824 You can't grep dead trees.
>
>
I agree, and I apologize towards Mr. Davis for my too strong message from
this morning. My impression of inconsistency in the message was not well
founded: he might have debugged an error situation, not necessarily
telnetted into a mailer. It can well be that he is not familiar with
the internet tools to locate persons and organizations throughout the net.
Hope that this puts the flame out that I lit up.
Can we on this list get a consensus that the rfc821 method of preventing
error mailings as a reply to error mailings must be changed since the
empty from: string can be used in abusive situations?
Interlock is a firewall system, and I would say no firewall system should
support messages that have no verifiable originator, or non-identifiable
intermediate forwarding systems.
A reverse path can be tagged: put a $$ in front, or mark it otherwise so that
no error reply mail is created, neither to from: nor to reply-to: .
Benefit: no anonymous mails possible, no hidden remailers possible, and
telnet into a mailer must give a reverse path that can be resolved and
verified.
Mike
============================================================================
Michael Nittmann 608 787 3792
Principal Communications Analyst 608 787 2552 FAX
The Trane Company
3600 Pammel Creek Road, La Crosse, WI 54601 nittmann @
uwlax .
edu
----------------------------------------------------------------------------
|
|
