headers
Satish Viswnantham | 2 Aug 1996 22:14
Picon

SMTP client

Is there any place where I can get SMTP client code (in c). (want to use
send mail
from my programs, do n't want to use sendmail unix command).

thanks,
-- 
bye,
>Satish<
From djb <at> koobera.math.uic.edu Tue Aug  6 01:50:09 1996
Received: from koobera.math.uic.edu (qmailr <at> KOOBERA.MATH.UIC.EDU [128.248.178.247]) by
list.cren.net (8.6.12/8.6.12) with SMTP id BAA27774 for <ietf-smtp <at> list.cren.net>; Tue, 6 Aug 1996
01:50:08 -0400
Received: (qmail-queue invoked by uid 666); 6 Aug 1996 05:54:14 -0000
Date: 6 Aug 1996 05:54:14 -0000
Message-ID: <19960806055414.19379.qmail <at> koobera.math.uic.edu>
From: djb <at> koobera.math.uic.edu (D. J. Bernstein)
To: ietf-smtp <at> list.cren.net
Subject: Re: header-munging

> Comments on draft-gellens-smtp-submit-00.txt are appreciated.

Instead of an SMTP extension, why not use a different TCP port?

Advantage #1: Existing servers, including qmail 0.90+ and sendmail 8.8+,
can already be configured to handle this, with no code changes.

Advantage #2: Client support is very easy. In fact, you can make this
work with every existing client, with no code changes, if you have a
machine sitting around that currently doesn't use port 25. (Just have it
forward port 25 to the new port on the real server. Use a port 113 proxy
(Continue reading)

Permalink | Reply | 0 comments |
headers
Randall C. Gellens | 6 Aug 1996 19:21
Picon

Re: header-munging

On 6 Aug 1996 05:54:14 -0000, djb <at> koobera.math.uic.edu (D. J. Bernstein)
wrote:

> Instead of an SMTP extension, why not use a different TCP port?

It's an interesting idea, and you do cite some good arguments in favor
of it.  However, the problem is that an SMTP client that wishes to give
permission to the SMTP server to fix the message would have to try the
new port number, and if it timed out, use the standard SMTP port.  By
using an extension, the client can connect in the same way, using an old
or new SMTP server.

Also, the draft includes techniques for guessing that the message is in
fact a submission even if the client doesn't use the extension.  That
way the SMTP server can do the right thing when receiving messages from
old and new SMTP clients.

--
|Randall Gellens             |                    randy <at> mv.unisys.com|
|(714) 380-6350              | fax (714)597-8053 can add ,,,,,,,,6350|
|Mail Stop MV 237            |                        Net**2 656-6350|
|Opinions are personal;  facts are suspect;   I speak only for myself|

                  Randomly selected tag:

Coding is "90% finished" for half of the total coding time. Debugging
is "99% complete" most of the time.                    -- Fred Brooks
Permalink | Reply | 0 comments |
headers
Randall C. Gellens | 7 Aug 1996 00:16
Picon

Re: header-munging

On Tue, 06 Aug 1996 14:34:28 -0700, Michael D'Errico <michael.derrico <at> 
software.com> wrote:

> > > Comments on draft-gellens-smtp-submit-00.txt are appreciated.
> >
> > Instead of an SMTP extension, why not use a different TCP port?
>
> I won't comment on that, but....
>
> > [....] If the client can't produce [....] a correctly formatted
> > message, and the server won't accept incorrectly formatted
> > messages, the situation is hopeless.
>
> ....this is exactly why I don't like the SUBMIT idea either.

But this is rarely the case.  More commonly, the client produces a
message which is often good enough, but should be better (for example,
it lacks a Message-ID, and the Date is either missing or incomplete),
and the server either passes everything through as is, or attempts to
fix messages.  If it attempts to fix messages, it might do this for
every message, or for messages it guesses are being submitted.

The SUBMIT extension makes it very clear that the client is giving the
server permission to attempt any fix-ups that might be needed.  The
draft also lists tests which can be used for the server to guess at
message submission if SUBMIT isn't used.

Examples of clients which fail to produce Message-ID and/or proper Date
headers are everywhere, as are examples of servers which munge messages
(often all messages) in an attempt to fix them.
(Continue reading)

Permalink | Reply | 1 comment |
headers
D. J. Bernstein | 6 Aug 1996 21:20
Picon

Re: header-munging

> would have to try the
> new port number, and if it timed out, use the standard SMTP port.

I don't see how that could ever be useful.

_If_ the server accepts broken messages on the new port, there's no
problem. Retrying is a bad idea here.

_If_ the server and client have an out-of-band agreement that the server
will fix up random messages on port 25, then the client can always use
port 25. Retrying is a bad idea here. (This is a common situation today,
and there's no reason to change it if both sides are happy with it.)

_If_ the server hasn't agreed out-of-band to accept broken messages, and
doesn't agree to accept broken messages on the new port, then the client
is out of luck---just as it would be with your SMTP extension. Neither
the client nor the server is willing to produce a valid RFC 822 message.
Retrying is a bad idea here: the client must not send a message through
that server at all. (This situation arises occasionally with clients
that use servers without their permission.)

Remember, the reason for the client to use the new port is that the
relevant server administrator says ``make sure you configure it to use
port XXX for outgoing mail.'' The reason the administrator would say
such a thing is that his port 25 server is _not_ willing to fix up
broken messages.

Exactly what situation are you worried about?

> Also, the draft includes techniques for guessing that the message is in
(Continue reading)

Permalink | Reply | 0 comments |
headers
Michael D'Errico | 7 Aug 1996 03:57

Re: header-munging

  [For some reason this didn't go through to list.cren.net
   the first time I sent it, so here it is again.]

To: "Randall C. Gellens" <RANDY <at> MPA15AB.MV.UNISYS.COM>
cc: djb <at> koobera.math.uic.edu, ietf-smtp <at> list.cren.net

> The SUBMIT extension makes it very clear that the client is giving the
> server permission to attempt any fix-ups that might be needed.  The
> draft also lists tests which can be used for the server to guess at
> message submission if SUBMIT isn't used.

I would think that fixing a client to put in a valid Message-Id and a valid 
Date (and fixing whatever other problems it has) would be far simpler, and 
much more useful, than rewriting it to use ESMTP and look for the optional 
SUBMIT keyword.

You have to ask if it's really worth having an extension for this.

Mike
Permalink | Reply | 0 comments |
headers
D. J. Bernstein | 7 Aug 1996 04:29
Picon

Re: header-munging

> So the SUBMIT extension takes real-world situations and makes them more
> deterministic.

Exactly what problem are you trying to solve?

1. A problem

Here's the interoperability problem I'm worried about.

   naive client ---> fast server ---> rewriting server

A naive client (e.g., Netscape) produces a message with several RFC 822
violations (e.g., ``Sender: joe'', missing Date, etc.) and sends it
through SMTP, in violation of RFC 821, to a fast SMTP server that
doesn't even look at the message (e.g., qmail), which passes it along to
a server that, in violation of its fundamental responsibility as an MTA,
tries to ``fix'' the header (e.g., sendmail).

The result is often a corrupted message. For example, ``Sender: joe''
turns into ``Sender: joe <at> recipient.host''.

Sometimes it's even worse: the message bounces. Unless the envelope
sender is correct (which it rarely is), the bounce never comes back.

I'm sure everybody agrees that this is a problem.

The client is violating all the relevant standards. Hopefully it will be
fixed. However, there's still a problem as long as there's still an
installed base of naive clients.
(Continue reading)

Permalink | Reply | 0 comments |
headers
mark | 7 Aug 1996 22:58
X-Face
Picon

Re: header-munging

On Aug 7, 12:29pm, Randall C. Gellens wrote:
> Subject: Re: header-munging
> On 07 Aug 1996 11:33:39 -0400, Valdis.Kletnieks <at> vt.edu wrote:
>
> > On Tue, 06 Aug 1996 15:16:35 PDT, "Randall C. Gellens" said:
> > > Examples of clients which fail to
> > > produce Message-ID and/or proper Date
> > > headers are everywhere, as are
> > > examples of servers which munge messages
> > > (often all messages) in an attempt to fix them.
> >
> > So what you're saying is that we should trust the people who wrote the
> > broken MUAs to update them, and get *that* correct, when they can't
> > get the *current* RFC's implemented correctly?
>
> I'm saying to MUA writers who, for whatever reason, feel they can't
> generate proper Message-ID, Date, or other headers, to please give the
> MTA permission to fix the message.
>
> Knowing that a message is being submitted allows an MTA to do more than
> fix obviously broken headers.  It can do other replacements/editing that
> may be needed for messages which go outside the company, for example.

Why can't the MTA do the fixup anyway?  sendmail has been doing this
for years, and I'm not aware of any problems its caused.

Indeed, that's one of the features of our configuration of the server,
it fixes up headers to be correct and useful.  Adding/fixing date,
message-id, and addresses are part of the service.
(Continue reading)

Permalink | Reply | 0 comments |
headers
D. J. Bernstein | 11 Aug 1996 13:30
Picon

Re: header-munging

> Why can't the MTA do the fixup anyway?

Let's go back to the picture of how mail works:

               +----------+             +----------+
  -------      |          |    FedEx    |RCVD:FEDEX|      -------
  message ---> | envelope | ----------> | envelope | ---> message
  -------      |          |             |          |      -------
               +----------+             +----------+

Why should FedEx care what's in the message? The delivery information is
all on the envelope. Looking through messages would take some manpower,
and on occasion they'd carelessly tear or smudge some important letter.

E-mail works the same way. Why should an MTA look at the contents of the
message? The delivery information is all on the envelope. (Exception: a
Received line doesn't fit onto the outside of today's standard envelope,
so you're forced to stick it onto the top of the message instead.)

Admittedly, there _was_ once a mail service that opened every letter.
They claimed---correctly, I'm sure---that people were sending illegal
messages through the mail. So they read everything. They didn't allow
any ``bad'' messages to be sent. Of course, they were far too eager to
declare that something was ``bad,'' so they often screwed up somebody's
mail for no good reason. This was the USPS, circa 1944.

> sendmail has been doing this
> for years, and I'm not aware of any problems its caused.

sendmail's rewriting has been a disaster. ``Apparently-To'' reveals
(Continue reading)

Permalink | Reply | 0 comments |
headers
Tim Goodwin | 13 Aug 1996 14:19

Re: header-munging

> It might be a good idea to extend SUBMIT so that the client can say
> either SUBMIT or RELAY.  If the client says RELAY, that tells the MTA
> not to muck with the message at all (except of course to add a received
> header).

So now every sender-SMTP that wants its messages relayed intact must: i)
use ESMTP; ii) check the supported extensions to see if SUBMIT is among
them; and iii) if it is, send RELAY with the MAIL command.

