On Sat, Dec 20, 2003 at 09:53:35AM -0500, Alan DeKok wrote:
Of course. But the *intent* behind SMTP was to enable two-way human
communication.
Says who?
Nearly all protocols on the Internet I know of have the itent to enable
two-way human communication. Even router protocols like BGP do.
HTTP, POP3, DNS, LDAP, FTP they all do, just like SMTP does and SMTP does
it in no way more special than any of these, except for protocols like IRC
or VoIP that are specially designed for direct two-way human interaction.
The intent with SMTP was to deliver an "electronic message" from one point
to another. As WAN links were crowded and unstable the design clearly allowed
for relaying and "backup MX" to route messages if the target host was
not directly accessible. Another name for this is a store-and-forward
system.
e.g. UDP "notification" packets, containing URL's where the
information may be found.
At the time SMTP was designed URLs didn't even exist. UDP was really
unreliable and lines were as flaky as hell.
SMTP compared to other protocols is more attackable because there are no
rules assigned to email addresses while there are rules assigned to
ports. (For example nobody can use a DNS service as an NTP service.)
Surely I can use a DNS service as an NTP service.
I could even use DNS for SMTP. All necessary information can be coded
in TXT records. All you need is some protocol agreement between sender
and receiver how to transfer the SMTP protocol via DNS.
I can use SMTP to transfer all kinds of data like executable
programs, XML files, movies, sound files, ... streaming protocols could
be a bit harder to handle but not impossible.
There are services like ftp-mailer that allow FTP Archive access via
SMTP.
Just like there are services like HTTP that can be used to transport
(encoded) SMTP protocol or a lot of other protocols.
Ports are not protocols. Someone can easily run DNS on the port
assigned to NTP. This is a big problem for an IDS. If TCP had a
"protocol" field, in addition to "src/dst port" fields, then a number
of network problems, and application insecurities could have been
avoided.
No. Nothing stops me from abusing the HTTP Protocol like in
POST http://some.mail.server:25/ for SMTP
POST http://some.telnet.server:23/ for telnet
POST http://some.www.server:80/cgi-bin/telnet.emu for telnet
As SMTP, telnet, HTTP operate at another protocol level they don't know
(and need not know) about any fields in TCP/UDP or IP packets.
The idea behind protocol stacks should show you that ports or "protocol
fields" don't say *anything* about the data contained, at best they
give information about the encoding and protocol used to transport the
data and thus it is useless. You cannot pevent users from accessing the
data of a FTP archive by blocking the FTP ports. If the data is also
available via SMTP or HTTP you have gained nothing.
\Maex
--
SpaceNet AG | Joseph-Dollinger-Bogen 14 | Fon: +49 (89) 32356-0
Research & Development | D-80807 Muenchen | Fax: +49 (89) 32356-299
"The security, stability and reliability of a computer system is reciprocally
proportional to the amount of vacuity between the ears of the admin"
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg