Re: Balsa + libESMTP patch

[Brian Stafford <brian stafford uklinux net>]

On Thu,  3 May 19:10 Albrecht Dreß wrote:
| Am 03.05.2001 11:47:04 schrieb(en) Brian Stafford:
| > My position is that its unnecessary.  Convince me that there is
| > some functionality that is available through an exec'ed MTA that
| > is *not* available with the SMTP interface and I'll reconsider.
|
| I currently run Balsa with the "Local Mail Transport Agent" button
| checked,
| and use fetchmail to get new messages. I must admit that it took me
| *weeks* to
| get a working sendmail configuration for my needs, so I would strongly
| support
| a more user-friendly mechanism... :-)). So, just to check back, does
| your lib
| support the following:
| 
| * rewriting of headers (the masquerade/virtusertable stuff in
| sendmail. I had
| to patch sendmail to get everything working, btw);

No.  This functionality will never be in libESMTP, because it
belongs in an MTA.  You will need to run sendmail as a daemon and
set "Remote SMTP Server" to localhost:25 or what ever is appropriate.
This is exactly how Netscape/Mozilla would be set up to do this.

Of course connecting to the sendmail daemon via SMTP means that
sendmail needn't run on the same host as your MUA which might be
useful (e.g. the same sendmail configuration will work for users
running Outlook Express or Eudora on a Windoze box if the submit
mail via the system running sendmail).

| * "expensive" queues (I have an ISDN line, and I do *not* want to dial
| in for
| every new mail to be sent), but I need immediate delivery in the local
| subnet.

Again, this functionality belongs in the MTA.  LibESMTP's design goal
is to be an SMTP client.  It provides an API to the SMTP protocol and
its extensions for the specific purpose of mail submission, nothing
else.  This really isn't as simple as it sounds.  The payback is that
much more fine-grained control over the mail submission process is
possible than via sendmail's command line.

To be certain that I wasn't missing anything important available
by execing sendmail rather than connecting to it vis SMTP, I asked
on comp.mail.sendmail and got the following response :-

>> >What advantages does piping a message into an exec'ed sendmail
>> >have over using SMTP to "sendmail -bd" on localhost?
>>
>> The client doesn't have to implement SMTP.
>>
>> >I'm interested to know if sendmail would process things differently
>> >or not.  I've had a look through my copy of the bat book and the
>> >source code, but I can't see any differences in processing other
>> >than the method of submission.
>>
>> Nothing that should be of real importance in normal usage. The
>> standard anti-spam/relay features only apply to messages passed in
>> via SMTP. The daemon will use sendmail.cf as of when it was started
>> or SIGHUP'ed, while the exec'ed sendmail will (of course) read the
>> current one as it starts.  If you've forgotten to make sendmail
>> setuid-root, submission via SMTP will still work (assuming the
>> daemon was started by root, of course), while exec'ing will not.
>> (There are changes in this area in 8.12 though, where you can have a
>> non-setuid-root sendmail accepting mail via exec'ing if you've set
>> things up right.)

So in summary, unless you want to send spam, there is no difference.
Using SMTP avoids the need for a setuid root sendmail.


Regards
Brian Stafford