[ntp:webdudes] Re: [ntp:hackers] Some NTP services to be terminated orrelocated at UDel

Brad Knowles brad.knowles at skynet.be
Sun Aug 24 15:45:49 PDT 2003


At 1:55 PM +0000 2003/08/21, David L. Mills wrote:

>  I don't buy it. Mike and I were concerned with only one thing, that some
>  folks could send to Udel mail but not to NTP mail.

	I've been sitting on this message for a while.  I wanted to make 
sure that I had thought out my response as much as I could.

>                                                      I understood the
>  configuration entry Mike mentioned was the culprit, nothing more,
>  nothing less.

	Mike identified the wrong feature.  Because I thought he had 
understood what we were talking about, I didn't catch that he had 
identified the wrong feature.

>                The UDel mail policy is established by the binaries now
>  extant plus the configuration files you see. That's the bottom line.

	That is not at all true.  Other machines are running anti-spam 
scanning software, and the other postfix configuration on maccarony 
does not do that.

	Clearly, the other postfix configuration is older, and is not an 
accurate representation of the current UDel EECIS policy, despite all 
claims to the contrary.


	There may very well be a postfix configuration somewhere that can 
be taken to be the canonical implementation of the UDell EECIS 
policy, but that configuration does not exist on maccarony.

	I've searched through the entire machine, and I'm pretty 
confident that there are only two postfix configurations anywhere on 
the system -- the ancient one I previously mentioned (which does not 
implement SpamAssassin, etc...), and the one that Harlan installed in 
April, and which I have been maintaining.

>                  Meanwhile, it is counterproductive to insist on an
>  explicit "mail policy" on the part of UDel hosts. These guys are working
>  stiffs and don't have a lot of time to craft agendae other than what
>  works.

	There's a forest/trees problem here.  When you get so far into 
fire-fighting mode, you tend to stop doing the very things that you 
need to do in order to properly dig yourself out of that hole.

>  On the other hand, what we might have here is a marvellous opportunity
>  to craft such a working policy that both UDel and NTP should follow. I
>  have to confess ignorance, as the only issue I was concerned with was
>  the accessibility one. What do you think we both should do relative to
>  the various options you see in the mail configuration issue? Are there
>  some options in the binary build procedure that we should talk about
>  other than what is in plain sight?

	At its simplest, a document like this only needs to discuss what 
features MUST and MUST NOT be present.  Assuming that our discussion 
on this topic has been relatively complete, we could boil this down 
to just two lines:

		1.  The machine MUST NOT be configured to refuse to accept a
			connection, simply on the basis of no correct reverse DNS
			in existence for the IP address of the transmitting machine.

		2.  The machine MUST NOT be configured to refuse to accept a
			message, simply on the basis of being unable to validate
			the host/domain portion of the envelope sender address.

	In actuality, you'd probably want to add a third line:

		3.  The machine MUST NOT act as a relay for IP addresses that
			are not within the UDel EECIS network (128.4.0.0/16).


	That's it.  That is all it really needs to say.  It simply 
wouldn't make mention of anything else, either way.



	However, if you like, you could add items describing features 
that SHOULD or SHOULD NOT be present:

		4.  Anti-spam scanning software SHOULD be installed on the
			machine.  The UDel EECIS standard software for doing this
			is SpamAssassin, in combination with Anomy (to disable
			certain types of potentially dangerous attachments or
			HTML code in e-mail).

	In this case, you may need to add additional items which describe 
further requirements:

			A.  If anti-spam scanning software is installed, it
				MUST NOT be configured to do any of the following
				things:

					* Blacklist incoming e-mail messages simply
						because they have headers including 8-bit
						characters

					* Blacklist incoming e-mail messages simply
						because they have some headers that are
						entirely in uppercase characters

			B.  If anti-spam scanning software is installed, it
				MUST be configured to do at least these following
				things:

					* Reduce the spam score for any mail message
						having passed through a campus machine
						(anything in udel.edu or 128.175.0.0/16)

					* Further reduce the spam score for any mail
						message having passed through a department
						machine (anything in eecis.udel.edu or
						128.4.0.0/16).

					* Increase the minimum required spam score by
						at least 20% from the built-in default (to
						reduce the probability of false positive
						matches).

			C.  If software to disable potentially dangerous types
				of attachments or HTML code in e-mail is installed,
				it MUST conform to the following requirements:

					...



	You could even go so far as to include additional items which 
describe features that MAY optionally be implemented, at the 
discretion of the postmaster/mail system administrator:

		5.  Anti-virus scanning tools MAY be implemented, at the
			discretion of the postmaster/mail system administrator.
			If such systems are implemented, they MUST meet the
			following requirements:

				...

		6.  Mailing list management software MAY be implemented.
			In such case, the following requirements MUST be met:

				...



	If you wanted to get really fancy, you could front-end all this 
with a section that tells the reader something along the lines of:

		All machines on the UDel EECIS network MUST implement the
		UDel EECIS policy, and that all machines on this network
		shall be administered by UDel EECIS personnel in accordance
		with this policy.

		All exceptions to this policy shall be approved solely at
		the discretion of UDel EECIS management.

		UDel EECIS management may choose to allow other personnel
		to administer machines on the UDel EECIS network.  These
		local administration staff members must agree to abide by
		all terms of this policy, in writing, before they can be
		given access to the machines, and they shall likewise
		require all future members of their staff to do likewise.

		Any violations of this policy shall be considered to be
		grounds for removal of access by that person to any UDel
		EECIS equipment, removal of that machine from the network
		until it can be secured and re-installed by UDel EECIS
		personnel, filing of complaints or lawsuits, notification
		of law enforcement officials, or other appropriate actions
		as determined by UDel EECIS management.




	The policy can be as simple or as fancy as you want to make it. 
However it is written, it should be in English, and as non-technical 
and as general as possible -- so that the policy can be easily 
understood and implemented correctly, and in a manner most 
appropriate to whatever software may be used.

-- 
Brad Knowles, <brad.knowles at skynet.be>

"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety."
     -Benjamin Franklin, Historical Review of Pennsylvania.

GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI++++$ P+>++ L+ !E-(---) W+++(--) N+
!w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++)
tv+(+++) b+(++++) DI+(++++) D+(++) G+(++++) e++>++++ h--- r---(+++)* z(+++)



More information about the hackers mailing list