SMTP pseudocode?

Hoping this is the right group for this question ...

I'm considering writing a custom SMTP component. To do that properly,
I'd need to understand the details of that protocol.

I know that SMTP is defined by various RFCs. However, it would clearly
be a significant task to code it up correctly, working from those RFCs.

Thus, does anyone know of an algorithmic expression of SMTP? That is, a
definition of SMTP expressed in some kind of non-discursive pseudocode?

eg:

sent MAIL command;
get reply code;
if code = 123 then
this
else
that
....

etc.

I'm not looking for a brief overview or broad outline. I have that
already. I'm looking for a detailed pseudocode which accounts for all
the nooks & crannies of the protocol!

TIA,
TC

Re: SMTP pseudocode?

On Thu, 3 Nov 2005, TC wrote:
> I know that SMTP is defined by various RFCs. However, it would clearly
> be a significant task to code it up correctly, working from those RFCs.

That is the only way to implement SMTP correctly.

> Thus, does anyone know of an algorithmic expression of SMTP? That is, a
> definition of SMTP expressed in some kind of non-discursive pseudocode?

No such thing exists that is also complete and correct.

Quite frankly, there are quite enough poor-quality SMTP implementations in
the world without adding yet another one written by someone who does not
want to be bothered with reading the RFCs. Either work from the RFCs, or
don't implement SMTP at all.

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.

Re: SMTP pseudocode?

TC wrote:
> I'm considering writing a custom SMTP component. To do that properly,
> I'd need to understand the details of that protocol.
>

My guess is that this isn't the case. My guess is that you want to
write a submission client. That's essentially a superset of SMTP.

> I know that SMTP is defined by various RFCs. However, it would clearly
> be a significant task to code it up correctly, working from those RFCs.
>

You need to do that, I'm afraid. Well, actually, I'm glad - the RFCs
for email are generally very good.

For what it's worth, the submission code in my email client is
undoubtedly the most complex part, but given that it's UI independent
and cross-platform Python, you're welcome to put together a simple
command-line submission agent, if you can work within the GPL. Then
you'll be supporting more submission extensions that any single server
actually offers.

The code's in subversion at
http://svn.dave.cridland.net/svn/projects/infotrope/python/

If you're interested, drop me an email, and I'll talk you through it. I
think you could probably write a submission client in about 10 or 20
lines of Python, depending on what you need to do.

Dave.

Re: SMTP pseudocode?

This is a MIME GnuPG-signed message. If you see this text, it means that
your E-mail or Usenet software does not support MIME signed messages.
The Internet standard for MIME PGP messages, RFC 2015, was published in 1996.
To open this message correctly you will need to install E-mail or Usenet
software that supports modern Internet standards.

--=_mimegpg-commodore.email-scan.com-12457-1131105256-0002
Content-Type: text/plain; format=flowed; charset="US-ASCII"
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

TC writes:

> I know that SMTP is defined by various RFCs. However, it would clearly
> be a significant task to code it up correctly, working from those RFCs.

SMTP is one of the simplest, easiest, mail-related protocols to implement.



--=_mimegpg-commodore.email-scan.com-12457-1131105256-0002
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.7 (GNU/Linux)

iD8DBQBDa0vox9p3GYHlUOIRAj0XAJ4nyw1qi4xTxXBryB93D55ld98wyQCg gDqL
GJXuysMQEKki6KytXj4Y8bI=
=oQjc
-----END PGP SIGNATURE-----

--=_mimegpg-commodore.email-scan.com-12457-1131105256-0002--

Re: SMTP pseudocode?

Mark Crispin wrote:


> Quite frankly, there are quite enough poor-quality SMTP implementations in
> the world without adding yet another one written by someone who does not
> want to be bothered with reading the RFCs.

(1) I must have missed the part where I said that I "did not want to
be bothered reading the RFCs".

(2) I have >30 years professional software development experience - so
if I write a component for SMTP, or anything else, it will probably not
be a "poor quality" one, thatks very much.

