Re: SMTP

Jack Masters wrote:
As to point out why I asked this: I am devoloping an application which gives the generic telnet connection and RFC a GUI, so that I could use it to security-test the servers I work with. The program is capable of learning protocols by reading trough snoop-logs of communication on that protocol between a server and a client that already knows what to do.

That sounds like a seriously ambitious goal. Having done the odd reverse-engineering of protocols with no or insufficient documentation, I am interested. How do you deal with things like windowing where the sender can have multiple unacknowledged commands outstanding, and unknown CRC algorithms? Analysing by hand yields a serious headache, and printouts with tons of lines trying to link commands to responses.

I realize that. This whole thing was based on the asumption that the all protocols I intend to work with have something in comon and that I can successfully replicate the common sense people usualy utilize when reading RFCs. It became preety clear pretty soon that making it universal will not work, so I made it to be as helpfull as you can expect a guessworks GUI to be.

The current version is looking out for response codes, so it obviously doesn't even work with POP3 (uses +/- instead of numeric response codes). All the tool does thoe is when the user clicks a command, shows an icon explaining if the response code is as expected or not, so that's not much.

It is interesting to work on, thoe. My programming experience comes from several years in the area of artificial intelligence. So if you know any tough protocols to crack (that still use a text-like interface; e.g.: readable), please tell me what they are, so I can check RFCs and try to figure out how I figure it out.

Doesn't surprise me in the least. M$ has it's own way of doing things, and apparently their own implementations of TCP were not completely conforming to any standard (the various deviations are useful for nmap fingerprinting though).

*nods* I know. However this is a clear example of an introduction into a dissaster, when using/making software that knows only one specific way to do protocol.

SMTP in itself is a simple protocol. There are however a bunch of extensions to the original (8bitmime, authentication, ...) that are not implemented by older servers and clients. The idea is that everything should be backward compatible though, and if a modern client encounters an older server it just doesn't use the newer commands. The DATA .... CRLF.CRLF thing however is part of the original standard, and I don't think there is anything that doesn't use it. [open to correction, just did a quick grep over the RFCs here, nothing jumped out that looked suspicious]

In my program I only try the basics and the usually hidden basics. Exploring a little. For example: I won't be implementing the HTTP gzip support until I'm done experimenting in plain ASCII text.

--
Model: INFJ
Primary function: Coprocessor
Secondary function: Cluster commander

Yes I'm a therian:
http://www.wikitherian.org

Creationism & Darwin:
"The bible says humans were
supposed to use animals to
do work for them and I like
to work so I must be an animal!"
.

Loading