[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