RE: Computer systems blamed for feeble hurricane response?
http://www.fema.gov/staff/extended.jsp
Lists an "IT Services Division" that has ~250 possible points of contact.
Surely one of them has some clue... :-/ I think this sort of problem shows the endemic disease currently in place at FEMA. It's not just an "IT gaffe" or firewall mistake. It's a failure much more serious, sadly.
ObOp: Email is NOT a reliable form of communication. DHS shouldn't start to think so either. NANOG shouldn't worry about if someones email is working as a byproduct, but sure worry if the store and forward function of an ISP is. ' Anything below that is the individual SP's problem, IMO. Perhaps there are reasons some corporate or volunteer mail service is not working i.e. blocked, disallowed on port, etc. ObNotOp: Anyone who needs to contact FEMA, already knows how. If they are using a web page address, they probably shouldn't be contacting FEMA directly, but working through their own government hierarchy.
On Sep 13, 2005, at 11:13 AM, Hannigan, Martin wrote:
ObOp: Email is NOT a reliable form of communication.
^^^ unrelated and I disagree...
DHS shouldn't start to think so either. NANOG shouldn't worry about if someones email is working as a byproduct, but sure worry if the store and forward function of an ISP is. '
^^^ There exist networks and operators who do not run ISPs. People often forget.
Perhaps there are reasons some corporate or volunteer mail service is not working i.e. blocked, disallowed on port, etc.
^^^ I'm sure there is a reason. My first guess is that it's broken. My second is that it was never intended to be a domain used for email and the website techs never got the memo.
ObNotOp:
Anyone who needs to contact FEMA, already knows how. If they are using a web page address, they probably shouldn't be contacting FEMA directly, but working through their own government hierarchy.
In dealing with incidents it is possible to cover many areas of failure. There are many cases where the chain of command, the hierarchy process and many other elements fail. In those times, sometimes getting to a website and finding a contact address serve as a real means of communication and should be regarded as such. History proves the point that out of band comms and other forms of handling are often used during an emergency that were not expected. Right now if I go to http://www.fema.gov and click on "How to get help" and then "Contact us" I get a 404 forbidden. That's a failure. It's narrow-sighted to underestimate the importance of things like FEMAs website in dealing with national disaster and incident response. -david
On Tue, Sep 13, 2005 at 07:23:33AM -0700, william(at)elan.net wrote: ...
Which indeed means they have no MX servers listed and that MAY be a problem for some mail servers (though normally mail servers are supposed to send email based on A record then).
Obviously not having MX record is not considered to be good email service setup in this century and it also means if they receive too many messages and their mail server can not handle all the connections, the mail will bounce (since there is no secondary mail server to go to). ...
Wrong ... On Tue, Sep 13, 2005 at 09:36:39AM -0500, Larry Smith wrote: ...
Actually it is worse than that. fema.gov has an IP (205.128.1.44) which does not respond for mail so most MTA will try the IP first, meaning that most mail will fail even is ns.fema.gov or ns2.fema.gov do answer for mail. ...
Wrong ... in detail, anyway ... On Tue, Sep 13, 2005 at 10:39:21AM -0400, Christian Kuhtz wrote: ...
Uh, which mainstream mail server out there is ignorant enough not to send to A record? ...
None, one may hope, although MS keeps amazing me ... On Tue, Sep 13, 2005 at 10:44:56AM -0400, Mike Tancsa wrote: ...
SOA said root.ns2.fema.gov. It might be someone actually read's roots mail ? ...
This [deliberate human intervention] is the ONLY WAY that mail might be delivered to ns2.fema.gov ... On Tue, Sep 13, 2005 at 08:06:57AM -0700, william(at)elan.net wrote: ...
So having no MX server is really not such a good idea nowdays...
Obviously FEMA's problems are a lot worth since ip address 205.128.1.44 is behind firewall and does not accept port 25 connections. ...
*sigh* On Tue, Sep 13, 2005 at 11:51:27AM -0700, David Ulevitch wrote: ... I want to comment that Dave's observations about backup reliable comms opportunities seemed quite right. If "the people who should" don't, there should be some backup way for others with not quite the right "in" to get through. Mostly, I would like to invite all of the above to read RFC 2821, which has specific comments on all of the above. Any alleged mail server that dosn't conform to RFC 2821 isn't doing its job. If there are MX records, the server must try all IP addresses (from A records) of all hosts listed in the MX records. If there are no MX records, the server must try all IP addresses associated with A records of that domain. If there are no MX records and no A records, no delivery may be attempted. NS records do NOT name candidates for mail delivery. If one of the mail servers responds, and indicates a permanent failure, then a failure response gets delivered right away. Otherwise, if the delivery does not succeed right away, the message must be stored and attempts made at reasonable intervals for a reasonable amount of time. No distinction is made between addresses from MX record hosts or from A records. There is no requirement - even in this century - for MX records. It is a Good Idea(tm). But not a requirement. Lack of MX records does NOT mean that you lose the store-and-forward capability of SMTP. Lack of a secondary server, while equally not a Good Idea(tm), does NOT mean that you lose the store-and-forward capability, only that you exercise it more often. I know that there are books somewhere that expound in more literary language on the concepts in RFC2821. But this is the source. Please read it and refer to it during any discussion of e-mail service. Thanks. Oh, and also ... please consider that some firewalls try to discern whether the connection on port 25 is from a mail server or from Telnet. While I mourn the simplicity of manual debugging of such sites, it remains that: the fact that you can't TELNET HOST.DOMAIN 25 doesn't mean that there's no mail service there. (It could also be temporarily down.) -- Joe Yao ----------------------------------------------------------------------- This message is not an official statement of OSIS Center policies.
At 03:50 PM 13/09/2005, Joseph S D Yao wrote:
Oh, and also ... please consider that some firewalls try to discern whether the connection on port 25 is from a mail server or from Telnet. While I mourn the simplicity of manual debugging of such sites, it remains that: the fact that you can't TELNET HOST.DOMAIN 25 doesn't mean that there's no mail service there.
Making a network connection using the application "telnet" vs the application "sendmail" (or whatever MTA one uses) seems to be the same when doing a tcpdump on the data. I am not sure how a firewall would know -- purely at the network layer -- what the other side's application was/is that initiated the connection. Yes, the other end could try and connect back to the host, but there is no 2 way traffic as the 3way handshake is not completing and I dont see any other traffic coming back from that host attempting to discern any info. ---Mike
On Tue, Sep 13, 2005 at 04:15:29PM -0400, Mike Tancsa wrote:
At 03:50 PM 13/09/2005, Joseph S D Yao wrote:
Oh, and also ... please consider that some firewalls try to discern whether the connection on port 25 is from a mail server or from Telnet. While I mourn the simplicity of manual debugging of such sites, it remains that: the fact that you can't TELNET HOST.DOMAIN 25 doesn't mean that there's no mail service there.
Making a network connection using the application "telnet" vs the application "sendmail" (or whatever MTA one uses) seems to be the same when doing a tcpdump on the data. I am not sure how a firewall would know -- purely at the network layer -- what the other side's application was/is that initiated the connection. Yes, the other end could try and connect back to the host, but there is no 2 way traffic as the 3way handshake is not completing and I dont see any other traffic coming back from that host attempting to discern any info.
I don't know, myself. I said they try. Perhaps they succeed. Perhaps they check the speed of incoming queries. Perhaps they try to use a Telnet OPTION. I don't know. Perhaps it's a sales gag. [I think it was a telnet OPTION, actually.] -- Joe Yao ----------------------------------------------------------------------- This message is not an official statement of OSIS Center policies.
In message <20050913202040.GK16110@core.center.osis.gov>, Joseph S D Yao writes :
On Tue, Sep 13, 2005 at 04:15:29PM -0400, Mike Tancsa wrote:
At 03:50 PM 13/09/2005, Joseph S D Yao wrote:
Oh, and also ... please consider that some firewalls try to discern whether the connection on port 25 is from a mail server or from Telnet. While I mourn the simplicity of manual debugging of such sites, it remains that: the fact that you can't TELNET HOST.DOMAIN 25 doesn't mean that there's no mail service there.
Making a network connection using the application "telnet" vs the application "sendmail" (or whatever MTA one uses) seems to be the same when doing a tcpdump on the data. I am not sure how a firewall would know -- purely at the network layer -- what the other side's application was/is that initiated the connection. Yes, the other end could try and connect back to the host, but there is no 2 way traffic as the 3way handshake is not completing and I dont see any other traffic coming back from that host attempting to discern any info.
I don't know, myself. I said they try. Perhaps they succeed. Perhaps they check the speed of incoming queries. Perhaps they try to use a Telnet OPTION. I don't know. Perhaps it's a sales gag. [I think it was a telnet OPTION, actually.]
Telnet options, and for that matter speed, happen after the 3-way handshake. We're not getting that far. --Steven M. Bellovin, http://www.cs.columbia.edu/~smb
On Tue, Sep 13, 2005 at 04:28:41PM -0400, Steven M. Bellovin wrote: ...
Telnet options, and for that matter speed, happen after the 3-way handshake. We're not getting that far.
--Steven M. Bellovin, http://www.cs.columbia.edu/~smb
Steve, I defer to your expertise, as always. ;-] -- Joe Yao ----------------------------------------------------------------------- This message is not an official statement of OSIS Center policies.
On Tue, Sep 13, 2005 at 04:56:58PM -0400, Joseph S D Yao wrote:
On Tue, Sep 13, 2005 at 04:28:41PM -0400, Steven M. Bellovin wrote: ...
Telnet options, and for that matter speed, happen after the 3-way handshake. We're not getting that far.
--Steven M. Bellovin, http://www.cs.columbia.edu/~smb
Steve, I defer to your expertise, as always. ;-]
Nevertheless ... I went looking for comments on how this was being done, and found the following specualtion by a small number of different people. "SEF [is] unique in that it can detect what appear to be telnet connections to Port 25 and drop the connection. This is probably because telnet connections send one character at a time whereas real SMTP clients send all the strings at once." This would not require the 3WH, ISTM. -- Joe Yao ----------------------------------------------------------------------- This message is not an official statement of OSIS Center policies.
OBTW, this discussion of how SEF tells the difference between SMTP and telnet is rather beside the point. Most of what I wrote was, read RFC 2821. It's a little different from the RFC 821 that some of us have always cited, but I believe the points I noted are the same. AND it's a bit more OT, I suspect. ;-> -- Joe Yao ----------------------------------------------------------------------- This message is not an official statement of OSIS Center policies.
In message <20050913212312.GM16110@core.center.osis.gov>, Joseph S D Yao writes :
On Tue, Sep 13, 2005 at 04:56:58PM -0400, Joseph S D Yao wrote:
On Tue, Sep 13, 2005 at 04:28:41PM -0400, Steven M. Bellovin wrote: ...
Telnet options, and for that matter speed, happen after the 3-way handshake. We're not getting that far.
--Steven M. Bellovin, http://www.cs.columbia.edu/~smb
Steve, I defer to your expertise, as always. ;-]
Nevertheless ... I went looking for comments on how this was being done, and found the following specualtion by a small number of different people.
"SEF [is] unique in that it can detect what appear to be telnet connections to Port 25 and drop the connection. This is probably because telnet connections send one character at a time whereas real SMTP clients send all the strings at once."
This would not require the 3WH, ISTM.
Sure it would -- until the 3-way handshake, there's no application data flowing, and hence no characters being sent one at a time. We'll leave to another mailing list the question of what security benefit there is to such a feature... --Steven M. Bellovin, http://www.cs.columbia.edu/~smb
On Tue, Sep 13, 2005 at 05:54:03PM -0400, Steven M. Bellovin wrote:
In message <20050913212312.GM16110@core.center.osis.gov>, Joseph S D Yao writes :
On Tue, Sep 13, 2005 at 04:56:58PM -0400, Joseph S D Yao wrote:
On Tue, Sep 13, 2005 at 04:28:41PM -0400, Steven M. Bellovin wrote: ...
Telnet options, and for that matter speed, happen after the 3-way handshake. We're not getting that far.
--Steven M. Bellovin, http://www.cs.columbia.edu/~smb
Steve, I defer to your expertise, as always. ;-]
Nevertheless ... I went looking for comments on how this was being done, and found the following specualtion by a small number of different people.
"SEF [is] unique in that it can detect what appear to be telnet connections to Port 25 and drop the connection. This is probably because telnet connections send one character at a time whereas real SMTP clients send all the strings at once."
This would not require the 3WH, ISTM.
Sure it would -- until the 3-way handshake, there's no application data flowing, and hence no characters being sent one at a time.
Right. Doh. Me go home lie down rest.
We'll leave to another mailing list the question of what security benefit there is to such a feature...
;-) -- Joe Yao ----------------------------------------------------------------------- This message is not an official statement of OSIS Center policies.
On 9/13/2005 5:23 PM, Joseph S D Yao wrote:
"SEF [is] unique in that it can detect what appear to be telnet connections to Port 25 and drop the connection. This is probably because telnet connections send one character at a time whereas real SMTP clients send all the strings at once."
While we're beating a dead tangent, TELNET clients are often configurable to use line-mode (preferred for those of us with fat fingers, where we need backspace to work on the local line buffer before it is transmitted). Many of them will also avoid sending TELNET options when the non-default port is used (they've learned by now that there's little reason to do so, and lots of reasons not to). -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
For "contact us", I'm now getting a 403 error: Forbidden You don't have permission to access /feedback/ on this server. Apache/1.3.33 Server at www.fema.gov Port 80 -- William Allen Simpson Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32
On Tue, 13 Sep 2005 15:50:12 EDT, Joseph S D Yao said:
Oh, and also ... please consider that some firewalls try to discern whether the connection on port 25 is from a mail server or from Telnet.
OK, I'll bite. A long time ago, I saw code that would trap the fact that many telnet binaries would send option negotiation on ports other than 21. What are they keying off now? Since the host in question gave a 'Connection Refused', it obviously made its decision based on the initial SYN packet. So what are they looking at? TCP options? initial window? other? 16:25:37.240700 IP h80ad2467.async.vt.edu.43404 > listserv.vt.edu.smtp: S 1026334142:1026334142(0) win 5840 <mss 1460,sackOK,timestamp 3672334 0,nop,wscale 2> 16:25:57.420455 IP h80ad2467.async.vt.edu.45093 > listserv.vt.edu.smtp: S 1074086420:1074086420(0) win 5840 <mss 1460,sackOK,timestamp 3677379 0,nop,wscale 2> One was a telnet connection, one was Sendmail. Damned if I can tell.. ;) Of course, a busticated firewall trying to tell the difference *would* explain why they aren't accepting mail. :)
On Tue, 13 Sep 2005, Joseph S D Yao wrote:
There is no requirement - even in this century - for MX records. It is a Good Idea(tm). But not a requirement. Lack of MX records does NOT mean that you lose the store-and-forward capability of SMTP. Lack of a secondary server, while equally not a Good Idea(tm), does NOT mean that you lose the store-and-forward capability, only that you exercise it more often.
I don't disagree but it so happens not all mail software is fully RFC2821 compliant - that maybe either by choice or by ignorance of the authors or simply not reading RFC closely enough. If you ever wonder how bad it is - try looking at your Received header lines and compare to what RFC2821 says about them. So yes, I'll say it again - there are mail servers that don't respond appropriately when there is no MX record. Besides what RFC2821 says, it is also well-known that use of 'A' if there is no 'MX' is feature to support legacy [pre-1990] systems/domains and for individual hosts that don't usually used to receive email (but still have working postmaster address, etc). And every recent manual, book, etc for mail server software says that when setting up *domain* to receive email MX record must be setup.
Oh, and also ... please consider that some firewalls try to discern whether the connection on port 25 is from a mail server or from Telnet.
Could you elaborate on how firewall will determine if the connection is from mail server or from telnet on port 25? They both will have the same destination TCP port, both will use random source TCP port number, etc. I really don't see how L4 device (like most firewalls are) can do this unless they keep list of known mail servers ip addresses - and with millions of them I don't think anyone is crazy enough to compile that into their firewall. -- William Leibzon Elan Networks william@elan.net
william(at)elan> Could you elaborate on how firewall will william(at)elan> determine if the connection is from mail server william(at)elan> or from telnet on port 25? Perhaps because most telnet clients will attempt telnet option negotiation? If so one could avoid this by using a client such as netcat... -roy
On Wed, 14 Sep 2005, Roy Badami wrote:
william(at)elan> Could you elaborate on how firewall will william(at)elan> determine if the connection is from mail server william(at)elan> or from telnet on port 25?
Perhaps because most telnet clients will attempt telnet option negotiation? If so one could avoid this by using a client such as netcat...
Telnet option negotiation is at Layer 7 after TCP connection has been established. Firewalls typically don't operate at this level (TCP session is Layer 4 if I remember right) and would refuse or reject (difference type of ICMP response) based solely on attempt to connect to certain ip or certain TCP/UDP port. -- William Leibzon Elan Networks william@elan.net
On Tue, Sep 13, 2005 at 04:31:05PM -0700, william(at)elan.net wrote:
Telnet option negotiation is at Layer 7 after TCP connection has been established. Firewalls typically don't operate at this level (TCP session is Layer 4 if I remember right) and would refuse or reject (difference type of ICMP response) based solely on attempt to connect to certain ip or certain TCP/UDP port.
Application layer firewalls have existed for at least 6 years. --Adam
Adam McKenna wrote:
On Tue, Sep 13, 2005 at 04:31:05PM -0700, william(at)elan.net wrote:
Telnet option negotiation is at Layer 7 after TCP connection has been established. Firewalls typically don't operate at this level (TCP session is Layer 4 if I remember right) and would refuse or reject (difference type of ICMP response) based solely on attempt to connect to certain ip or certain TCP/UDP port.
Application layer firewalls have existed for at least 6 years.
AAAAAAAAAAAGGGGGGGGGGHHHHHH! But the point is that you would still establish a TCP connection before a MTA, firewall, IPS, or whatever could know it was telnet! The FEMA address that started this whole thing was timing out. You can tell the difference between a telnet filter and something completely, silently blocking 25/tcp. CAN THIS DIE NOW? Pulllleeeeeese... -- Crist J. Clark crist.clark@globalstar.com Globalstar Communications (408) 933-4387
In message <20050913235950.GA16550@flounder.net>, Adam McKenna writes:
On Tue, Sep 13, 2005 at 04:31:05PM -0700, william(at)elan.net wrote:
Telnet option negotiation is at Layer 7 after TCP connection has been established. Firewalls typically don't operate at this level (TCP session is Layer 4 if I remember right) and would refuse or reject (difference type of ICMP response) based solely on attempt to connect to certain ip or certain TCP/UDP port.
Application layer firewalls have existed for at least 6 years.
Make that 15.... --Steven M. Bellovin, http://www.cs.columbia.edu/~smb
Application layer firewalls have existed for at least 6 years.
Make that 15....
I suspect that claiming to that they existed farther back than 1990 would require careful debate about the functionality. Taking it at its most general: a boundary barrier service that mediated particular application exchanges between an "interior" Administrative Environment, versus the rest of the public network. One can reasonably argue than any such mediation has a security component to it. Therefore one could argue that firewall functionality was around at least 25 years ago -- there were a number of email boundary gateway mediating services by then -- and very probably back to 1973. (I just know that some MIT type is going to claim pre-1970, given the generality of the definition I offered.) d/ -- Dave Crocker Brandenburg InternetWorking +1.408.246.8253 dcrocker a t ... WE'VE MOVED to: www.bbiw.net
On Tue, Sep 13, 2005 at 11:09:54PM -0700, Dave Crocker wrote:
Application layer firewalls have existed for at least 6 years.
Make that 15....
I suspect that claiming to that they existed farther back than 1990 would require careful debate about the functionality.
Taking it at its most general: a boundary barrier service that mediated particular application exchanges between an "interior" Administrative Environment, versus the rest of the public network. One can reasonably argue than any such mediation has a security component to it.
Therefore one could argue that firewall functionality was around at least 25 years ago -- there were a number of email boundary gateway mediating services by then -- and very probably back to 1973. (I just know that some MIT type is going to claim pre-1970, given the generality of the definition I offered.)
Dave, I think the mail gateways back when the various networks were being put together into an internet had as their functional purpose unifying disparate networks. On the contrary, a firewall has as its purpose partitioning a network that otherwise would not have been. I don't think one will hear from MIT, given that. But Steve and Ches and Dave Presotto at Bell, and Brian Reid and others at DEC, were doing the partitioning thing in the late 1980's and 1990. Right? -- Joe Yao ----------------------------------------------------------------------- This message is not an official statement of OSIS Center policies.
Joseph S D Yao <jsdy@center.osis.gov> writes:
Dave,
I think the mail gateways back when the various networks were being put together into an internet had as their functional purpose unifying disparate networks. On the contrary, a firewall has as its purpose partitioning a network that otherwise would not have been.
When ARPA and MILNET were segmented in 1984, there were (Fuzzball-based IIRC) mail gateways between the two networks. The intended purpose of these devices was to restrict inter-network traffic to only email between two networks that were formerly one, so they're best looked at as a policy enforcement tool rather than a unifier the same way that, say, WISCVM.BITNET or ...!uunet!... was. It's not clear to me whether they were simply packet filters or actual application level gateways (given the capabilities of the fuzzball, my inclination is to think the former, but it's still worth taking note of). Besides, I was in high school at the time; it's not as if I had anything to do with the actual implementation. Those of a historical mind are encouraged to read Request For Kludges 821 - SMTP Polymorph Command: http://www.ibiblio.org/pub/docs/humor/fionavar/rfk_821 You may also find this interesting (particularly "On the Undesirability of 'Mail Bridges' as a Security Measure" by the late Mike Muuss); "walled garden" complaints and griping about gratuitously hosing the end-to-end model far predate the last decade and the lossage imparted by NAT: http://www.scatteredsheep.com/darpa-arpa-internet.htm
I don't think one will hear from MIT, given that.
As much time as I've spent hanging out at MIT over the years, I don't count. ;-) ---Rob
On Wed, Sep 14, 2005 at 08:26:54PM -0400, Robert E.Seastrom wrote: ...
When ARPA and MILNET were segmented in 1984, there were (Fuzzball-based IIRC) mail gateways between the two networks. ...
I hadn't thought back to that. From what I remember of the intent, and the little I knew about the intended design, they would qualify. But ... did the full intended partitioning ever happen? That I don't remember, I was working on a kind of isolated network at the time. ;-) -- Joe Yao ----------------------------------------------------------------------- This message is not an official statement of OSIS Center policies.
In message <20050914232747.GD23815@core.center.osis.gov>, Joseph S D Yao writes :
On Tue, Sep 13, 2005 at 11:09:54PM -0700, Dave Crocker wrote:
I think the mail gateways back when the various networks were being put together into an internet had as their functional purpose unifying disparate networks. On the contrary, a firewall has as its purpose partitioning a network that otherwise would not have been. I don't think one will hear from MIT, given that.
But Steve and Ches and Dave Presotto at Bell, and Brian Reid and others at DEC, were doing the partitioning thing in the late 1980's and 1990. Right?
Right, but Seastrom is correct. If you read the old TCP/IP Transition Handbook, you'll see that it talks about shutting off connectivity to MILNET and running mailbridges instead. What's unclear to me is how much of that was every built, but the intent was quite clear. I regard that as the first TCP/IP application firewall, vintage around 1981. --Steven M. Bellovin, http://www.cs.columbia.edu/~smb
On Tue, Sep 13, 2005 at 04:31:05PM -0700, william(at)elan.net wrote:
On Wed, 14 Sep 2005, Roy Badami wrote:
william(at)elan> Could you elaborate on how firewall will william(at)elan> determine if the connection is from mail server william(at)elan> or from telnet on port 25?
Perhaps because most telnet clients will attempt telnet option negotiation? If so one could avoid this by using a client such as netcat...
Telnet option negotiation is at Layer 7 after TCP connection has been established. Firewalls typically don't operate at this level (TCP session is Layer 4 if I remember right) and would refuse or reject (difference type of ICMP response) based solely on attempt to connect to certain ip or certain TCP/UDP port.
You're talking about the packet filters that marketeers sell as "firewalls". The best firewalls operate at the application layer. And, yes, that's an OPINION, no need to rave. -- Joe Yao ----------------------------------------------------------------------- This message is not an official statement of OSIS Center policies.
On Wed, 14 Sep 2005, Roy Badami wrote:
Perhaps because most telnet clients will attempt telnet option negotiation?
No they won't. I don't have any copies of BSD to hand from before 1987, but even then Berkeley Telnet would not do unsolicited option negotiation if you specified a port number. Tony. -- f.a.n.finch <dot@dotat.at> http://dotat.at/ BISCAY: WEST 5 OR 6 BECOMING VARIABLE 3 OR 4. SHOWERS AT FIRST. MODERATE OR GOOD.
participants (15)
-
Adam McKenna -
Crist Clark -
Dave Crocker -
David Ulevitch -
Eric A. Hall -
Hannigan, Martin -
Joseph S D Yao -
Mike Tancsa -
Robert E.Seastrom -
Roy Badami -
Steven M. Bellovin -
Tony Finch -
Valdis.Kletnieks＠vt.edu -
William Allen Simpson -
william(at)elan.net