This seems like a significant step in the wrong direction.

Tim.
From RANDY <at> MPA15AB.MV.UNISYS.COM Tue Aug 13 14:04:44 1996
Received: from bbmail1.unisys.com (192-63-2005.unisys.com [192.63.200.5]) by list.cren.net
(8.6.12/8.6.12) with ESMTP id OAA24935 for <ietf-smtp <at> list.cren.net>; Tue, 13 Aug 1996 14:04:42 -0400
Received: from mvdns1.mv.unisys.com (mvdns1.mv.unisys.com [192.59.253.100]) by
bbmail1.unisys.com (8.7.3/8.6.12) with SMTP id SAA23152; Tue, 13 Aug 1996 18:05:00 GMT
Received: from MPA15AB.MV.UNISYS.COM by mvdns1.mv.unisys.com (4.1/SMI-4.1-1.8)
	id AA14687; Tue, 13 Aug 96 18:04:43 GMT
Date: Tue, 13 Aug 1996 11:05:42 -0700 (PDT) (11:05 am 18:05 UT)
From: "Randall C. Gellens"  <RANDY <at> MPA15AB.MV.UNISYS.COM>
To: Tim Goodwin  <tim%uunet.pipex.com <at> MV.Unisys.COM>
Cc: ietf smtp list  <ietf-smtp%list.cren.net <at> MV.Unisys.COM>
Subject: Re: header-munging
In-Reply-To: Your message of "13 Aug 1996 13:19:36 +0100"
References: <AAAvTjIQctgADsRv <at> pipe.pipex.net>
Message-Id: <EJPN0542AC3462 <at> MPA15AB>