(3) Possibly you enjoy re-inventing the wheel. I do not. Obviously
there are compliant components out there, so it is highly likely that
someone has already sat down with the RFCs and expressed them in a
pseudocode form. The question is not whether a pseudocode form already
exists - clearly it does, somewhere. The question is whether one is
available publically.

TC

Re: SMTP pseudocode?

Thanks for the comments. You're right, I only need the submission part.

I was going to use Blat, but I'm troubled by its minimal error
handling.

I'll look at the code you mentioned & see if it will help. Thanks also
for the offer of email, I will take you up on that if it becomes
necessary :-)

Cheers,
TC

Re: SMTP pseudocode?

On 2005-11-05, TC wrote:
> Thanks for the comments. You're right, I only need the submission part.
>
> I was going to use Blat, but I'm troubled by its minimal error
> handling.

If you were going to use Blat, I don't know why you wouldn't use
a scripting language and one of its libraries. Perl has Net::SMTP
and I am sure Python and Ruby have equivalents. Those would also provide
real-world implementations to use as an example should you decide
to write your own after all.

--
Mike Heins
Perusion -- Expert Interchange Consulting http://www.perusion.com/

Be patient. God isn't finished with me yet. -- unknown

Re: SMTP pseudocode?

A number of SMTP clients and servers support logging. If the one you use
does, turn logging on and then try a number of scenarios.

What language where you intending to write the component in?

--
Andrew Butchart
andrew@floatingbear.ca


"TC" wrote in message
news:1131082324.050369.248010@g47g2000cwa.googlegroups.com.. .
> Hoping this is the right group for this question ...
>
> I'm considering writing a custom SMTP component. To do that properly,
> I'd need to understand the details of that protocol.
>
> I know that SMTP is defined by various RFCs. However, it would clearly
> be a significant task to code it up correctly, working from those RFCs.
>
> Thus, does anyone know of an algorithmic expression of SMTP? That is, a
> definition of SMTP expressed in some kind of non-discursive pseudocode?
>
> eg:
>
> sent MAIL command;
> get reply code;
> if code = 123 then
> this
> else
> that
> ...
>
> etc.
>
> I'm not looking for a brief overview or broad outline. I have that
> already. I'm looking for a detailed pseudocode which accounts for all
> the nooks & crannies of the protocol!
>
> TIA,
> TC
>

Re: SMTP pseudocode?

Hmm, I should probably have said that this is for win32 boxes :-)

I market a commercial win32 app. I want to add some automatic emailing
functions to it. For that purpose, I need a stand-alone component with
a minimal footprint. For that reason, I need to avoid requiring support
libraries etc. I am toying with the idea of writing my own, for the
simple reason that I could integrate it better into the needs of my
app.

Blat seems very functional, but the error handling is not up to par. A
single error code might mean, for example, that the server was down, or
the m/c was out of memory, or the specified file did not exist, or
today is a thursday, or your brother's hat was on the wrong peg!, & so
on.

But I guess I could look at perl examples to double check the
algorithyms.

Thanks,
TC

Re: SMTP pseudocode?

I was going to use VBA. (That's the language of the commercial
apploication in which I want to use it.) I've already done a simple one
(some time ago), but that did not support attachments, authentication,
& so on: it was just a "quick & dirty" to get the general feel for the
protocol.

But I feel that I will probably need to multi-thread it, which can't be
done in VBA.

Cheers,
TC

Re: SMTP pseudocode?

TC wrote:

> (1) I must have missed the part where I said that I "did not want to
> be bothered reading the RFCs".

"I want to implement a standard, but I don't want to bother reading the
document that describes that standard."

OK.....

> (2) I have >30 years professional software development experience - so
> if I write a component for SMTP, or anything else, it will probably not
> be a "poor quality" one, thatks very much.

It will be an extremely high-quality implmentation of something, but
most likely not of SMTP.

