Re: bug 2

[Brian Stafford <brian stafford uklinux net>]

On Mon,  4 June 12:31 Ali Akcaagac wrote:
| On 2001.06.04 13:22:07 +0200 Brian Stafford wrote:
| > On Sat,  2 June 09:27 Ali Akcaagac wrote:
| > 
| > | sine i use --with-esmtp=no i think i am able using
| > | the old way of sending emails. i dont want to install
| > | another crappy library for sending some emails. any
| > | ideas howto fix that problem ?
| > 
| > I like to think libESMTP is rather good, however there
| > is always room for improvement.
| > 
| > I'd appreciate a list of the ways in which libESMTP is
| > crappy, then I can set about improving it so that it's no
| > longer quite so crappy.
| 
| errm....
| 
| nono its not crappy because of its functionality. i just
| hated the idea having another library installed to use
| balsa. i liked the old way pretty much. but now that its
| compiled and installed here on my system, i can live with
| it now.. the only annoyance is that balsa depends on another
| library. thats all.

One option might be to build only the static version of libESMTP.
Then it gets linked conventionally and Balsa doesn't require
another lib.

Having said that, libESMTP is being looked at for some other
projects now that its getting more stable.  It is even rumoured
that it will become part of Debian, so perhaps this is less of
a problem in the long run.

| i really like the idea of having this:
| 
| - optionally old SMTP as it used to be in balsa

Balsa's old SMTP client is fairly buggy and violates RFC 822 in
certain ways (e.g. multiline responses from the server aren't
handled properly - might have been fixed since I started libESMTP,
can't remember).  Also it didn't support some useful SMTP extensions.
Forking sendmail would have been *much* more reliable.

| - optionally new ESMTP
| - optionally SENDMAIL

THe problem IMO of forking sendmail is that much of the fine control
that is available using SMTP + extensions is lost.  To date Balsa
has been unable to take any advantage of this since it hasn't had
a comprehensive SMTP client and the functionality is not necessarily
available via the sendmail command line.

There is however an aletrnative way of forking sendmail which
runs a SMTP session on the standard input (sendmail -bs) rather than
specifying the recipients on the command line and piping the
message to the standard input.  I will probably add support for this
in the future, but its not high on my list of priorities just now.

| the old SMTP was quite ok for me. did its job best. i cant
| see any improved USAGABILITY for me now that i was forced
| to ESMTP maybe you can clear me up.

Don't forget that libESMTP's problem space is that of message
submission and not relay.  RFC 2476 goes into the difference
in more detail.

Fundamentally all that changes is the method of submission to the MTA.
The MTA is still required for queueing, performing MX routing etc.
Instead of forking sendmail  to submit, libESMTP expects to be able to
connect to the sendmail daemon.  Of course, the daemon need not run
on the same host now since a socket is used rather than a pipe.

Also, if multiple A records are listed in DNS for the mail submission
host, libESMTP will try them all until it finds a server that is up.
The DNS server rotates the list, thus load balancing and if a host is
down, libESMTP still stands a good chance of sending the mail.
In summary, both load balancing and redundancy are supported.

The PIPELINING extension and socket buffering in libESMTP should
improve performance when submitting mail via an ISP's server.

The AUTH extension permits authentication (e.g. typically required
by Netscape Messaging server, M$ Exchange and recent versions of
sendmail).

The SIZE extension is used so that sending large mails which would
be rejected is avoided.  This is useful when you submit via a
dial up ISP.  Without SIZE, you might spend considerable time sending
a mail only to have the ISP's server reject it for being too large
*after* all the data is transferred.

DSN can be requested, although Balsa doesn't do this yet.  It shouldn't
be hard to do since the code needed in Balsa is pretty much the same as
introduced in the MDN patch.

LibESMTP may also be much easier to use when located behind a firewall
which blocks access to port 25 on the Internet.  Sendmail needs to be
configured for a smarthost to work in this scenario and even then
could have difficulty if AUTH is required by the MTA on the smarthost.

| only fact is that balsa causes more problems than before
| because it rather often stores the mail in the queue instead
| throwing the mail out. i need to select 'send queue mail'
| really often in the past days.

But don't forget libESMTP does not replace the MTA, it merely
changes the interface to the MTA and in some cases eliminates
the need for an MTA on the host running the MUA.

Its true that most of the benefits of using libESMTP are subtle
from a user's perspective, however I contend that any difficulties
are not inherent in using SMTP for mail submission, rather they are
a side effect of a dramatic change in the mail submission mechanism.

Regards
Brian Stafford