Re: mail service with no mx (was - Re: Computer systems blamed for feeble hurricane response?)
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.
Re: mail service with no mx (was - Re: Computer systems blamed for feeble hurricane response?)
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
Re: mail service with no mx (was - Re: Computer systems blamed for feeble hurricane response?)
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 [EMAIL PROTECTED] http://dotat.at/ BISCAY: WEST 5 OR 6 BECOMING VARIABLE 3 OR 4. SHOWERS AT FIRST. MODERATE OR GOOD.
Re: Computer systems blamed for feeble hurricane response?
On 9/14/05, Mike Tancsa [EMAIL PROTECTED] wrote: Port 587? Not everyone implements that. You would make a large part of the internet unreachable via email vinyl# telnet mx2.mail.yahoo.com 587 Trying 67.28.114.36... telnet: connect to address 67.28.114.36: Connection refused Trying 4.79.181.13... Wrong host. 587 / msa is for outbound email [EMAIL PROTECTED] 16:57:22 [~]$ telnet smtp.mail.yahoo.com 587 Trying 216.136.173.18... Connected to smtp.mail.yahoo.com (216.136.173.18). Escape character is '^]'. 220 smtp017.mail.yahoo.com ESMTP quit 221 smtp017.mail.yahoo.com Connection closed by foreign host. -- Suresh Ramasubramanian ([EMAIL PROTECTED])
Re: Computer systems blamed for feeble hurricane response?
does anyone else find it highly odd and worrisome that they're sending emails to alert FEMA of a crisis, instead of, I don't know - phone calls? if I'm a federal agency and I require FEMA's resources immediately, I'm going to pick up the phone and call them; not fire off an email marked urgent. Imagine the following email: I have just received a phone call from one of my constituents who was visiting friends in New Orleans. She is trapped along with 50 other people on the second floor of the Baptist Church at the corner of ABC Street and XYZ Avenue approximately a mile west of the Superdome. The nearest building with any part of it above water is the Odeon Theatre 3 blocks north of the church. They have had no water to drink for over 24 hours and they fear that some of the children and elderly are literally dying of thirst. Is there a fax number I can send this information to? What part of the above email message is it preferably to communicate by telephone instead of email? Many people choose the medium of communication based on whether or not they want a record of the information communicated. If they want the content kept secret, they use the phone. If they want the content recorded, they use email. In my hypothetical example, a politican from another state is trying to help a constituent. Naturally, being a politician, they prefer to have a record of the content. Also, the sender of the email recognizes that some of the information is important to have in written form, such as the address, distance, direction, number of blocks. Things like that can get wrongly transcribed on a voice call. This is a life or death situation so it can be argued that it is TOO IMPORTANT to risk a voice call. If only FEMA's email infrastructure was geared for emergencies... Or their web page. Or the web page of the American Red Cross. Fact is that a lot of organizations got caught with their pants down because they were not prepared to respond to an emergency and they were not prepared to use modern communications methods. Anyone who was searching for friends and relatives during the aftermath knows how chaotic it was to find information about the whereabouts of the refugees. This is a real wake-up call for all kinds of organizations, not just FEMA and not just government agencies. Could your diesel gensets cope with an extended running period like the one that DirectNIC has experienced? Do you have enough bottled water in your data center to keep critical staff ALIVE in the case of an extended emergency like this? Anyone who runs any type of critical infrastructure will have dozens of lessons to learn after analyzing the outcome of the New Orleans disaster, even moreso than the 911 commission or the Columbia accident inquiry. --Michael Dillon
Re: Computer systems blamed for feeble hurricane response?
At 07:28 AM 14/09/2005, Suresh Ramasubramanian wrote: On 9/14/05, Mike Tancsa [EMAIL PROTECTED] wrote: Port 587? Not everyone implements that. You would make a large part of the internet unreachable via email vinyl# telnet mx2.mail.yahoo.com 587 Trying 67.28.114.36... telnet: connect to address 67.28.114.36: Connection refused Trying 4.79.181.13... Wrong host. 587 / msa is for outbound email Sorry, my point was that you could not just assume the sending host was a mail server by connecting back to the host on the submission port as it might not be listening on that port or that because the host sending is not in the MX list, that its not a mail server. ---Mike
Re: mail service with no mx (was - Re: Computer systems blamed for feeble hurricane response?)
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.
Re: mail service with no mx (was - Re: Computer systems blamed for feeble hurricane response?)
Joseph S D Yao [EMAIL PROTECTED] 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
Re: mail service with no mx (was - Re: Computer systems blamed for feeble hurricane response?)
In message [EMAIL PROTECTED], 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
Computer systems blamed for feeble hurricane response?
This is the first I've heard of this... Via The Inquirer: [snip] REPORTERS at the Wall Street Journal said they have seen documents which show that a swift response by the US federal government to Hurricane Katrina was hampered because FEMA computer servers crashed. Michael Brown, FEMA's head, resigned yesterday after being recalled by the Department of Homeland Security to Washington DC. Attempts by agencies to spur the Federal Emergency Management Agency into urgent action were met with bouncing emails, the Journal said. It quoted a Department of Health official as saying every email it had sent to FEMA staff bounced. They need a better internet provider during disasters, the Journal quoted her or him as saying. A number of US agencies made desperate calls to the Department of Homeland Security and to Congresswomen and men, the article claimed. [Subscription required.] The newspaper did not say which computer systems FEMA uses. [snip] http://www.theinquirer.net/?article=26125 - ferg -- Fergie, a.k.a. Paul Ferguson Engineering Architecture for the Internet [EMAIL PROTECTED] or [EMAIL PROTECTED] ferg's tech blog: http://fergdawg.blogspot.com/
Re: Computer systems blamed for feeble hurricane response?
on Tue, Sep 13, 2005 at 01:13:19PM +, Fergie (Paul Ferguson) quoth: Attempts by agencies to spur the Federal Emergency Management Agency into urgent action were met with bouncing emails, the Journal said. It quoted a Department of Health official as saying every email it had sent to FEMA staff bounced. They need a better internet provider during disasters, the Journal quoted her or him as saying. Does anyone know what their mail infrastructure looks like? From what I can see, they don't even have an MX record for fema.gov... -- hesketh.com/inc. v: +1(919)834-2552 f: +1(919)834-2554 w: http://hesketh.com antispam news, solutions for sendmail, exim, postfix: http://enemieslist.com/
Re: Computer systems blamed for feeble hurricane response?
At 09:31 AM 13/09/2005, Steven Champeon wrote: Does anyone know what their mail infrastructure looks like? From what I can see, they don't even have an MX record for fema.gov... No MX record, and the A record for fema.gov does not accept smtp traffic. # telnet fema.gov smtp Trying 205.128.1.44... telnet: connect to address 205.128.1.44: Operation timed out telnet: Unable to connect to remote host # Then again, it might be that they use different email addresses ? @dhs.gov ? set type=soa fema.gov Server: ns.fema.gov Address: 166.112.200.142 fema.gov origin = ns.fema.gov mail addr = root.ns2.fema.gov serial = 2005090901 refresh = 10800 (3H) retry = 3600 (1H) expire = 604800 (1W) minimum ttl = 1800 (30M) fema.govnameserver = ns.fema.gov fema.govnameserver = ns2.fema.gov ns.fema.gov internet address = 166.112.200.142 ns2.fema.govinternet address = 162.83.67.144 Looks Solaris'ish # telnet ns2.fema.gov smtp Trying 162.83.67.144... Connected to ns2.fema.gov. Escape character is '^]'. 220 ns2.fema.gov ESMTP Sendmail 8.11.7p1+Sun/8.11.7; Tue, 13 Sep 2005 09:49:36 -0400 (EDT) ---Mike
Re: Computer systems blamed for feeble hurricane response?
On Tue, 13 Sep 2005, Fergie (Paul Ferguson) wrote: It quoted a Department of Health official as saying every email it had sent to FEMA staff bounced. They need a better internet provider during disasters, the Journal quoted her or him as saying. A number of US agencies made desperate calls to the Department of Homeland Security and to Congresswomen and men, the article claimed. The newspaper did not say which computer systems FEMA uses. $ dig mx fema.gov ;; ANSWER SECTION: fima.org. 3600IN MX 0 smtp.secureserver.net. fima.org. 3600IN MX 10 mailstore1.secureserver.net. ;; AUTHORITY SECTION: fima.org. 3600IN NS PARK5.secureserver.net. fima.org. 3600IN NS PARK6.secureserver.net. [This is Godaddy and their datacenter is obviously in Arizona] $ dig fima.org [snip] $ ;; ANSWER SECTION: fema.gov. 1800IN A 205.128.1.44 ;; AUTHORITY SECTION: fema.gov. 1800IN NS ns.fema.gov. fema.gov. 1800IN NS ns2.fema.gov. $ whois -h completewhois.com 205.128.1.44 [snip] Level 3 Communications, Inc. LVLT-ORG-205-128 (NET-205-128-0-0-1) 205.128.0.0 - 205.131.255.255 Federal Emergency Management Agency FEDEMERGENCY-1-18 (NET-205-128-1-0-1) 205.128.1.0 - 205.128.1.127 Note: They also have 192.206.40.0/24 (not routed), 205.142.100.0/22 (not routed), 64.119.224.0/20 (not in bgp) and 166.112.0.0/16 (announced by 2828 - XO). While its possible that L3 or XO could have been down with one of their southern links, I really dont think it would effect their Washington, DC customers. -- William Leibzon Elan Networks [EMAIL PROTECTED]
Re: Computer systems blamed for feeble hurricane response?
In message [EMAIL PROTECTED], william(at)elan .net writes: On Tue, 13 Sep 2005, Fergie (Paul Ferguson) wrote: It quoted a Department of Health official as saying every email it had sent to FEMA staff bounced. They need a better internet provider during disasters, the Journal quoted her or him as saying. A number of US agencies made desperate calls to the Department of Homeland Security and to Congresswomen and men, the article claimed. The newspaper did not say which computer systems FEMA uses. $ dig mx fema.gov ;; ANSWER SECTION: fima.org. 3600IN MX 0 smtp.secureserver.net. fima.org. 3600IN MX 10 mailstore1.secureserver.net That's interesting -- I'm not getting that response. --Steven M. Bellovin, http://www.cs.columbia.edu/~smb
Re: Computer systems blamed for feeble hurricane response?
Steven M. Bellovin wrote: In message [EMAIL PROTECTED], william(at)elan .net writes: not say which computer systems FEMA uses. $ dig mx fema.gov ;; ANSWER SECTION: fima.org. 3600IN MX 0 smtp.secureserver.net. fima.org. 3600IN MX 10 mailstore1.secureserver.net That's interesting -- I'm not getting that response. Sure you will. If you dig fima.org and not fema.gov as it appears above. Fema.gov doesn't have any mx. Thanks, Christian
Re: Computer systems blamed for feeble hurricane response?
On Tue, Sep 13, 2005 at 10:08:59AM -0400, Steven M. Bellovin wrote: In message [EMAIL PROTECTED], william(at)elan .net writes: ;; ANSWER SECTION: fima.org. 3600IN MX 0 smtp.secureserver.net. fima.org. 3600IN MX 10 mailstore1.secureserver.net That's interesting -- I'm not getting that response. Second that. Just glanced at the fema website - their contact us section lists a mixture of @dhs.gov as well as @fema.gov addresses. John
Re: Computer systems blamed for feeble hurricane response?
On 13/09/05, Steven M. Bellovin [EMAIL PROTECTED] wrote: $ dig mx fema.gov ;; ANSWER SECTION: fima.org. 3600IN MX 0 smtp.secureserver.net. fima.org. 3600IN MX 10 mailstore1.secureserver.net That's interesting -- I'm not getting that response. Er, who is fIma.org and were you looking for fEma.org instead? -- Suresh Ramasubramanian ([EMAIL PROTECTED])
Re: Computer systems blamed for feeble hurricane response?
The newspaper did not say which computer systems FEMA uses. $ dig mx fema.gov ;; ANSWER SECTION: fima.org. 3600IN MX 0 smtp.secureserver.net. fima.org. 3600IN MX 10 mailstore1.secureserver.net That's interesting -- I'm not getting that response. Sorry about that, as you could probably get from dig, I did it on fima.gov instead ... correct one is: - ;; QUESTION SECTION: ;fema.gov. IN MX ;; AUTHORITY SECTION: fema.gov. 1642IN SOA ns.fema.gov. root.ns2.fema.gov. 2005090901 10800 3600 604800 1800 - 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). -- William Leibzon Elan Networks [EMAIL PROTECTED]
Re: Computer systems blamed for feeble hurricane response?
on Tue, Sep 13, 2005 at 09:54:42AM -0400, Mike Tancsa wrote: At 09:31 AM 13/09/2005, Steven Champeon wrote: Does anyone know what their mail infrastructure looks like? From what I can see, they don't even have an MX record for fema.gov... No MX record, and the A record for fema.gov does not accept smtp traffic. # telnet fema.gov smtp Trying 205.128.1.44... telnet: connect to address 205.128.1.44: Operation timed out telnet: Unable to connect to remote host # Then again, it might be that they use different email addresses ? @dhs.gov ? Their contact us page on fema.gov lists several @fema.gov addresses, so I doubt it. fema.govnameserver = ns.fema.gov fema.govnameserver = ns2.fema.gov ns.fema.gov internet address = 166.112.200.142 ns2.fema.govinternet address = 162.83.67.144 Looks Solaris'ish # telnet ns2.fema.gov smtp Trying 162.83.67.144... Connected to ns2.fema.gov. Escape character is '^]'. 220 ns2.fema.gov ESMTP Sendmail 8.11.7p1+Sun/8.11.7; Tue, 13 Sep 2005 09:49:36 -0400 (EDT) Well, how is any automated system supposed to find it? Sheesh. Apparently, that host accepts mail to postmaster; we'll see if it is actually delivered/read/responded to. -- hesketh.com/inc. v: +1(919)834-2552 f: +1(919)834-2554 w: http://hesketh.com antispam news, solutions for sendmail, exim, postfix: http://enemieslist.com/
Re: Computer systems blamed for feeble hurricane response?
On Tuesday 13 September 2005 09:23, 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). 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. -- Larry Smith SysAd ECSIS.NET [EMAIL PROTECTED]
Re: Computer systems blamed for feeble hurricane response?
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). Uh, which mainstream mail server out there is ignorant enough not to send to A record?
Re: Computer systems blamed for feeble hurricane response?
At 10:29 AM 13/09/2005, Steven Champeon wrote: on Tue, Sep 13, 2005 at 09:54:42AM -0400, Mike Tancsa wrote: Looks Solaris'ish # telnet ns2.fema.gov smtp Trying 162.83.67.144... Connected to ns2.fema.gov. Escape character is '^]'. 220 ns2.fema.gov ESMTP Sendmail 8.11.7p1+Sun/8.11.7; Tue, 13 Sep 2005 09:49:36 -0400 (EDT) Well, how is any automated system supposed to find it? Sheesh. Apparently, that host accepts mail to postmaster; we'll see if it is actually delivered/read/responded to. SOA said root.ns2.fema.gov. It might be someone actually read's roots mail ? I will cc that addr so if its read, they can see the thread at http://www.merit.edu/mail.archives/nanog/msg11505.html and perhaps comment. ---Mike -- hesketh.com/inc. v: +1(919)834-2552 f: +1(919)834-2554 w: http://hesketh.com antispam news, solutions for sendmail, exim, postfix: http://enemieslist.com/
Re: Computer systems blamed for feeble hurricane response?
On Tue, 13 Sep 2005, Christian Kuhtz wrote: 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). Uh, which mainstream mail server out there is ignorant enough not to send to A record? I came around windows mail server that ddnt (not exchange, some small one that I don't remember now). There are also unix php scripts that don't work properly with it. Also earlier versions of postfix did not properly retry delivery if the domain had no MX and connection to they server did not work. Other mail server may also have various types of unusual behavior when they see no MX. Also some servers like exim have option not to send email if there is no MX record (or rather turn off default behavior of falling back to A record if MX is not there). 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. -- William Leibzon Elan Networks [EMAIL PROTECTED]
Re: Computer systems blamed for feeble hurricane response?
On 9/13/05, Fergie (Paul Ferguson) [EMAIL PROTECTED] wrote: Attempts by agencies to spur the Federal Emergency Management Agency into urgent action were met with bouncing emails, the Journal said. while the lot of you can debate proper DNS records and what OS their mail server might be running, does anyone else find it highly odd and worrisome that they're sending emails to alert FEMA of a crisis, instead of, I don't know - phone calls? if I'm a federal agency and I require FEMA's resources immediately, I'm going to pick up the phone and call them; not fire off an email marked urgent. aaron.glenn
Re: Computer systems blamed for feeble hurricane response?
On Tue, 13 Sep 2005 10:39:21 EDT, Christian Kuhtz said: 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). Uh, which mainstream mail server out there is ignorant enough not to send to A record? There's no MX record for fema.gov. The *single* A record doesn't answer on port 25. And there's no mail server I know of that's on enough crack that it thinks trying the 2 NS entries is acceptable pgpW8EUuxY7fa.pgp Description: PGP signature
Re: Computer systems blamed for feeble hurricane response?
On Sep 13, 2005, at 1:13 PM, Fergie (Paul Ferguson) wrote: Attempts by agencies to spur the Federal Emergency Management Agency into urgent action were met with bouncing emails, the Journal said. 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. -David
Re: Computer systems blamed for feeble hurricane response?
[EMAIL PROTECTED] wrote: On Tue, 13 Sep 2005 10:39:21 EDT, Christian Kuhtz said: 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). Uh, which mainstream mail server out there is ignorant enough not to send to A record? There's no MX record for fema.gov. The *single* A record doesn't answer on port 25. And there's no mail server I know of that's on enough crack that it thinks trying the 2 NS entries is acceptable That wasn't the question, I'm well aware of the situation. But thanks for playing ;-)
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.
Re: Computer systems blamed for feeble hurricane response?
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
Re: Computer systems blamed for feeble hurricane response?
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.
Re: Computer systems blamed for feeble hurricane response?
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
Re: Computer systems blamed for feeble hurricane response?
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.
Re: Computer systems blamed for feeble hurricane response?
In message [EMAIL PROTECTED], 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
Re: Computer systems blamed for feeble hurricane response?
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. :) pgpqpvDjw52Hj.pgp Description: PGP signature
Re: Computer systems blamed for feeble hurricane response?
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.
Re: Computer systems blamed for feeble hurricane response?
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.
Re: Computer systems blamed for feeble hurricane response?
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.
Re: Computer systems blamed for feeble hurricane response?
In message [EMAIL PROTECTED], 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
Re: Computer systems blamed for feeble hurricane response?
On Tue, Sep 13, 2005 at 05:54:03PM -0400, Steven M. Bellovin wrote: In message [EMAIL PROTECTED], 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.
Re: Computer systems blamed for feeble hurricane response?
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
Re: Computer systems blamed for feeble hurricane response?
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. Hallhttp://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
mail service with no mx (was - Re: Computer systems blamed for feeble hurricane response?)
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 [EMAIL PROTECTED]
mail service with no mx (was - Re: Computer systems blamed for feeble hurricane response?)
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
Re: mail service with no mx (was - Re: Computer systems blamed for feeble hurricane response?)
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 [EMAIL PROTECTED]
Re: mail service with no mx (was - Re: Computer systems blamed for feeble hurricane response?)
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
Re: mail service with no mx (was - Re: Computer systems blamed for feeble hurricane response?)
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. AAAGGHH! 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? Pueese... -- Crist J. Clark [EMAIL PROTECTED] Globalstar Communications(408) 933-4387
Re: Computer systems blamed for feeble hurricane response?
$ dig mx fema.gov ;; ANSWER SECTION: fima.org. 3600IN MX 0 smtp.secureserver.net. fima.org. 3600IN MX 10 mailstore1.secureserver.net That's interesting -- I'm not getting that response. from tokyo roam.psg.com:/usr/home/randy dig mx fema.gov. ; DiG 9.3.1 mx fema.gov. ;; global options: printcmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 9180 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;fema.gov. IN MX ;; AUTHORITY SECTION: fema.gov. 1797IN SOA ns.fema.gov. root.ns2.fema.gov. 2005090901 10800 3600 604800 1800 ;; Query time: 0 msec ;; SERVER: 202.232.15.98#53(202.232.15.98) ;; WHEN: Wed Sep 14 10:23:20 2005 ;; MSG SIZE rcvd: 74 and roam.psg.com:/usr/home/randy doc -p -w fema.gov Doc-2.2.3: doc -p -w fema.gov Doc-2.2.3: Starting test of fema.gov. parent is gov. Doc-2.2.3: Test date - Wed Sep 14 10:23:48 JST 2005 ERROR: NS list from fema.gov. authoritative servers does not === match NS list from parent (gov.) servers ERROR: nse.algx.net. claims to be authoritative, but does not appear in NS list from authoritative servers ERROR: nsf.algx.net. claims to be authoritative, but does not appear in NS list from authoritative servers Summary: ERRORS found for fema.gov. (count: 3) Done testing fema.gov. Wed Sep 14 10:23:52 JST 200 5
Re: mail service with no mx (was - Re: Computer systems blamed for feeble hurricane response?)
In message [EMAIL PROTECTED], 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
RE: mail service with no mx (was - Re: Computer systems blamed for feeble hurricane response?)
Application layer firewalls have existed for at least 6 years. Make that 15 Socks, fwtk (before it went commercial) to name a few. -M
Re: mail service with no mx (was - Re: Computer systems blamed for feeble hurricane response?)
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.
