Regarding the technical discussion you wanted to bring up:
I have learned that WIS operates number of mailing lists with hosting on several various machines.
using "list(at-nospam)weizmann.ac.il" address format.
Is it not possible to change the address of the list from
"linux-il(at-nospam)plasma-gate.weizmann.ac.il" to something like
"linux-il-archive(at-nospam)weizmann.ac.il"? And route messages intended to this address
to plasma-gate server?
Of course, it would be possible (albeit far from optimal, IMHO). Moreover, this was indeed the solution WICC suggested to me quite a while ago, and I accepted it (although, again, I believe that such a complication was completely unnecessary). However, on Thursday, I was told that the new decision is to block the SMTP traffic to plasma-gate completely.
So there is a striking difference between what I was told and your information. Did you get it after the last Thursday or before?
I believe that if that is done your Information Security peolple would have less(or none) objections to the existance and operation of the archive.
While we're at that, I'd like to ask you about one favor. Apparently, you managed to establish a _technical_ contact with the Information Security people - something which I've miserably failed for a very long time. So can you please ask them what was the reason to ban [EMAIL PROTECTED] addresses in the first place? Thanks in advance. The maximum info I could get myself was that this is the best solution given the WICC manpower is limited in number. I can't comprehend it, though, and here is some basic math:
0. The first (or zeroth) question, actually, is what was wrong with
direct SMTP access to plasma-gate. To the best of my knowledge, there
have been no security-related incidents with the server; and it's in the
Weizmann DMZ anyway. There are antispam and antivirus filters enabled.
Virus lists are updated automatically (and, for all I know, no antispam mechanisms exist at the main Weizmann gateway as of yet).
1. But let's assume the blocking of the direct SMTP access is justified somehow. Then, we come to a logical solution to have a central email gateway that will forward (after the necessary security checks) messages to the final destination. Of course, the reliability of such a system falls twofold, but hey, one knows that security has a price attached.
2. The forwarding can be implemented in a few ways. The one that seems to me the optimal would include two steps: a) define MX for plasma-gate in the DNS pointing to the central SMTP gateway and b) adding one entry to the mailrouting table of the gateway to forward all emails with the destination of [EMAIL PROTECTED] to plasma-gate.
Each of the two actions effectively means adding a single line to a relevant ASCII config file. Once done, this will work forever with no need for further maintenance. What's more, it will work transparently for all
users, requiring no actions whatsoever on their part. Let's now estimate
the WICC manpower needed to implement it. If we define X as the time
needed to type a single text line, the value we're looking for can be
expressed as
T = 2*X. (1)
Now we're in some genuine trouble, since X is unknown. Based on my own
experience, I'd estimate the upper bound as 1 (one) minute, allowing for some coffee breaks. But one never knows. However, as anybody does know, everything should be considered in comparison.
3. So let's see what the blessed by the WICC solution means (in the terms of manpower). They suggest that all email addresses will be replaced, as you correctly stated in above. The calculations are more complicated here. Let's define the number of user accounts @plasma-gate as NU. Further, each user may want to have several aliases. Full.Name@ is just obvious one, but other needs may exist. For example, I use a special alias when ordering, say, a commercial compiler from a company. Then, if at some time, I start getting spam at that address, I know exactly whom to sue for selling my private info without my explicit permission. So let's define (an average) number of aliases per user as NA. Further, it's a common practice nowadays to use email addresses of the form username+foldername@, often used to subscribe to some public forums. Then (if the underlying delivery agent supports it - and many decent ones do), such emails will be delivered right to the named folder instead of inbox. We'll use NF for these "folder aliases". In total, there are, therefore, NU*(1 + NA + NF) distinct email addresses to be dealt with. So far, all of these have demanded exactly 0 (zero, null, nothing) of the WICC manpower to support. But now, each of them (and the real target for each) will have to be defined at the central email gateway. In the simplest form, this is again a single textual line to be added to a relevant file. Therefore, we get
T = NU*(1 + NA + NF)*X. (2)
But this is only a tip of the iceberg. Each user has to remember all his email respondents for almost ten last years and send each of them a note that his email is going to change. Each of the respondents must alter his or her address book respectively (of course, this has nothing to do with the WIS manpower, but valuing the work time of our colleagues from other academic institutions as zero is unethical at the very least). As well, there are countless scientific papers that have been published during these years and which list contact emails of the form of [EMAIL PROTECTED] These are hardcopy items, available in thousands of libraries around the world, which can't be altered at all. An attempt of anybody from the world scientific community to request some clarification using the email addresses will simply fail. Further, in contrary to (1), the maintenance time implied by (2) is a never-ending story. Users come and leave, they add or remove their aliases, etc. Plus, the large lookup table at the gateway means its operation is less efficient.
But even forgetting all this underwater part of the issue, let's compare the two approaches. We'll calculate R, the ratio of the work time given by (2) and (1). What one gets is:
R = NU*(1 + NA + NF)/2. (3)
There are many parameters, but one doesn't need to have a Ph.D to easily say that the crossover point (i.e. when R exceeds 1, or, in other words, when the first method becomes preferable) is guaranteed to be reached for NU > 2. And you can be sure that in practice NU (number of users @plasma-gate) >> 2.
Regards,
Evgeny
================================================================= To unsubscribe, send mail to [EMAIL PROTECTED] with the word "unsubscribe" in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
