Computer systems blamed for feeble hurricane response?


>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,


Telnet options, and for that matter speed, happen after the 3-way
handshake. We're not getting that far.

    --Steven M. Bellovin,

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

"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.

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. ;->

For "contact us", I'm now getting a 403 error:

You don't have permission to access /feedback/ on this server.

Apache/1.3.33 Server at Port 80

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).