> (3) Possibly you enjoy re-inventing the wheel. I do not. Obviously
> there are compliant components out there, so it is highly likely that
> someone has already sat down with the RFCs and expressed them in a
> pseudocode form. The question is not whether a pseudocode form already
> exists - clearly it does, somewhere. The question is whether one is
> available publically.

Download the Perl Net::SMTP module. Then use it instead of writing
your own.

search.cpan.org is your friend.

--
David.

Re: SMTP pseudocode?

Mark Crispin wrote on Thu, 3 Nov 2005 22:02:13
-0800:
> On Thu, 3 Nov 2005, TC wrote:
>> I know that SMTP is defined by various RFCs. However, it would clearly
>> be a significant task to code it up correctly, working from those
>> RFCs.

> That is the only way to implement SMTP correctly.

>> Thus, does anyone know of an algorithmic expression of SMTP? That is, a
>> definition of SMTP expressed in some kind of non-discursive pseudocode?

> No such thing exists that is also complete and correct.

> Quite frankly, there are quite enough poor-quality SMTP implementations
> in the world without adding yet another one written by someone who does
> not want to be bothered with reading the RFCs. Either work from the
> RFCs, or don't implement SMTP at all.

Mark, it might just be that if there were such a pseudocode description
of SMTP available, it might help implementers to understand the RFCs
better, motivate them to read the RFCs more thoroughly, hence _reduce_
the number of duff SMTP implementations. After all, reading and
understanding documentation (even well written stuff like RFCs) is work,
and what hacker wants to duplicate work unnecessarily?

> -- Mark --

--
Alan Mackenzie (Munich, Germany)
Email: aacm@muuc.dee; to decode, wherever there is a repeated letter
(like "aa"), remove half of them (leaving, say, "a").

Re: SMTP pseudocode?

If you're going to use VBA then you have two basic choices - MAPI/CDO or the
Outlook object. Both of those use the local mail client as an intermediary
to send mail.

I have a VB program that I use for this purpose that I install on a server
and the client stations just deposit records into a shared SQL database to
trigger mail. I did try to market it for some time, but there was little
interest.

You might want to check out http://www.planetsourcecode.com for samples as
well.

--
Andrew Butchart
andrew@floatingbear.ca


"TC" wrote in message
news:1131238004.593027.315540@g49g2000cwa.googlegroups.com.. .
> I was going to use VBA. (That's the language of the commercial
> apploication in which I want to use it.) I've already done a simple one
> (some time ago), but that did not support attachments, authentication,
> & so on: it was just a "quick & dirty" to get the general feel for the
> protocol.
>
> But I feel that I will probably need to multi-thread it, which can't be
> done in VBA.
>
> Cheers,
> TC
>

Re: SMTP pseudocode?

On 2005-11-06, Andrew Butchart wrote:
> If you're going to use VBA then you have two basic choices - MAPI/CDO or the
> Outlook object. Both of those use the local mail client as an intermediary
> to send mail.
>
> I have a VB program that I use for this purpose that I install on a server
> and the client stations just deposit records into a shared SQL database to
> trigger mail. I did try to market it for some time, but there was little
> interest.
>
> You might want to check out http://www.planetsourcecode.com for samples as
> well.
>

I will confess I don't have much confidence in any of your ability to
produce standards-compliant software when you can't even post to Usenet
properly....no context at all, quotes below a signature, etc.

--
Mike Heins
Perusion -- Expert Interchange Consulting http://www.perusion.com/

Be patient. God isn't finished with me yet. -- unknown

Re: SMTP pseudocode?

On Sun, 6 Nov 2005, Alan Mackenzie wrote:
> Mark, it might just be that if there were such a pseudocode description
> of SMTP available, it might help implementers to understand the RFCs
> better, motivate them to read the RFCs more thoroughly, hence _reduce_
> the number of duff SMTP implementations. After all, reading and
> understanding documentation (even well written stuff like RFCs) is work,
> and what hacker wants to duplicate work unnecessarily?

That sounds very much like "I don't want to read the book, I'll just read
the Cliff Notes and fake it from there."

