[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Nmh-workers] Success in submitting mail to a secure MTA (was Re: sh

From: Earl Hood
Subject: Re: [Nmh-workers] Success in submitting mail to a secure MTA (was Re: should nmh be an MTA or an MUA?)
Date: Sat, 30 Jan 2010 12:21:52 -0600

On January 30, 2010 at 10:49, Lyndon Nerenberg wrote:

> > Not sure how it worked since SASL support is not available
> > when using sendmail as your mts delivery method.  I.e.  If
> > the SMTP server requires user/pass authentication, sendmail-based
> > deliver will not work.
> Sendmail has had SASL support for years. The version shipped with your OS 
> might not have it compiled in, but it's there.

I meant, "sendmail delivery mode" within MH.  I.e.  When the "mts:"
option is set to "sendmail" vs "smtp".

In this case, nmh will call (fork/exec) the sendmail program (as
specified by the 'sendmail:' option in the mts.conf) to post an
email message (or check addresses when in -whom mode).  nmh invokes
sendmail in -bs mode, allowing it to communicate with the program
(via stdin/stdout) using SMTP commands.

Under this usage model, nmh's SASL support does not exist.  And
if using the openssl command to create a basic SSL pipe to the
SMTP server, SASL support is needed. 

IMO, this allows greater flexibiltiy since dumb proxy connections
can be established w/o being burdened by SMTP and SASL operations.
It is similiar to rsync and the --rsh option, allowing one to
establish remote connections using alternative protocls (ssh)
w/o burdening rsync with such details.

Maybe nmh should have an option to allow one to specify an external
process for establishing the remote connection to the SMTP server.
This way, mts mode can be set to "smtp", but one can specify an
external program to establish the end-points of the communication.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]