On 13 Aug 1996 13:19:36 +0100, Tim Goodwin <tim <at> uunet.pipex.com> wrote:
(Continue reading)

Permalink | Reply | 0 comments |
headers
Tim Goodwin | 14 Aug 1996 12:44

Re: header-munging

> It is far too late to argue that SMTP should not be used for submission.

Agreeed.

> All we can do, as I see it, is either (a) accept the status quo and do
> nothing, or (b) try and improve the situation in an efficient way.

I agree, and I agree that we should strive for (b).

Unfortunately, I really, really, can't see the SUBMIT extension helping.
It's just way too complicated for the client.  Nobody's going to
implement it.

I suppose, maybe, if you're a client that already does ESMTP but submits
broken messages, there might be some point in using SUBMIT.  Such
clients are currently a tiny minority.  For other clients, it would be
simpler to generate conforming RFC 822 messages in the first place.

If we truly hope to overcome the inertia of the status quo, we need
something that's trivial to implement on the client side (and preferably
the server side, too, although that's slightly less important).  The
only suggestion I've seen which I think fits the bill is to use SMTP but
on a different port.

I've written this idea up in internet draft form.  I haven't yet
submitted it, but you can retrieve it from

    ftp://ftp.pipex.net/pub/mail/draft-goodwin-smtp-submit-00.txt

Please let me have any comments.
(Continue reading)

Permalink | Reply | 0 comments |

Gmane