There are numerous pedagogical texts which discuss the SMTP protocol; for
example, Kevin Johnson's "Internet Email Protocols: A Developer's Guide".
But these books do not presume to show you how to implement SMTP; rather,
they teach you enough about the protocol that you can analyze a
transaction, and understand the RFCs when the time comes to write an
implementation.

However, for writing an implementation, there is no substitute for reading
the RFCs.

Lazy programmers are not hackers.

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.

Re: SMTP pseudocode?

"Mike Heins" wrote in message
news:slrndmsbpe.9s5.mikeh@bill.heins.net...
> I will confess I don't have much confidence in any of your ability to
> produce standards-compliant software when you can't even post to Usenet
> properly....no context at all, quotes below a signature, etc.
>
> --
> Mike Heins
> Perusion -- Expert Interchange Consulting http://www.perusion.com/
>
> Be patient. God isn't finished with me yet. -- unknown


Excuuuuse me - remind me not to use rude people like you for any consulting
services I might ever need.
--
Andrew Butchart
andrew@floatingbear.ca

Re: SMTP pseudocode?

On 2005-11-06, Andrew Butchart wrote:
> "Mike Heins" wrote in message
> news:slrndmsbpe.9s5.mikeh@bill.heins.net...
>> I will confess I don't have much confidence in any of your ability to
>> produce standards-compliant software when you can't even post to Usenet
>> properly....no context at all, quotes below a signature, etc.
>>
>
> Excuuuuse me - remind me not to use rude people like you for any consulting
> services I might ever need.

You have a possible point, though personally I find it as rude to
improperly post and reduce the signal-to-noise ratio of a group
such as this.

What's more rude? Improper behavior, or calling people on their improper
behavior? I don't know.

In any case, a group like this should be a professional one. I argue
that proper protocol with regard to posting is important, and that
when something like that is left to degenerate then Usenet becomes
just another garbage-infested bulletin board.

You apparently feel that not risking people taking offense is more
important.

My original point stands -- when one is not steeped in the lore and
practices of the Internet, it is very difficult to software that will
work as intended in that environment.

Note the undoubtedly excellent programmers of Microsoft swinging and
missing for years on Outlook before they began to start making it
meet standards. They were good at programming, but they didn't know
diddly about the Internet or its culture. In fact, their god-awful
decision to have Outlook default to putting its cursor at the top
of the quoted message area is the major reason we have so many rude
people top posting today.

--
Mike Heins
Perusion -- Expert Interchange Consulting http://www.perusion.com/

Be patient. God isn't finished with me yet. -- unknown

Re: SMTP pseudocode?

On Mon, 07 Nov 2005 01:00:55 -0000, Mike Heins
wrote:

>In fact, their god-awful
>decision to have Outlook default to putting its cursor at the top
>of the quoted message area is the major reason we have so many rude
>people top posting today.

Sorry, that's bullshit. Where do you think Agent places the cursor?
Quoting a long winded message completely is just as rude whether it's top
posted or bottom posted. I think OE/O is really horrible software for a
number of reasons, but cursor placement in followups isn't one of them
(in case you're thinking I'm just a MS crapware apologist).
I mostly agree with Mark, although I don't think that the
anti-top-posting crusaders are actually more annoying than the top
posting itself. I think it's a toss-up.

Steve Baker

Re: SMTP pseudocode?

Mike Heins wrote:
>
> Top-quoting is here to stay in corporate email, no doubt, simply because
> the laziness and poor editing skills.

Or perhaps because people have found it a more efficient method.

Busy people can read the reply without having to scroll down to the
bottom. They may remember what the thread was about, and so not need to
read the quote.

Another technique used by busy people is to answer points within the
quoted text. So you may see:

Dear Fred,

> a quoted question

the answer

> another quoted question

the answer

.... and so on. For this to work, it's better for people to get in the
habit of reading from the top.

Since most people use threaded email clients and newsreaders nowadays,
quoting is largely unnecessary. It certainly isn't worth arguing about.

--
Julian